# Lovable AI Data Leak: 200K Messages Exposed [2026]

> Researchers analyzed 159,041 Lovable apps and found ~4,000 leaking passport scans and 200K+ private messages. Here's what went wrong and how to check your own app.

- Canonical: https://www.kunalganglani.com/blog/lovable-ai-app-data-leak
- Author: Kunal Ganglani
- Published: 2026-11-14 · Updated: 2026-11-14
- Category: Cybersecurity · Tags: vibe-coding, data-leak, ai-app-builders, security, supabase

## TL;DR

Thousands of apps built on the no-code AI platform Lovable were handing out their users' private data to anyone who looked. Security researchers scanned 159,041 of these apps and found about 4,000 exposing passport photos and more than 200,000 private messages, no hacking required, just a browser's built-in developer tools. The cause is a database security setting that is switched off by default, so the app looks like it works perfectly while quietly being public. If you built an app this way, you can check it yourself in under five minutes, and you probably should today.

## Lovable AI Data Leak: 200K Messages Exposed [2026]

Security researchers at [Crissy Field GmbH](https://www.crissyfield.de/research/lovable-en/) analyzed 159,041 apps built on Lovable and found roughly 4,000 of them leaking sensitive personal data, including passport scans and more than 200,000 private user messages, to anyone who opened a browser's developer tools. The Lovable AI app data leak, disclosed alongside German outlet Handelsblatt on November 2, 2026, needed no exploit, no stolen credentials, and no malware. It needed the Network tab.

![An open padlock surrounded by scattered black computer keyboard keys under red and green light](https://cdn.sanity.io/images/vzekdneq/production/a1e71cb39354a8a283d3a2e76332dba0bdca92c0-1200x675.webp)

I've been writing about this exact failure mode for over a year. This is the loudest confirmation yet that it was never theoretical. And the scary part isn't the headline number. It's how boring the attack was.

## What is the Lovable AI app data leak

The Lovable AI app data leak is a mass data-exposure incident in which thousands of apps built on the Lovable platform served their backend database contents directly to the browser with no login required. Lovable is a Stockholm-based vibe coding platform, founded in 2023 by [Anton Osika](https://lovable.dev) and Fabian Hedin out of Osika's earlier open-source project GPT Engineer, and relaunched publicly in November 2024. It lets non-technical people describe an app in plain English and ship it with a working database behind it.

![A computer screen with the words back the web on it](https://cdn.sanity.io/images/vzekdneq/production/6336ad5960f07aab77df239f52758f578e89af24-1200x675.webp)

The research method was deliberately unglamorous. Over roughly ten months, from December 2025 to September 2026, the Crissy Field team pulled 159,041 Lovable projects out of the Common Crawl public web archive. Of those, 34,545 used Supabase as their backend. And 24,664 of those Supabase-backed apps shipped database records straight to the browser the moment the page loaded, with no authentication step in between.

From there the researchers made additional read-only API requests using the same key that every visitor's browser already had. That one move surfaced email addresses in 10,560 database tables across 7,403 websites, which is 30% of the sites that leaked data on load. A classifier tuned to an 85% confidence threshold then flagged the privacy-sensitive subset: roughly 4,000 apps, or 15.9% of every Lovable app using Supabase, exposing passport images, private messages, and more.

The researcher posting on Hacker News under the handle neathack was blunt about the difficulty. No advanced hacking techniques were used, they wrote, and anyone with a moderate understanding of how the web works can reproduce the results. There is no CVE here. There is a Network tab and a bit of curiosity.

## What data was exposed: passports, 200K messages, and emails

The word "leak" undersells what was sitting in the open. The exposed records included government identity documents and the kind of personal conversations people assume are private.

![a computer keyboard with a padlock on top of it](https://cdn.sanity.io/images/vzekdneq/production/3f73984f11cd39c4c27b14d1a526c33ec1f6f639-1200x675.webp)

Based on the published findings, the categories of exposed data break down like this:

- **Passport scans** uploaded by end users of the affected apps, a textbook example of special-category personal data.
- **More than 200,000 private user messages**, the contents of which the researchers chose not to republish.
- **Email addresses** in 10,560 tables across 7,403 sites, the broadest single category by volume.
- **Full table dumps** returned on page load across 24,664 apps, meaning whatever those tables held was readable.
- **Implied sensitive verticals** such as travel, dating, and medical-adjacent apps, inferred from the data shapes rather than named, to avoid re-exposing anyone.
And the researchers were explicit that this is a floor, not a ceiling. They only looked at Supabase integrations, the most common backend among Lovable projects, and deliberately skipped Lovable's own native database feature introduced in late 2025. The real blast radius is almost certainly larger than 4,000 apps.

## Why Supabase row-level security keeps biting AI app builders

Here's the thing nobody's saying clearly enough: this is not a Supabase bug. Supabase worked exactly as designed. The design just happens to be a trap for people who don't know it's there.

Supabase exposes your Postgres database through an auto-generated REST API, and it protects individual tables using Postgres row-level security (RLS). RLS decides which rows a given request is allowed to read or write. The catch, documented plainly in the [Supabase RLS guide](https://supabase.com/docs/guides/database/postgres/row-level-security), is that RLS is opt-in. When you create a table, policies are off until you turn them on. A table with no enabled policy and a public API is readable by anyone holding the anon key, and the anon key ships inside every visitor's browser by design.

Now layer the vibe coding workflow on top. A non-technical builder tells Lovable to "make a form that saves user submissions," tests it, sees their data appear, and ships. The app works. It works whether or not RLS is enabled, because the person building it is always authenticated enough in testing to see their own rows. A working app gives you zero signal that the table is public. That is the entire failure, in one sentence.

This ambiguity runs across the whole category of [AI no-code app builders](/blog/ai-no-code-app-builders-compared). The platforms are genuinely impressive at generating a functional CRUD app in minutes. What none of them does well is make the security posture of the generated backend obvious to someone who can't read the code. The default is permissive, the UI celebrates the happy path, and the one setting that matters is a toggle buried in a dashboard the builder was told they'd never need to open.

This is why I keep hammering the point in my writing on [vibe coding](/blog/vibe-coding-best-practices-2026) and in the deeper [AI security](/blog/ai-security-complete-guide) material. The convenience that makes these tools viral is the same convenience that hides the one decision you cannot afford to get wrong.

## Lovable's response and the shared-responsibility gap

The researchers disclosed the full dataset to Lovable before publication, working with Handelsblatt reporter [Lina Knees](https://www.handelsblatt.com), whose report ran on November 2, 2026. So the company had the findings in hand ahead of the news cycle.

The more revealing detail is structural. Lovable's Terms and Conditions place responsibility for application security and data handling squarely on the customer, while the product's entire marketing promise is that no technical knowledge is required. You cannot hold both of those positions honestly. If your pitch is "anyone can build an app, no expertise needed," then your user base is, by definition, people without the expertise to configure row-level security correctly. Pushing liability onto them in the fine print is a shared-responsibility model where only one side knows the responsibility exists. Hacker News commenter Oras put the practical version well: these AI-generated apps are an easy target precisely because the average user doesn't know what they're using or how risky it can be.

The legal exposure is not abstract either. Passport scans and private messages are special-category personal data under the GDPR, and the research was run by a German firm with a German outlet. Thousands of EU site owners may now be sitting on breach-notification obligations they don't know they have, for an incident they didn't know happened.

## How to check if your own AI-built app is leaking data

If you shipped anything on Lovable, Bolt.new, Base44, or Replit that stores user data, stop reading and run this check. It takes under five minutes and needs no tools beyond the browser you already have.

1. **Open your live app** in Chrome or Firefox, logged out, in a private window so your session doesn't mask the problem.
1. **Open developer tools** (F12 or right-click then Inspect) and switch to the **Network** tab.
1. **Reload the page** and watch the requests. Filter for `supabase.co` or `/rest/v1/`.
1. **Click any request that returns a JSON array** of your records. If you can see rows of real user data while logged out, those rows are public to the entire internet.
1. **Try changing the table name** in the request URL to another table you know exists. If that returns data too, RLS is off across the board, not just on one table.
1. **Fix it in Supabase:** enable row-level security on every table, then write explicit policies for who can read and write each one. Deny by default, allow deliberately.
If step four returned your users' data, treat it as a live breach, not a hypothetical. Rotate anything sensitive, enable RLS immediately, and work out your notification obligations. For a structured version of that cleanup, the [LLM data leakage playbook](/blog/llm-data-leakage-playbook) and this [AI-generated code review checklist](/blog/review-ai-generated-code-checklist) both walk through the containment and audit steps in order.

## What the Lovable data leak means for vibe coding

This incident is not an outlier. It's the pattern finally showing up at scale.

Exposed API keys and secrets in AI-generated apps have been reported by security researchers throughout 2024 and 2025, and I documented a stack of them in [the vibe-code security nightmares](/blog/vibe-code-security-nightmares) piece and again when I [audited vibe-coded applications](/blog/vibe-coding-security-audit-nightmares) directly. The same root cause recurs. Generated code that runs is assumed to be code that's safe, and nobody with security instincts ever reads it. It's the same blind spot that makes [prompt injection](/blog/repository-prompt-injection-coding-agent) so effective against coding agents: the system does exactly what it's told, and nobody audits what it was told.

Vibe coding, a term coined by [Andrej Karpathy](https://x.com/karpathy) in early 2025, was always going to collide with production reality. The tooling got non-engineers to a deployed app faster than anyone expected. What it did not do was get them to a secure one.

Running this blog's own multi-agent publishing pipeline across 261+ posts taught me the lesson that applies directly here: defaults and automated gates decide outcomes, good intentions don't. The deterministic SEO quality gate I run before any model review catches more issues than doubling the size of that review model would, precisely because it always runs and never gets skipped. Lovable's problem is the mirror image. The one check that mattered was optional, and optional checks don't run.

Until the defaults flip from permissive to deny-by-default, with RLS on at table creation and a loud warning when a public API meets an unprotected table, these builders are shipping landmines with a smiley face on them.

My prediction: the next Lovable-scale disclosure won't be about Supabase at all. It'll be about a platform's own native backend, the one this research deliberately skipped, and the numbers will be worse because the audit tooling for it doesn't exist yet. If you build on these tools, or you lead a team that does, treat the Network-tab check as a mandatory pre-launch gate today, and fold backend security into how you think about [AI in production](/pillars/ai-engineering-production) and [AI security](/pillars/ai-security-safety) before the regulators do it for you. The window to fix this quietly is closing.

Photo by Sasun Bughdaryan on Unsplash.