Lovable Apps Exposed Passports and Private Chats. The Fixes So Far Don’t Close Existing Leaks

What the Researchers Found

Crissy Field took 159,041 Lovable projects from the Common Crawl web archive, covering December 2025 to September 2026. Of those, 34,545 stored their data with Supabase, the database service Lovable apps most often use.

On 24,664 of those sites, the page sent database records as soon as it loaded, with no login. That can be harmless, since a menu or event list is meant to be public. But with further read-only requests using the same public key, the researchers found tables holding email addresses on 7,403 sites, 30% of the ones they checked.

The worst cases they describe:

• a German lifestyle forum with more than 80,000 profiles (full name, email, date of birth, gender) and over 200,000 chat messages
• event organisers and restaurants with tens of thousands of ticket and food orders, including phone numbers, postal addresses, payment information and ticket codes
• a property manager’s AI-written summaries of internal emails about tenants and owners
• a service provider with more than 1,000 identity-document records
• tens of thousands of contracts and invoices, photo albums, internal WhatsApp messages, and in one case 280,000 emails sent to a company’s customers

Crissy Field is careful about its own numbers. The 30% is not a leak rate, because an email address can be a public contact or test data, and the Common Crawl sample doesn’t represent every Lovable app. It downloaded only parts of each dataset, doesn’t name the apps, and couldn’t tell whether anyone had misused the data. Handelsblatt reported that it received the first tips in mid-August and that the data had been reachable for at least a year.

Why It Keeps Happening

Lovable writes the app, but the person who asked for it decides who may read what. Supabase lets a web page talk to the database directly, with a key that sits in the page’s code where anyone can see it. What keeps strangers out is a set of database rules called Row Level Security. Supabase’s own guidance is to switch it on for every table the app exposes. Where it’s off, or the rules are too loose, the public key opens the table.

This isn’t new. A researcher reported the same pattern in Lovable apps in 2025, and it became CVE-2025-48757. Lovable disputed it, on the grounds that each customer is responsible for protecting their app’s data. In September 2026, UpGuard counted 16,326 Supabase databases with readable tables across the web, built with all kinds of tools.

Lovable’s answer has stayed close to that line. It told Handelsblatt this is a known configuration problem across the industry. Its security documentation says the same: “You are responsible for ensuring that your app meets the security requirements appropriate for its use case.” Yet the platform’s pitch is that you don’t need to know how to code. Lovable says it delivers 1.2 million new projects a week, and its builders are exactly the people who’ve never heard of Row Level Security.

What Lovable and Supabase Have Changed

Two changes, and neither reaches data that is already exposed.

Supabase stopped making new tables reachable through its public API automatically. The change reached all existing projects on 30 October, days before the report. A new table now needs an explicit grant before the page can query it. But the changelog is clear that existing tables “keep their current grants and stay reachable.” An app that was leaking on 29 October still leaks unless someone fixes it.

Lovable added a step on 12 November, according to its changelog. When someone publishes a project on Lovable’s built-in backend with unresolved critical security findings, Lovable now asks them to review the findings first. They can still choose “publish anyway”. Only Enterprise workspaces can block publishing outright. The free Quick scan runs when the publish window opens, so an app nobody touches again isn’t checked again.

Lovable’s changelog lists no other change up to 14 November that would close tables already open.

Is Your Data in One of These Apps?

You probably can’t tell from the outside. Crissy Field doesn’t name the apps, and with a paid plan an app can run on any domain. Apps on Lovable’s own hosting run at an address ending in lovable.app.

What helps:

• Think about small new services. A ticket shop for a local event, a restaurant’s order page, a booking form, a community forum or a waiting list launched in the past two years is the kind of app the report describes.
• Ask the operator. Under the GDPR, any business that holds your data in the EU must tell you what it holds when you ask (Article 15). You can also ask what it uses to build and host the service.
• If you shared an ID document, treat it as exposed until the operator says otherwise. A passport number can’t be changed like a password, so watch for messages that quote your ID details back at you, and ask your bank or mobile provider whether they offer an extra check on new accounts.
• Expect convincing phishing. Leaked order data lets a scammer write “your ticket for Saturday” with the right name and address. Check any request for payment or login through the official site, not the link in the message.

If You Built an App With Lovable

Run the Deep scan in Lovable’s Security view; it’s free, and it isn’t automatic. Then open Supabase’s Security Advisor and fix every table it flags, starting with any that hold personal data. Check that Row Level Security is on and that no rule lets the public key read other people’s rows. Never put Supabase’s secret (service role) key in the app’s front end.

If personal data was exposed, the law treats it as your breach, not Lovable’s. Under the GDPR, you have 72 hours from when you become aware of a breach to report it to your data protection authority (Article 33), unless it’s unlikely to put people at risk. If the risk is high, as with ID documents or payment details, you must also tell the people affected (Article 34). Crissy Field’s advice for anything that handles customer data is a professional review before it goes live, and again after big changes.