How do you check if your Lovable app is leaking data?

Three checks. Look for lovable.app hostnames in your DNS and proxy logs, since that is where Lovable publishes by default. Then search the page source for a Supabase address and key. Then query that database for a table. Crissy Field scanned 159,041 Lovable sites and found 7,403 of them with email addresses sitting in open tables.

What did the researchers find in 159,041 Lovable apps?

Thousands of Supabase-backed Lovable sites had personal data sitting in tables anyone could read. Crissy Field GmbH, an application security firm in Hamburg, says it analyzed 159,041 Lovable projects dating from December 2025 to September 2026, located through the Common Crawl archive, in work done with the German daily Handelsblatt. Of those, 34,545 used Supabase, and 24,664 returned Supabase records the moment the page loaded. That figure on its own is not the finding, and the researchers say so: data served to a visitor may be meant to be public. The exposure showed up when they made further read-only requests, which turned up 10,560 tables holding email addresses, spread over 7,403 of those sites. Crissy Field cautions that the 30 percent that implies is not a confirmed leak rate and that the sample does not represent all Lovable applications.

The examples are what make this a company problem rather than a hobbyist one. One service provider exposed over 1,000 records holding identity document details, among them passport numbers, expiry dates and nationalities. A lifestyle forum in Germany left over 80,000 member profiles open, each with a full name, an email address, a birth date and a gender, plus more than 200,000 chat messages. A property management company exposed machine-written summaries of internal emails about tenants.

How do you find out whether your company has one?

Start with hostnames, because Lovable's default publishing target is predictable. Its documentation says a published app lands on a subdomain of lovable.app taken from the project's own URL, and that Business and Enterprise workspaces get a branded variant. Custom domains come with the paid plans, so an app may also sit on your own domain, and PrivacyAffairs is blunt that you probably cannot tell from the outside.

Then look in the page. UpGuard found Supabase-backed sites at scale through technology-profiling data and by hunting public JavaScript for Supabase key names and database addresses, then asking each one for a table called users; the bad outcome is a page of rows coming back. Across roughly 300,000 domains it found 16,326 databases with readable tables, and says more than half showed signs of personal data. In one case, 4,560 of the email addresses exposed by a valet service, 11 percent of them, were on third-party corporate domains, universities and Fortune 500 companies among them.

Why are the tables readable without a login?

The key in the page is public on purpose, and only row level security stands behind it. Supabase's own documentation is explicit that a secret key must never be put in the browser, which leaves the anonymous role and its policies as the only barrier, and Trending Topics states the consequence directly: where the rules are absent or too loose, anyone holding the public key can read the tables. Supabase names the traps too. A table in an exposed schema with no row level security can be read by any role holding a grant on it, and grants and policies are separate checks, so writing a policy does not withdraw a grant. A policy comparing auth.uid() to a user_id column fails quietly for visitors who are not signed in, because the comparison is against null. Views sidestep row level security unless security_invoker is set.

This is the second time around for the same class of flaw. NVD's CVE-2025-48757 covers insufficient row level security in Lovable up to April 15, 2025, letting unauthenticated attackers read or write arbitrary tables in generated sites. MITRE scored it 9.3, critical, and the record notes the supplier disputes it, on the ground that each customer takes on responsibility for its own data.

Did Supabase's October change close the hole?

Only for tables created after it. Supabase's changelog says new tables in the public schema are no longer wired to the Data API on creation, that it began becoming the default for new projects on May 30, 2026, and that it was switched on for every existing project on October 30, 2026. The sentence that decides your exposure comes next: tables that already exist keep the grants they have and stay reachable.

Supabase gives automation as the reason, naming agents, command-line scripts and AI platforms as table creators, and noting that much of that work happens with nobody reading the diff. UpGuard adds that the earlier row-level-security default covered tables made in the web editor but not tables made through the API, which is the route a coding agent takes. PrivacyAffairs sums up both vendors' changes: neither reaches data that is already exposed, and an app leaking on October 29 is still leaking unless a person fixes it.

Who has to report the breach, you or Lovable?

The company that runs the app does, not the builder. PrivacyAffairs states that the law counts the exposure as the operator's breach rather than Lovable's, and Lovable's documentation agrees that the customer is responsible for meeting the security requirements that apply to its app. GDPR Article 33 allows 72 hours from becoming aware of a breach to tell the regulator, unless the breach is unlikely to put anyone at risk, and Article 34 requires telling the people affected where the risk is high, which covers identity documents and payment details. Unlike a password, a passport number cannot be changed.

Nobody has started that process for these sites. Asked on Hacker News whether the findings went to a regulator, the author said they had not been reported to the authorities, and that the researchers passed the site details to Lovable instead, both because they did not necessarily have a way to reach the owners and because mailing the leaked addresses would have exposed that data further. Lovable has published nothing on its own channels naming the research, though Cybernews reports that the company answered the findings by calling them a known, industry-wide configuration problem with the use of Supabase. Its head of security also answered questions in the thread, saying every app is scanned before publishing and a deeper scan is available free, and that for many customers what stops them fixing an app is a worry that the repair will break production. He did not answer the questions about notifying a regulator.