Lovable's April 2026 Security Incident: What to Check

Short answer: if you built an app with Lovable, two separate things could have gone wrong. The first is the April 2026 incident, in which Lovable has confirmed that the source code and chat history of public projects were accessible to other Lovable users for about eleven weeks. The second is older and more common: the database rules inside your own app, which Lovable's incident did not cause and did not fix. This post separates the two, sticks to what has been confirmed, and ends with the five checks to run today.

We run a Lovable app rescue service, so we have an interest in people worrying about this. We have therefore kept to Lovable's own statements and named news coverage, and we say where a claim is unverified.

What Lovable has confirmed

Lovable published its account on 22 April 2026. The confirmed facts:

• The window. Between 3 February and 20 April 2026, the chat history and source code of public projects could be accessed by any Lovable user who had the project link.
• The cause. Lovable says backend regressions in February "re-enabled public access to chat history and source code on public projects."
• The missed reports. Researcher reports filed from 22 February were closed rather than escalated, which Lovable attributes to outdated internal documentation at its bug bounty programme.
• The fix. Lovable says it shipped a fix within two hours of the public disclosure on 20 April, reverted the regression, and has since made historically public projects private, apart from its official templates.
• What was not affected. Lovable states that private projects and Lovable Cloud were never impacted, and that new projects have been private by default since December 2025.

Lovable has not published the number of projects or users involved. It says it is reviewing which public projects were viewed and will contact the owners.

What researchers and reporters say

The incident became public on 20 April 2026 when a researcher posting as @weezerOSINT showed that a free Lovable account could read other users' source code, database credentials and chat histories. Coverage in The Next Web and Fast Company adds detail that Lovable's statement does not:

• The Next Web reports that the researcher filed the flaw with Lovable's bug bounty programme on 3 March, that Lovable patched it for new projects but not existing ones, and that a follow-up report was closed as a duplicate. By the time of publication the flaw had been open for 48 days.
• The same report describes hard-coded Supabase database credentials in exposed source code, and a Danish nonprofit whose real user records, including Stripe customer IDs, were reachable.
• Fast Company reports that Lovable's first response on 20 April was that no data breach had occurred and that access to public projects' code was intended behaviour, followed later the same day by a partial apology and a retroactive API patch.

One point of disagreement to be clear about: the researcher's claim that every project created before November 2025 was exposed is not confirmed by Lovable, whose statement covers public projects only. Treat the broader scope as reported, not established.

The older problem: your own database rules

The April incident was about Lovable's platform. A separate and more widespread issue sits inside the apps themselves.

In May 2025, CVE-2025-48757 was published against Lovable-generated apps. It describes insufficient row-level security (RLS) in the Supabase databases those apps use, allowing "remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." It carries a CVSS score of 9.3, which is critical. Lovable disputes the record, arguing that securing application data is each customer's responsibility. Third-party scans at the time reported that roughly 170 of 1,645 sampled Lovable apps exposed personal data; those counts come from researchers, not from the CVE record.

Whoever is responsible, the practical point stands: a Lovable app talks to its database directly from the browser, and the only thing protecting each user's data from every other user is the RLS policy on each table. If a table has RLS switched off, or a policy that allows everything, anyone with your app's public key can read it. Lovable's platform fix in April did nothing to change this inside your app.

The five checks to run today

These take an hour and need no code changes to perform. Our Lovable production checklist covers the full twelve points; these are the ones the incident makes urgent.

1. Was your project public at any point between February and April 2026? If so, assume its source code and chat history were readable. Check your project's visibility setting now, and remember that project visibility and the published website URL are separate settings.
2. Rotate every secret that was ever in the code or the chat. Supabase service-role key, Stripe secret key, AI provider keys, email provider keys. If you pasted a key into a Lovable prompt while building, it lived in the chat history. Rotate it even if the code no longer contains it.
3. Confirm RLS is on for every table. Open your Supabase dashboard; it flags tables without RLS. Any table holding user data with RLS off is readable by anyone who opens your app.
4. Test your policies as two different users. RLS being enabled is not the finish line. Sign in as two test accounts and confirm neither can read or change the other's records. A policy that always evaluates to true protects nothing.
5. Search your live app for private keys. Open the browser's developer tools on your published app and search the loaded JavaScript for service_role, sk_live and sk-. Anything you find is public.

If any of these fail, fix the database and secrets before anything else. Features can wait; an open table cannot.

Does this mean you should stop using Lovable?

No. The April incident was a platform failure that Lovable has acknowledged and fixed, and the database issue is a property of how fast, browser-to-database apps are built, not of Lovable alone. Apps built with Bolt, Replit, v0 and Cursor show the same gaps when nobody checks.

What the incident does show is that "it works in the demo" and "it is safe to put customer data in" are different standards, and that the second one is nobody's job unless you make it someone's. If your app already has real users and you are not sure where it stands, our Lovable app rescue service starts with a fixed-price audit of exactly these points, and the report is yours whether or not we do the fixes. The same process exists for Bolt, Replit and other AI-built apps.

Sources

• Lovable, Our response to the April 2026 incident, 22 April 2026
• The Next Web, Lovable security crisis: 48 days of exposed projects, 21 April 2026
• Fast Company, Lovable left AI prompts and user data exposed, one researcher found, 21 April 2026
• NVD / Intruder, CVE-2025-48757, published 30 May 2025

We will update this post if Lovable publishes the number of affected projects or further findings. Last checked 31 October 2026.