Lovable apps leaking data: how missing Supabase Row Level Security keeps exposing AI-built products

Why AI-built apps ship without Row Level Security

The short answer: because nothing forces them to, and the app works either way. Supabase, the backend most AI builders pair with, exposes a public API key by design. That key is safe exactly as long as Row Level Security (RLS) policies are configured on every table; without them, as Wiz Research put it in their February 2026 Moltbook analysis, “this key grants full database access to anyone who has it.” An app with no policies looks identical to a secure one in every demo. The customer sees the same screens. The founder sees the same green checkmarks. The difference only appears when someone hostile, or curious, queries the API directly.

Code generators make this worse in a specific, measurable way: they optimise for code that runs, not code that’s safe. Veracode’s Spring 2026 GenAI Code Security report found AI-generated code passing security checks at roughly 55%, essentially unchanged in two years despite dramatically better functional quality. And the failure compounds over iterations: a peer-reviewed 2026 arXiv study documents security degrading across successive AI generations of the same codebase, because each regeneration can silently drop constraints a previous pass added. An auditor in a widely read Indie Hackers thread (May 2026) named the discipline this creates: the question for AI-built apps is “not ‘what’s broken’ but ‘what used to be restricted that quietly isn’t anymore.’”

The incident record, 2025–2026

Answer first: four separate, documented incidents trace to the same family of failure: a backend reachable with credentials the frontend hands out, and no row-level policies behind it. The details differ; the mechanism repeats.

CVE-2025-48757, disclosed 2025, disputed. After findings by security researcher Matt Palmer in March 2025, CVE-2025-48757 described insufficient Row Level Security in Lovable-generated sites, allowing unauthorized reads and writes against generated apps’ tables. A follow-up analysis by Superblocks counted 170 vulnerable apps of 1,645 scanned, across 303 exposed endpoints. Two honesty notes that most write-ups of this CVE omit: the vendor formally disputes the entry, and NVD assigns it no severity score of its own; the widely quoted 8.26 figure comes from third-party databases such as SentinelOne. The dispute is about whether a platform is the right object for a CVE, not about whether the exposed tables were exposed. As of 2026, Lovable applies RLS to newly generated schemas, while apps generated before the change remain vulnerable until manually fixed (VibeAppScanner’s 2026 status review).

Moltbook, February 2026. Wiz Research (Gal Nagli, February 2, 2026) found the viral “social network for AI agents” running on a misconfigured Supabase database with full read and write access open: 1.5 million API authentication tokens, 35,000 email addresses, and private messages, all reachable because RLS was missing on critical tables. Moltbook wasn’t built on Lovable; that’s precisely the point. The same vibe-coded pattern produces the same exposure wherever it’s assembled. One almost comic detail from the same report: behind the 1.5 million “AI agents” stood about 17,000 humans.

Lovable’s platform incident, April 2026. Between February 3 and April 20, 2026, a backend regression at Lovable made chat history and source code of public projects readable by any Lovable user with a project link. Researchers reported it through HackerOne starting February 22; the reports were closed unescalated because the triage team was working from outdated documentation, and the issue was only fixed, within two hours, after researcher @weezerOSINT disclosed it publicly on April 20. Accounts of the scope differ, and both deserve stating: the researcher and subsequent write-ups (Bastion, April 2026) described source code, database credentials and AI chat histories of projects created before November 2025 as readable from any free account; Lovable’s own post-mortem (April 22, 2026) states the exposure covered chat history and source code of public projects, and that private projects and Lovable Cloud were never impacted. What the vendor conceded is damning enough, in their own words: “we hadn’t built the product safeguards, the communication muscle, or the security processes to match the trust our users placed in us.”

Base44, July 2025. Wiz Research also disclosed an authentication bypass in Wix-owned Base44: an app_id retrievable from a public manifest file allowed registering a verified account on private enterprise apps, bypassing SSO. Base44 fixed it within 24 hours of the report (Wiz Research, July 29, 2025), a genuinely fast response. It belongs in this record because it shows the category-level truth: on a bundled platform, every app inherits the platform’s mistakes, and no app owner can audit or fix that layer themselves.

How exposed is the category as a whole?

Answer first: systematically, not anecdotally. Escape.tech’s security team scanned more than 5,600 publicly available vibe-coded applications and found over 2,000 vulnerabilities, more than 400 exposed secrets, and 175 instances of personal data including medical records and IBANs (Escape.tech research, 2025–2026). Combine that with Veracode’s ~55% security pass rate for generated code and the arXiv finding that iteration makes it worse, and the working assumption for any AI-built app that hasn’t had a dedicated security pass should be: something is open.

Check your own app in ten minutes

Answer first: you can test the core exposure yourself, today, without a security background. Three checks, in order of importance:

