Back

[Analysis]

Lovable and Moltbook: AI-built apps with missing database access controls

A SaaS built with 'zero hand written code' was shut down within days. A tenth of the Lovable apps one researcher checked let anyone read their data. Moltbook exposed 1.5 million API tokens. The same control was missing every time, and nobody had checked for it.

Sam O., Technical Writer, Assurance
Anton Osika, in a pale jacket and wearing a headset microphone, speaking from an armchair on a stage lit in purple and blue.
Anton Osika, co-founder and chief executive of Lovable, at Web Summit in Lisbon in November 2025. After CVE-2025-48757 was reported, Lovable added a security scan to its publishing flow. Cropped from the original. Photo by Sam Barnes / Web Summit via Sportsfile, CC BY 4.0.

On 15 March 2025, a founder posted that his new SaaS had been built with Cursor, “zero hand written code”. Two days later he posted again: “guys, i’m under attack”. He listed maxed-out API keys, people bypassing the subscription and junk being written to his database. Within a week the product was gone.

It would be easy to write that off as one founder’s bad week. But over the following year the same failure turned up again and again, in apps built with different tools by very different people. Each app worked, and nobody had checked who else it worked for.

Lovable: a tenth of the apps checked

Lovable builds web apps from a description, typically with a Supabase database behind them. The app’s web page talks to the database directly, using a key that’s public by design. What keeps one user out of another’s data is Row Level Security (RLS): rules in the database saying who may read or change each row.

In March 2025 Matt Palmer, a security researcher, found a Lovable-built site that would hand over its users’ email addresses to anyone who asked. He then checked the home pages of 1,645 apps on Lovable’s showcase. In 170 of them (about 10%), 303 endpoints returned data without any login: personal details, payment and subscription information, and API keys for other services. They only looked at home pages; they didn’t try anything behind a login.

Palmer reported it to Lovable on 21 March and published in May, as CVE-2025-48757. Lovable added a security scan to its publishing flow. As Palmer pointed out, it checks that RLS rules exist, not that they’re right.

Moltbook: minutes to find, three hours to fix

Moltbook, a social network for AI agents, launched at the end of January 2026 and quickly became one of the most talked-about sites in tech. Its founder had been clear about how it was built: “I didn’t write a single line of code for @moltbook. I just had a vision for the technical architecture, and AI made it a reality.”

Researchers at Wiz found the problem within minutes of looking. The Supabase key was in the site’s JavaScript, as expected, but RLS wasn’t switched on, so that public key could read and write the entire production database: 1.5 million API tokens for registered agents, around 35,000 email addresses, and private messages between agents, some of them containing third-party API keys, including OpenAI keys, in plain text. Anyone could also have changed what was posted.

Wiz reported it late on 31 January, and Moltbook had fixed it within about three hours. That’s a good response. But nobody should have been able to find it in minutes in the first place.

[One public key, the whole database]

  1. Web page, with the public key in its JavaScript
  2. Database API
  3. Every table, because RLS is off

What the key could reach at Moltbook

  • 1.5 million agent API tokens
  • 35,000 email addresses
  • Private messages
  • Write access to posts

With RLS on and rules that match the app, the same key only reaches what each signed-in user should see.

Why this keeps happening

None of these apps failed because the AI wrote obviously bad code. They failed because of something that wasn’t there. Access control is invisible when it works and when it’s missing: the app looks and behaves exactly the same for its owner either way. An AI tool asked to make something work will make it work. Unless someone asks, it has no reason to make it refuse.

This is exactly where the NCSC’s vibe coding spectrum says to slow down. Code that handles authentication, access control or personal data belongs at the end of the spectrum where a person understands and checks it, however it was first written.

What to check before launch

If you’ve built something with an AI app builder, or someone has built it for you, these are the questions we’d ask first:

Building with AI isn’t the problem. Launching something that holds other people’s data without anyone having checked who can read it is, and that was true long before the code wrote itself.

Sources

Back