Short version: in early November 2026, researchers reported that tens of thousands of apps built with the AI app-maker Lovable were leaking real user data - passport numbers, payment details and more than 200,000 private chat messages - readable by anyone, with no login. The headline numbers are real. But the important part is why it happened, because this was not a "hack" of Lovable. It was a predictable gap in how AI builders and their database default - a gap you can check for and close in an afternoon. Here is a calm, technical assessment: what happened, the root cause, and how to tell whether your own app is exposed.
What the report actually found
The German research group Crissy Field, working with the business daily Handelsblatt, scanned 159,041 Lovable projects pulled from the public Common Crawl web archive (apps created between December 2025 and September 2026). Of the roughly 34,500 using Supabase as their backend, 24,664 returned database records with no authentication at all. Sifted and others covered the findings, and the story spread quickly across social media.
The specifics are what made it land:
- Email addresses were readable on 7,403 sites, across more than 10,500 database tables.
- One service provider exposed over 1,000 passport records, complete with nationalities and expiry dates.
- A lifestyle forum leaked more than 200,000 chat messages and 80,000 user profiles.
- A single CRM-style project exposed over 280,000 customer emails, waiting-list entries and support tickets.
Crucially, the researchers did not break anything. They used plain, read-only requests - the same kind the app itself makes. If the data came back to them, it would come back to anyone who looked.
This was not a "Lovable hack" - and that matters
It is tempting to read a story like this as "Lovable is insecure." That is the wrong lesson, and it leads to the wrong fixes. Lovable's servers were not breached. The data was exposed because of a setting in each app's own database that was never switched on: Row-Level Security.
This is a shared-responsibility gap, and it is the same class of issue behind CVE-2025-48757 earlier in the year - a formally recorded, critical-severity (CVSS 9.3) vulnerability describing exactly this: insufficient Row-Level Security in Lovable-generated sites, letting unauthenticated users read or write arbitrary database tables. Independent scans tell the same story: researchers have catalogued more than 16,000 exposed Supabase databases behind vibe-coded apps, and a separate Lovable-hosted app was found leaking around 18,000 users' records. The pattern is consistent - and so is the fix.
The root cause, in plain English
Most Lovable apps store their data in Supabase, a hosted Postgres database. To talk to Supabase from the browser, the app uses a public key called the anon key. That key is meant to be public - it ships in the frontend of every app. By itself it is not a secret.
The only thing standing between that public key and your data is Row-Level Security (RLS): a set of rules that says "this user can only see their own rows." Supabase's own documentation is explicit that enabling and writing those rules is your job. If RLS is off - easy to miss when an AI generates your tables and you are moving fast - Supabase does exactly what it is told: it hands every row to anyone holding the public key. No login required. That is the whole mechanism behind every number in the report.
There is a sharper version of the same mistake: shipping the service_role key - an admin key that bypasses RLS entirely - in frontend code. That key belongs on your server and nowhere else. If it is in your browser bundle, your database is wide open regardless of RLS.
Why AI builders are especially prone to this
None of this is unique to Lovable - the same gap shows up in apps built with Bubble, Replit, Base44, v0 and hand-written code too. But AI builders concentrate the risk, for a few honest reasons:
- Speed hides steps. You describe a feature, the tables appear, the app works. The security layer is invisible, so it is easy to assume it is handled. It usually is not.
- Insecure-friendly defaults. Generating a working app and generating a secured one are different jobs. The quickest path to "it works" leaves RLS off.
- No security review in the loop. A traditional team has someone who asks "is this table protected?" A solo founder shipping with AI often does not - until a researcher, or an attacker, asks it for them.
To its credit, Lovable responded to the earlier CVE by adding an automated Security Scanner and an AI Security Reviewer - a genuinely good move. But as the researchers noted, a scanner that checks whether a policy exists is not the same as checking whether the policy is correct. Tooling helps; it does not replace understanding what you shipped.
Our honest assessment of Lovable
We build and rescue AI-built products for a living, so let us be fair: Lovable is a genuinely good tool. For prototypes, internal tools and early MVPs it is fast, capable and a great way to turn an idea into something people can click. The problem is not the tool - it is the moment an app graduates from "demo" to "real users with real data." That is where the data layer stops being a detail and becomes the whole game.
So the assessment is not "avoid Lovable." It is: know which stage you are at, and secure the data layer before real people trust it with their information.
Is your app exposed? A 6-point self-check
You do not need a security team to answer this. Work through the list below - most of it takes an afternoon.
- Turn RLS on for every table. In Supabase, confirm Row-Level Security is enabled on all tables, not just some. A table without RLS is public.
- Write real policies, do not just enable RLS. "Enabled" with a permissive policy still leaks. Each table needs rules that tie rows to the logged-in user (for example,
auth.uid() = user_id). - Test with the anon key. Open your app, grab the public anon key from the network tab, and try to read each table directly. If data comes back without logging in, so can everyone else.
- Remove any service_role key from the frontend. Search your client bundle and repo. That key bypasses RLS - it must live only on a backend you control.
- Protect writes, not just reads. The CVE covered read and write. Make sure nobody can insert, update or delete rows they should not.
- Lock down storage and admin tables. File buckets, storage and any "admin" tables need the same scrutiny as your main data.
If you want the broader version of this, we keep a running list of the security holes we most often find in AI-built apps - RLS is near the top every time.
When to bring in engineers
There is a clear line. If your Lovable app is a prototype or an internal tool, the self-check above is usually enough. The moment it holds personal data, payments, or anything you would not want screenshotted in a news article, it is worth a proper review - and often a plan to move the critical parts to a hardened, production-grade setup.
This is exactly where human expertise and AI efficiency meet. AI builders let a small team move astonishingly fast; experienced engineers make sure that speed does not quietly turn into a data breach. We help both ways: a focused security review of what you have already shipped, or a migration from Lovable to a scalable, secure MVP when you have outgrown the prototype. If you are weighing that up, our guide on moving from no-code to production walks through the trade-offs.
The takeaway
The Lovable data exposure is not a reason to fear AI builders - it is a reminder that shipping fast and shipping safely are a single discipline, not a trade-off. The tools are extraordinary. The one step they cannot take for you yet is deciding that your users' data deserves a lock on the door. Turn RLS on, test it the way an attacker would, and you have closed the gap behind every headline in that report. If you would like a second pair of eyes on an app you have built with AI, we are happy to take a look.
FAQ
Is Lovable safe to use?
Yes, for what it is designed for. Lovable is a strong tool for prototypes, internal tools and early MVPs. The 2026 data leaks were not a flaw in Lovable itself - they came from apps shipping with Supabase Row-Level Security turned off, which leaves the database readable by anyone. Enable RLS and write proper policies, and a Lovable app can be perfectly safe for real users.
What caused the Lovable data leak?
Missing Row-Level Security (RLS) on Supabase, the database most Lovable apps use. Apps talk to Supabase with a public anon key, and RLS is the rule set that restricts each user to their own data. When RLS is left off, that public key returns every row to anyone, with no login. This is the same root cause as the critical vulnerability recorded as CVE-2025-48757.
How do I know if my Lovable app leaked data?
Open your app, copy the public anon key from the browser network tab, and try to query each table directly. If data comes back without logging in, your tables are exposed. Also confirm RLS is enabled on every table, that each table has a real policy (not just "enabled"), and that no service_role admin key is present in your frontend code.
What is Supabase Row-Level Security (RLS)?
RLS is a Postgres feature that controls which rows each user can read or write. In a Supabase app it is the main thing protecting your data, because the key used from the browser is public by design. Supabase does not enable RLS for you - you have to turn it on and write policies that tie each row to the logged-in user.
Can you build secure apps with AI?
Absolutely. AI builders dramatically speed up development; they just do not make the security decisions for you. Secure AI-built apps come from pairing that speed with a few deliberate practices - RLS on every table, keys scoped and kept server-side, writes protected, and a review before real user data is involved. That combination of human expertise and AI efficiency is how we build by default.
