The Lovable April 2026 Breach: What Got Leaked and What to Check

April 20 2026: Lovable confirmed a security incident exposing source code, database credentials, AI chat history, and customer data across every project created before November 2025.

This isn't the first Lovable security headline. May 2025 brought CVE-2025-48757, the missing-RLS disclosure that left 170+ apps with anon-key data exfiltration. February 2026 brought an independent researcher's report of 18,000 user records exposed in a single Lovable-hosted app. April 2026 is the platform-level event — different scale, same underlying pattern.

This post is the bystander's playbook. If you shipped anything on Lovable in the last 18 months, this is your eight-step audit.

1. What was leaked

Based on the public disclosure and independent reporting, the affected data includes:

• Source code for every project in scope — including any secrets that ended up in the code (Stripe keys, OpenAI keys, webhook URLs).
• Database credentials — Supabase project URLs, anon keys, and in some cases service role keys.
• AI chat history between users and Lovable's AI builder — which often includes business logic descriptions, sensitive product details, and pasted snippets of customer data the user gave Lovable as examples.
• Customer data for any app that wasn't using proper Row Level Security — which, per CVE-2025-48757, was most of them.

The chat history exposure is the one founders are underestimating. Most people don't remember what they typed into Lovable nine months ago. Go look. There are usually emails, full names, and at least one paste of a "real" record used as an example.

2. How Lovable kept missing this

After the May 2025 CVE, Lovable released "Lovable 2.0" with a "Security Scan" feature. The marketing copy said RLS was now checked. The implementation checked whether RLS was enabled, not whether the policies actually worked.

So apps with policies like USING (true) — which allow every row to every caller — passed the scan. RLS was "on." The policy was "present." Neither fact meant the data was protected.

That's the consistent failure pattern with vendor-built scanners that check their own generated code:

• They check for the syntactic shape they know how to generate.
• They miss the semantic question of whether the shape is correct for your data model.
• They give you a green checkmark that means "I generated this pattern" — not "this pattern is secure."

You need a third-party scanner that doesn't share the builder's blind spots.

3. The eight-step audit

1. Inventory. List every Lovable project you've created. For each: was it before November 2025? If yes, in scope.
2. Export your AI chat history from each project. Search for emails, phone numbers, API keys, addresses, "real" examples you pasted in. Note what was exposed.
3. Audit every Supabase table for RLS — but go deeper than "is it enabled." Open every policy. Anything using USING (true), USING (1=1), or auth.role() = 'authenticated' as the sole predicate is broken. Rewrite to scope by auth.uid() or a real tenancy field.
4. Audit GRANTs. Run SELECT * FROM information_schema.role_table_grants WHERE grantee = 'anon'. Any INSERT / UPDATE / DELETE on tables that should be read-only is a hole.
5. Find service-role usage in client routes. Grep for SUPABASE_SERVICE_ROLE_KEY. Every reference should be in a server-only file (API route, server action, edge function) behind an auth check.
6. Find secrets in client bundles. Look for NEXT_PUBLIC_ / VITE_ prefixes followed by anything that ends in _KEY, _SECRET, _TOKEN. Move them server-side.
7. Check your Supabase audit logs. Anything unusual in the last six months — large reads from unfamiliar IPs, mass-export queries, schema changes you didn't make?
8. Notify users if PII was exposed. Required by GDPR for EU residents within 72 hours of awareness; by CCPA for California; by various state laws elsewhere. Use the template at your jurisdiction's data-protection authority.

4. Credential rotation order

Rotate in this order — bigger blast radius first:

1. Supabase service role key (full database admin)
2. Supabase JWT secret (forges any auth)
3. Stripe secret keys + webhook signing secrets
4. Any AI provider keys (OpenAI, Anthropic) — re-issue at the provider, not just from Lovable
5. Email provider keys (Resend, Postmark, SendGrid)
6. OAuth client secrets (Google, GitHub, etc.)
7. Supabase anon key (lower urgency — RLS is the actual protection; rotating anon doesn't help if RLS is broken)

For each: rotate at the provider, update your env, redeploy, then watch the old key's access logs for 24 hours for anyone trying to use it.

5. What to do differently going forward

• Don't trust the builder's security scan. Use a third-party scanner. Lovable's checks the syntactic shape; an external scanner asks whether the shape is correct.
• Treat AI chat history as compromised by default. Don't paste real data into AI builder chats. Use synthetic examples for anything sensitive.
• Export and back up your code regularly. If a vendor goes through a breach, you want your own copy not held hostage.
• Pin RLS policies to your specific user model. The default templates almost never match your tenancy correctly. Write your own.
• Run a scan after every major Lovable-generated change. The vulnerability rate per generation is too high to skip review.

More context on what Lovable typically gets wrong: 5 Security Vulnerabilities Every Lovable App Has and Your Supabase App Has No Row Level Security.

The bottom line

The April 2026 breach didn't introduce new vulnerability classes. It compounded the ones the ecosystem was already missing — RLS that's "on but doesn't work," service-role keys in client-reachable code, AI chat history with pasted production data. The fixes are not exotic. They are not optional.

If you shipped on Lovable before November 2025, do the eight-step audit this week, not next quarter.