Lovable calls passport records left open in apps built on it an industry-wide problem

Crissy Field, a Hamburg application security firm, says apps built on Lovable left passport numbers, payment information and more than 200,000 chat messages readable by anyone, with no login. Lovable told Handelsblatt the problem is industry-wide, and its terms say customers are responsible for their own apps and data.

Crissy Field worked with the German business daily Handelsblatt, whose Lina Knees reported the findings on 2 November. The firm’s report carries newer figures than that story. India Today and Cybernews followed on 3 and 4 November.

What Crissy Field found

The firm used Common Crawl, a public web archive, to find 159,041 Lovable projects online between December 2025 and September 2026. Of those, 34,545 used Supabase, the hosted database service. A total of 24,664 of those sites sent database records to the browser the moment the page loaded, with no login. Crissy Field says that alone proves nothing, because some data is meant to be public. Further read-only requests, using the same key each page already hands its visitors, turned up records containing email addresses in 10,560 tables across 7,403 of the 24,664 sites.

The worst cases, in Crissy Field’s words and figures: a German lifestyle forum exposed more than 80,000 profiles with full names, email addresses, dates of birth and gender, plus more than 200,000 chat messages. One service provider exposed more than 1,000 records with passport numbers, expiry dates and nationalities. Several event organisers and restaurants exposed tens of thousands of ticket and food sales records, including email addresses, 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. Other readable content included tens of thousands of contracts and invoices, personal photo albums and internal WhatsApp messages, and in one case 280,000 emails sent to a provider’s customers. Crissy Field downloaded only parts of the datasets, so those figures are what it retrieved. It isn’t publishing how it got the data or naming the apps, and it couldn’t establish whether anyone misused any of it.

How a web page hands over a database

Crissy Field didn’t break into Lovable or Supabase. A Supabase app sends the browser a public key by design. What protects the data is row-level security, a set of rules inside the database that decide which rows each visitor can read. A table with no rule, or a rule that lets everyone through, is readable by anyone holding the page’s key. Crissy Field says database integrations on Lovable follow recurring patterns, so an approach that works against one app can work against others with little extra effort.

What the numbers don’t show

Crissy Field says the 30% (7,403 of 24,664) isn’t a confirmed leak rate. Email addresses can be public contact details or test data, and records with no email address went uncounted. Its Common Crawl sample isn’t representative of all Lovable apps. It looked only at Supabase, not at Lovable’s own database features, which launched in late 2025. It doesn’t say whether the affected apps had run Lovable’s scans, or which plans their owners were on.

Lovable’s answer

Handelsblatt’s subheadline puts Lovable’s position in one line: according to Lovable, this is an industry-wide problem. India Today, citing Handelsblatt, says Lovable told the paper the problem isn’t limited to its platform. Cybernews describes Lovable’s line as a known configuration problem with Supabase. The comparison has support: Cybernews cites a separate UpGuard scan of about 300,000 Supabase-linked domains that found readable tables on 16,326 databases, more than half with signs of personal data.

On 10 November, Lovable’s head of security, Igor Andriushchenko, published a post on Lovable’s blog and a post on X about building secure apps on the platform. Neither names Crissy Field. The blog post says “the most common issue we see in Lovable apps is data access rules that are too open”. It says scanners check row-level security policies on every publish and that a deep scan is free. Auto-fix is a setting users turn on, and publishing controls that block apps with critical findings are something Lovable “offers”. Its closing section is headed “What we still need you to do”, and it ends that section with: “your app is yours, and so is the final call on what goes live.”

The pitch and the terms

Crissy Field calls the gap between Lovable’s marketing and its terms “troubling”. Lovable’s vibe coding page says: “As long as you can describe what you’re looking to build, you can build it.” Its terms say: “You are responsible for your Customer Data and for the applications and projects you build, deploy, and make available using the Services.” Its security docs say the same about security, and add that “misconfigured RLS rules are a common cause of data leaks”.

The terms also tell customers not to put government identifiers or payment card data through the services unless their plan or a written agreement allows it. They say the standard services “are not designed to serve as a system of record for, or to provide regulatory-grade safeguards for, such data”. Crissy Field found passport numbers and payment information in apps built on Lovable. It doesn’t say whether those customers had such an agreement, or whether the data sat on Lovable’s infrastructure.

It isn’t the first report

In May 2025, researcher Matt Palmer published his findings on missing or weak row-level security in Lovable-built apps, and the record CVE-2025-48757 followed. It describes an insufficient policy that “allows remote unauthenticated attackers to read or write to arbitrary database tables of generated sites”. It also carries a note that Lovable disputes it “because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application”. Palmer wrote that the security scanner Lovable introduced afterwards “merely checks for the existence of any RLS policy, not its correctness”. Lovable’s docs now describe a scan that flags tables without row-level security and rules that let everyone through.

A separate failure was Lovable’s own. In its April 2026 incident post, Lovable says that between 3 February and 20 April 2026, backend regressions meant any Lovable user with a project link could potentially access the chat history and source code of public projects. Researchers’ reports through HackerOne, the first on 22 February, “were closed instead of being escalated” because of outdated internal documentation. Lovable’s post calls its first public response “dismissive”. Private projects and Lovable Cloud weren’t affected, it says.

Lovable’s 10 November post says a redesigned security experience and scheduled scans on all paid plans are coming this month.