Lovable apps exposed passports and 200,000 chats: 24,664 sites open without login

Security researchers at Hamburg firm Crissy Field say that, out of 159,041 Lovable projects they identified, 24,664 websites handed over database records the moment a page loaded, with no login. Among the data they report finding: more than 200,000 chat messages from one forum, and over 1,000 identity records with passport numbers from one service provider. The findings are about apps people built with Lovable's AI app builder and connected to a Supabase database, so the fix sits with each app's owner as much as with Lovable.

Key points

• Crissy Field, working with the German newspaper Handelsblatt, analysed 159,041 Lovable projects from December 2025 to September 2026; 34,545 of them used Supabase.
• 24,664 sites sent Supabase database records on load without login or interaction, and records with email addresses showed up in 10,560 tables across 7,403 sites.
• The researchers say they found a forum with more than 80,000 profiles and over 200,000 chat messages, and a service provider with more than 1,000 identity records including passport numbers.
• The researchers stress that the 30% share (7,403 of 24,664) is not a confirmed leak rate and that the sample is not representative of all Lovable apps.
• The report does not say whether any of the data was misused, and the report does not document a Lovable response.

What to do

If you built an app with Lovable and Supabase: the exposure comes from how database access is controlled, so check it from the outside, not from your own logged-in session. Supabase separates table grants (which operations a role may attempt) from row-level security (RLS) policies (which rows it may touch), and both need checking. Hiding pages or filtering lists in the front end does not enforce authorization; the database must.

A practical test, following the approach in a guide from the security firm Wavect: write down who may read and change each record and field; test with two synthetic users and one signed-out caller; include a positive control (the owner can read their own row) so an empty answer is not mistaken for a block; test writes too; then repeat against the deployed app, not only a local copy. Wavect also lists pitfalls: a narrow new policy does nothing if a broader permissive policy still applies (permissive policies combine with OR), admin or table-owner connections bypass RLS and so cannot stand in for customers, and anonymous sign-ins still use the authenticated role, so they need their own condition.

If your app already held personal data in a readable table: Wavect recommends containing the access path first, preserving logs, and involving security and data-protection staff. Crissy Field's own advice is to review access permissions, interfaces and the separation between user accounts before an app handles real customer or business data, to repeat the checks after significant changes, and to bring in qualified help if you lack the expertise. It adds that automated checks are not a substitute for a professional security assessment.

If you are a user of such an app: nothing in the report lets us name affected apps, so there is no list to check. Treat unexpected emails that mention details you gave one of these services with extra caution.

What happened

Handelsblatt reporter Lina Knees published the first account on 2 November 2026. Crissy Field then published a report that, in its words, contains a more recent analysis with updated figures. Both draw on the same method: the researchers found projects through Common Crawl web archive datasets and looked at those built with Lovable, an AI tool that generates web apps from prompts.

They counted 159,041 Lovable projects from December 2025 to September 2026. Of these, 34,545 used Supabase, the database service the researchers believe is most widely used with Lovable. They looked only at Supabase, not at Lovable's own database features. Of the Supabase sites, 24,664 sent database records when the page loaded, without any login or interaction. With read-only requests using the same public key the page itself uses, they retrieved more data. Records containing email addresses appeared in 10,560 tables across 7,403 of those sites.

The report describes several cases without naming the operators. A German lifestyle forum exposed more than 80,000 profiles (names, email addresses, birth dates, gender) and more than 200,000 chat messages. Event organisers and restaurants exposed tens of thousands of ticket and food-sale records with emails, phone numbers, postal addresses, payment information and ticket codes. A property management company exposed AI-generated summaries of internal emails about tenants, owners and business partners. One service provider exposed more than 1,000 records with identity-document details: passport numbers, expiry dates and nationalities. Other cases included contracts, invoices, personal photo albums and internal WhatsApp communications, and one provider's 280,000 customer emails.

The researchers say they could not determine whether the data had been misused. They also withheld technical access details to avoid making further access easier, and the report does not state the exact access-control cause in each case.

Background

This is not the first time Lovable apps have been in this position. CVE-2025-48757, published on 30 May 2025, describes an insufficient row-level security policy in Lovable, through 15 April 2025, that lets unauthenticated remote attackers read or write arbitrary tables in generated sites. The record rates it CVSS 3.1 9.3, critical, and notes the supplier disputes it, saying each customer is responsible for protecting its own application's data. That dispute is the core of the issue this time as well: who is responsible when an AI tool generates an app whose database is open.

Separately, in April 2026 Lovable published a statement about a different incident, which according to Wavect involved a regression that let authenticated users with a public-project link reach a project's source and chat history in the builder. Lovable says it fixed it and that private projects and Lovable Cloud were not affected. Wavect points out that this concerns the editor, not the database of deployed apps, and does not verify any particular app.

The numbers

The funnel below shows how the researchers got from all projects to the sites with email addresses. Each step is a subset of the one before it, and the last figure counts sites where email-like records appeared, not confirmed leaks.

Lovable projects identified159041

Projects using Supabase34545

Sites returning records on load24664

Sites with email-address records7403

Lovable projects in the Crissy Field analysis, by stage (sites or projects)

	sites or projects
Lovable projects identified	159041
Projects using Supabase	34545
Sites returning records on load	24664
Sites with email-address records	7403

Source: Crissy Field, Lovable research report (November 2026)

Techzine, which also reported the study, and Wavect both repeat the same four figures, and both repeat the researchers' warning: the emails could be public contact addresses or test data, so 30% is not a confirmed breach rate.

How it works

Supabase exposes a database to the browser through an API and a public key that ships in the page. That is by design: the key is not a secret, and the safety comes from RLS policies that decide which rows a visitor may see. If a table has no RLS, or a policy is written too widely, anyone who opens the page and reads the key can ask the API for the table's contents. That matches the pattern the researchers describe: records arriving at page load, and more on read-only requests with the same key. The report itself does not publish the exact cause per site, so we do not claim that every case is a missing policy.

This is why Wavect's advice stresses that a login screen proves nothing. The front end can hide a page while the API behind it still answers anyone. It is also why a clean automated scan is not enough on its own: scans can read configuration but cannot know your business rules, such as which tenant may see which invoice.

What it means

For people building with AI app builders, the lesson is that generated code can look finished while access control is still your job. An app that handles real customers, tickets or identity documents needs its permissions defined and tested before launch and after every significant change, which is exactly what Crissy Field recommends.

For platforms, the report revives the question that the 2025 CVE dispute raised: whether a tool that creates databases for people who may not know what RLS is should make safe settings the default. We cannot say from these sources what Lovable plans, because none of the reports we opened carries a Lovable statement on this study.

For the people whose data sat in these apps, the practical risk is phishing and identity misuse, but the researchers say they could not determine misuse, so we do not claim it happened.

What we don't know yet

• How many of the 24,664 sites were fixed, and how many were still open when the report went out.
• Lovable's response: Crissy Field's report says only that Handelsblatt contacted the company, and the reports we read do not include a statement.
• The exact cause per site, and how many cases involve Supabase misconfiguration versus other designs.
• Whether any of the data was accessed by anyone other than the researchers.
• How the sample compares with all Lovable apps; the report says it is not representative.

What to watch next

A Lovable statement or changes to its defaults for new databases, fixes by the named categories of operators, data-protection regulator interest in the affected services (the cases include a German forum and event and restaurant operators), and whether other AI app builders face similar studies.

Sources

• Crissy Field, Lovable research report (primary source)
• Techzine, Thousands of Lovable apps are leaking personal data
• Wavect, Lovable data exposure: how to prove a permissions fix
• CVE-2025-48757 record on CVEfeed