Lovable apps leaked passports and 200,000 chats: 7,403 sites exposed email data, and Lovable blames missing RLS

On November 14, a study of apps built with the AI app builder Lovable reached the top of Hacker News and drew a public response from the company. The research, by Hamburg security consultancy Crissy Field in collaboration with the German business daily Handelsblatt, analyzed 159,041 Lovable projects and found that 7,403 of them returned database tables containing email addresses to anyone who asked, with no login. Case examples include a forum with more than 80,000 user profiles and 200,000 chat messages, and a service provider with over 1,000 identity records including passport numbers.

The findings are not new this week: Handelsblatt first reported them on November 2, and the Crissy Field write-up carries updated figures. What changed on November 14 is that Lovable’s head of security, posting as Igor in the Hacker News thread, confirmed the root cause in plain terms: the affected apps had insufficient Row-Level Security. That turns a set of anonymized examples into a concrete, checkable failure mode for anyone shipping an AI-generated app on Supabase.

What the scan found

Crissy Field used the open web archive Common Crawl to identify Lovable projects crawled between December 2025 and September 2026. The funnel looks like this:

Step	Count
Lovable projects identified	159,041
Projects using Supabase	34,545
Sites that sent Supabase records on page load, no login	24,664
Sites with email addresses in readable tables	7,403 (30% of 24,664)
Tables containing email addresses	10,560

The researchers are careful about the third row. A site that loads database records for an anonymous visitor is often working as intended: product listings, blog posts and public profiles are supposed to be public. The problem appears in the next step. Using the same public API key the site ships to every browser, the researchers made additional read-only requests and found tables that were never meant to be shown.

The anonymized examples go well beyond mailing lists:

• A German lifestyle forum: more than 80,000 profiles with full names, emails, dates of birth and gender, plus more than 200,000 chat messages.
• Event organizers and restaurants: tens of thousands of ticket and food-order records with emails, phone numbers, postal addresses, payment information and ticket codes.
• A property manager: AI-generated summaries of internal emails about tenants, owners and partners.
• A service provider: more than 1,000 records with passport numbers, expiry dates and nationalities.
• Newsletter and support data, including one table of 280,000 emails sent to a provider’s customers.

In the Hacker News thread, the report’s author (username neathack) added a figure that is not in the write-up: a classifier run locally over each dataset flagged “nearly 4,000 websites” as leaking privacy-sensitive data at an 85% confidence threshold. He described that as 15.9% of Lovable sites using Supabase, a share that lines up with the 24,664 sites that returned records, not the full 34,545.

Why a public key can read private tables

The mechanism is ordinary, which is the uncomfortable part. A Supabase app talks to its Postgres database directly from the browser through an auto-generated REST API. The key that authorizes those requests is embedded in the site’s JavaScript by design. It is not a secret. What is supposed to stand between that key and your users’ data is Row-Level Security (RLS): per-table Postgres policies that decide which rows a given caller may read or write.

If a table has no RLS, or a policy that lets everyone through, the public key can read the whole table. The app’s interface may never display that data, but the interface is not the security boundary. Anyone can open the browser’s network tab, copy the project URL and key, and query other tables by name. “No advanced hacking techniques were used,” neathack wrote, adding that the team had planned to move on to more sophisticated attacks and never got there because so much was already open.

Until this year, Supabase made the mistake easy to make. Every new table in the public schema was automatically granted select, insert, update and delete to the anonymous role, so RLS was the only safeguard. Supabase has been reversing that default: since May 30, 2026, new projects no longer expose new tables to the Data API without an explicit GRANT, and the change was scheduled to reach existing projects on October 30. Its stated reason is that the old model relied on a human reviewing each new table, and that “doesn’t scale” when agents and AI platforms create tables on their own. The change only covers new tables, though. Tables that already exist keep their grants, so it does nothing for the apps in this study that are already deployed.

Lovable’s response, and what its scanner does by default

Igor, Lovable’s head of security, thanked the Crissy Field team and said the root cause “is exactly what our scanning is built to catch.” He pointed to a November 10 blog post describing the tooling: an automatic scan before every publish, a free deeper scan, a Fix button, an auto-fix mode and a setting that blocks publishing while critical findings are open.

Lovable’s security documentation is more specific about what is on by default, and the details matter:

• Quick scan runs automatically on every publish. It checks for tables without RLS and for policies that let everyone through, plus dependency issues. It does not review application code.
• Deep scan adds a code review covering access control, unauthenticated endpoints and exposed personal data. It does not run automatically; the user has to trigger it. Scheduled deep scans are an Enterprise feature.
• Blocking publish on critical findings is a workspace setting. The docs say new Enterprise workspaces start with it enabled. For other projects, a dialog shows the findings and offers a choice to fix them or “publish anyway.”
• Auto-fix is opt-in, and applies only to quick-scan findings.

So a non-Enterprise user who is told a table has no access rules can still click through and ship. Igor acknowledged this in a follow-up comment: for many users the obstacle is “the fear that the fix will break production,” and some apps will publish regardless of warnings. Lovable’s answer is to make auto-fix cautious enough about breaking changes to turn it on by default “one day (soon!).”

neathack’s criticism is aimed at the gap between that reality and the marketing. Lovable tells non-technical founders they do not need to know how to code, while its terms say users are “solely responsible” for reviewing and validating AI output. People who buy the first message are unlikely to act on the second, he argues, and it is the site operator, not Lovable, who faces the privacy fines when data leaks.

The limits of the numbers, and the fight over method

Crissy Field states several caveats that are easy to lose in the headline. The 30% figure “should therefore not be read as a confirmed data leak rate”: an email address is a rough marker that can catch public contact addresses and test data, and misses sensitive tables with no email column. The Common Crawl sample is not representative of all Lovable apps (Lovable says more than 50 million projects have been created on the platform). The researchers retrieved only part of each dataset, so the real exposure is likely larger, and they could not establish whether anyone had misused the data. Apps using Lovable’s own built-in database, introduced in late 2025, were not examined. Crissy Field also sells security assessments, and the report ends with an offer to book one.

The method itself drew fire. Hacker News user jacquesm argued that pulling records from thousands of third-party databases goes past proving a vulnerability and becomes a breach in its own right. neathack’s reply: the team downloaded only the first page of results per table, analyzed it with a local model, deleted the records and kept only metadata, and worked with a data-protection lawyer brought in by Handelsblatt. Lovable was informed weeks before publication and received the list of sites, table names and record counts so it could contact the owners. The incident has not been reported to data-protection authorities, and the affected operators have not been named.

What to check if you have shipped one of these apps

The pattern is not unique to Lovable. On November 10, Claroc reported 35,578 Grok Build apps open to the internet because of a sharing default. The common thread is that the person who prompted the app into existence never saw the access model.

For a Supabase-backed app, the check takes minutes:

1. In the Supabase dashboard, confirm RLS is enabled on every table in the public schema, and read each policy. A policy with USING (true) on a table of user data is the same as no policy.
2. Test from outside: take the project URL and anon key from your site’s JavaScript and request /rest/v1/<table>?select=* for each table without logging in. Anything that comes back is public.
3. Check write access the same way. Open insert or update permissions can be worse than open reads.
4. In Lovable, run the deep scan manually, and turn on “Block publishing with critical issues” in workspace settings.
5. Repeat after every significant change, since each new table an agent creates is a new chance to miss a policy.

The things to watch next are whether Lovable makes auto-fix and publish blocking the default for all plans, whether any data-protection authority takes an interest in the roughly 4,000 flagged sites, and whether Supabase’s stricter grants show up as a measurable drop in exposed tables in apps created after May.