Short answer: A Hamburg security firm found that thousands of apps built with the AI app builder Lovable let anyone read data that should have been private, including passport numbers, payment details and more than 200,000 chat messages. Nobody hacked Lovable. The apps used Supabase with a public key and missing or loose Row Level Security rules, so the database answered strangers. Supabase and Lovable have both shipped changes, but neither closes tables that are already open. If you built an app on Lovable, you need to check it yourself.
What did the researchers find?
Crissy Field’s report, produced with the German business daily Handelsblatt, looked at 159,041 Lovable projects found in the Common Crawl web archive, covering apps published from December 2025 to September 2026. Of those, 34,545 used Supabase as their database.
On 24,664 of those sites, the page sent database records as soon as it loaded, without a login. That alone can be fine, since a menu or event list is meant to be public. But with further read only requests using the same public key, the researchers found tables holding email addresses on 7,403 sites, about 30% of the sites they examined closely.
The worst cases they describe:
- A German lifestyle forum with more than 80,000 profiles (full name, email, date of birth, gender) and over 200,000 chat messages
- Event organizers and restaurants exposing tens of thousands of ticket and food orders, with phone numbers, postal addresses, payment information and ticket codes
- A property manager’s AI generated summaries of internal emails about tenants and owners
- A service provider with more than 1,000 identity document records, including passport numbers, expiry dates and nationalities
- Tens of thousands of contracts and invoices, photo albums, internal WhatsApp messages, and in one case 280,000 emails sent to a company’s customers
The report reached the Hacker News front page and climbed past 800 points, which is why builders are talking about it this weekend.
How careful are those numbers?
Crissy Field is upfront about the limits, and so should we be. The 30% figure is not a confirmed leak rate: an email address can be a public contact or test data, and personal records without an email field were missed. The Common Crawl sample does not represent every Lovable app. The researchers downloaded only parts of each dataset, did not name the apps, did not publish how to access them, and could not tell whether anyone misused the data. They also did not examine Lovable’s own newer built in database, only Supabase.
Why did this happen?
Supabase lets a web page talk to the database directly using a publishable key that sits in the page’s code, where anyone can see it. That is by design. What keeps strangers out is Row Level Security (RLS): rules inside Postgres that decide which rows each user may read or write. When RLS is off on a table, or a policy is written too loosely, the public key opens the whole table.
This is not new. A researcher reported the same pattern in Lovable apps in 2025, filed as CVE-2025-48757. Lovable’s position has stayed consistent: its security documentation says customers are responsible for making sure their app meets the security requirements of its use case. The tension is that Lovable markets itself to people who do not code, and many of them have never heard of RLS.
What have Lovable and Supabase changed?
| Change | What it does | What it does not do |
|---|---|---|
| Supabase default grants | New tables in the public schema are no longer reachable through the Data API until you add an explicit GRANT, now enforced on all projects |
Existing tables keep their current grants and stay reachable |
| Lovable publish check | Projects on Lovable’s built in backend with unresolved critical findings get a review prompt before publishing, plus a “Fix all” option in chat | You can still choose “publish anyway”; apps nobody republishes are not rechecked |
The Supabase changelog is explicit that existing tables “keep their current grants and stay reachable.” The Lovable changelog describes the new publish review step. In short, both changes help the next app. Neither one fixes an app that was already leaking.
How do you check your own Lovable or Supabase app?
If you shipped anything on Lovable with Supabase, set aside 30 minutes for this:
- Run Lovable’s Deep scan in the project’s Security view. It is free but not automatic.
- Open Supabase’s Security Advisor in the dashboard and fix every table it flags, starting with anything holding personal data.
- Turn on RLS for every table the app reads from the browser, then write policies scoped to the signed in user, typically
auth.uid() = user_id. - Test like a stranger. Log out, open your app, and using only the publishable key, try to select from each table. Anything you can read is public.
- Revoke what you do not need. If a table should never be read by anonymous visitors, remove the
anongrant instead of relying on policy alone. - Keep the service role key server side. It bypasses RLS entirely and must never appear in front end code.
- Repeat after big changes. Every new table or feature the AI adds is a new place to get this wrong.
If real personal data was exposed, the legal responsibility sits with you as the app operator, not with Lovable. Under the GDPR, a breach that puts people at risk has to be reported to your data protection authority within 72 hours of becoming aware of it, and high risk cases such as ID documents or payment data also require telling the people affected. US builders should check their state’s breach notification rules, which vary.
What does this mean for people building with AI app builders?
AI builders like Lovable, Bolt and Replit have made it easy to go from prompt to live app in an afternoon. This report is a reminder that “it works” and “it is safe to hold customer data” are different tests. Generated apps follow recurring patterns, which means one misconfiguration can be found across thousands of sites with little extra effort.
The practical rule: a prototype with test data is fine to ship fast. The moment an app stores real names, emails, payments or documents, treat access control as a separate review step, either your own checklist above or a professional security check. If you sell app building as a service, an RLS audit is now something clients will reasonably expect you to include.
What to watch next
- Whether Lovable adds automatic rescans for already published apps, or blocks publishing with critical findings outside Enterprise plans
- Whether Supabase goes further on existing tables, for example by emailing owners of projects with RLS disabled on exposed tables
- Regulator interest in Europe, given the passport and payment data involved
Sources: Crissy Field research report, Supabase changelog on Data API grants, Lovable changelog, PrivacyAffairs follow up, Supabase Row Level Security docs.