1. The RLS test. In your Supabase dashboard, open Table Editor and look at each table: Supabase labels tables with RLS disabled. Then verify from the outside: call your project’s REST endpoint with only the public (anon) key, requesting a table that should be private. A secure app returns an empty result or an authorization error. If real rows come back, your database is readable by anyone who finds the key, and the key is in your frontend by design.
2. The bundle test. Open your deployed app in a browser, view the JavaScript sources, and search for key, secret and sk_. The public Supabase key is expected; anything else (payment keys, service-role keys, third-party credentials) is a live problem.
3. The regression test. If you’ve regenerated features since your last check, re-run check 1. The Indie Hackers audit thread (May–June 2026) documents the pattern: a regenerated table comes back without the RLS policies the original had, nothing errors, and the hole sits open until someone looks.

If check 1 returns real rows and your users are in the EU, you have crossed from a security finding into a legal one. Personal data readable by anyone holding the public key is a personal data breach as GDPR defines it (Article 4(12)) once you cannot rule out that someone read it. Article 33 then gives you 72 hours from becoming aware to notify the supervisory authority, unless the breach is unlikely to put anyone at risk; where the risk is high, Article 34 requires telling the affected people too, without undue delay. Either way, Article 33(5) requires you to document the breach: the facts, its effects, the remedial action. Write that record the same day. There is a fuller guide to the GDPR surface of AI-built apps →

The fix, honestly

Answer first: enabling RLS is quick; designing correct policies is the real work, and it’s finite. Turning RLS on for a table is one command. But a policy is an access-control decision: who may read which rows, who may write, in which roles. On an app with ten tables and three user types, that’s a day or two of careful work plus testing, well within reach of a competent contractor even if you never touch it yourself. Rotate every key that has ever been in the project while you’re at it; given the incident record above, old keys should be treated as burned.

Two limits of the patch path deserve naming. First, policies you add can be silently dropped by the next AI regeneration, so a patch without a verification layer (tests that fail loudly when a table goes open) decays. Second, RLS fixes the door, not the house: if your app also keeps business logic in the client, holds regulated data, or is hitting platform ceilings, the policy work is necessary but not sufficient. That’s a structural question, and there’s an honest ten-question self-assessment for it on the Lovable page.

What the alternatives cost

Answer first: the market has three price bands, and they buy different things. Automated scanners and audit services ($199–$4,500 across vendors like the ones quoted throughout this piece) find the holes; they don’t redesign the access model or take responsibility for the fix holding. A proper security-plus-architecture diagnosis sits in the low thousands; mine is €7,500, fixed, one week, and it prices both paths: what a durable patch costs, and what a rebuild costs if the problems turn out to be structural. Full rebuilds of proven products land, in published market spans that match my own band, between €50,000 and €150,000. The wrong purchase is paying rebuild money for a scan, or scan money expecting a rebuild.

Questions founders actually ask

Is Supabase itself insecure?

No. Supabase’s model is explicit: the public key is safe when RLS policies are configured, and the platform now warns loudly about tables without them. Every incident above is a configuration failure by the generating tool or the app builder, not a Supabase vulnerability.

Lovable says it applies RLS now. Am I safe?

If your schema was generated after the change, the defaults are much better. Two caveats: apps generated earlier don’t get retrofitted (VibeAppScanner, 2026), and default policies are not the same as policies that match your product’s actual roles. Run the ten-minute check regardless of when your app was built.

My app was affected by the April 2026 incident window. What should I have done by now?

Rotate every secret that ever appeared in your project (Supabase keys, API tokens, anything pasted into chats), check your Supabase logs for reads you can’t explain, and if you hold customer data, assess whether your disclosure obligations were triggered. Bastion’s April 2026 write-up carries a practical checklist.

If my Lovable app leaked data, do I have to report it?

If the people in the data are in the EU, very likely yes, and the duty is yours: under GDPR the controller is the business that decides why and how the data is used, which is your company, not Lovable or Supabase. Article 33 gives you 72 hours from becoming aware to notify the supervisory authority, unless the breach is unlikely to put anyone at risk; Article 34 adds a duty to inform the affected people directly when the risk is high; Article 33(5) requires you to document every breach either way, so the regulator can check your reasoning. Exposure without proof of access still counts once you cannot rule access out. That is the regulation’s own text, not legal advice; a lawyer decides the borderline cases. There is a fuller guide to the GDPR surface of AI-built apps at /articles/gdpr-ai-built-apps-eu-personal-data/.

Can’t I just ask the AI to secure the app?

You can ask, and it will produce something. The measured reality: ~55% of generations pass security checks (Veracode, Spring 2026), and iterative regeneration degrades what was previously fixed (arXiv, 2026). Security work needs a human who owns verification. That’s not a sales line; it’s what the incident record shows.

Is this only a Lovable problem?

No. Moltbook wasn’t Lovable, Base44’s flaw was platform-level, and Bolt-generated apps show the same keys-in-bundle pattern (VibeAppScanner’s Bolt analysis, 2026). The mechanism follows the pattern, not the brand.