1 in 10 scanned Lovable apps would hand your data to anyone who asked the database directly
- Date
- May 29, 2025
- Tools involved
- Lovable
- Impact
- 170 of 1,645 scanned apps (~10%) exposed names, emails, financial info, and secret API keys, with 303 vulnerable endpoints; CVE-2025-48757
- Root cause
- Lovable-generated apps made direct browser-side Supabase calls with a public anon key, relying entirely on Row Level Security policies that were missing or misconfigured
What happened
On May 29, 2025, Semafor published a story with a headline that aged into prophecy: 'The hottest new vibe coding startup Lovable is a sitting duck for hackers.' It centered on research by Matt Palmer, a Replit employee, who scanned 1,645 web apps built with Lovable. Of those, 170, roughly 10 percent, allowed anyone to access sensitive data: names, email addresses, financial information, and secret API keys for services like Stripe, Google Maps, and Gemini.
The root cause was architectural rather than a single bug. Lovable-generated apps made direct REST API calls to Supabase from the browser using a public anon key. That design is workable only if Row Level Security policies are correctly configured on every table, because RLS is the entire protection layer. When RLS was missing or misconfigured, which it frequently was, unauthenticated visitors could query sensitive tables directly. The pattern was assigned CVE-2025-48757.
The timeline did Lovable no favors. Palmer reported the issue on March 21, 2025. After roughly two months without a full fix, he published his findings and the CVE on May 29. Lovable initially downplayed the problem, then later shipped a limited security scanner that could detect whether RLS was enabled but not whether it was configured correctly, which is a bit like a smoke detector that confirms you own a fire extinguisher.
The episode became the archetypal 'vibe-coded apps leak data' story, cited in nearly every subsequent piece on AI-generated app security, and a direct precursor to Lovable's larger breaches in 2026. The lesson it planted: when a platform generates the same architecture for thousands of apps, it also generates the same vulnerability for thousands of apps.
Impact
Of the 1,645 Lovable-built apps scanned, 170 (about 10 percent) exposed sensitive data to anyone who queried their Supabase backend, across 303 vulnerable endpoints. The exposed data included names, email addresses, financial information, and secret API keys for services like Stripe, Google Maps, and Gemini, meaning attackers could both read user data and run up bills or take actions on the app owner's paid accounts. The systemic finding mattered more than any single app: one in ten shipped apps was open by default, tracked as CVE-2025-48757.
Root cause
Lovable generated apps that called Supabase's REST API straight from the browser using the public anon key. In that architecture there is no server between the user and the database, so Row Level Security policies are the only thing standing between an anonymous visitor and every table. Where RLS was missing or misconfigured, the database answered any query the browser could send. The report went in on March 21, 2025; the CVE and public findings landed May 29 after about two months without a full fix, and Lovable's follow-up scanner checked only that RLS was enabled, not that the policies were right.
How to not be this entry
- Enable Row Level Security on every table and treat a table without policies as publicly readable, because with a browser-side anon key architecture, it is. Read the fix guide: Supabase Row Level Security is off: your whole database is readable with the anon key
- Test as a stranger, not as yourself. Take only your app's public anon key, query your Supabase REST API unauthenticated, and confirm each sensitive table returns nothing. This is exactly the scan that found the 170 apps. Read the fix guide: Lovable Supabase RLS not enabled: anyone can read your app's data (CVE-2025-48757)
- Keep secret API keys (Stripe, Gemini, Google Maps) out of client-side code and out of publicly readable tables. A leaked secret key is an open tab on your credit card. Read the fix guide: Lovable API key exposed: secrets visible in your client-side code
- Do not stop at 'RLS enabled.' Enabled with wrong policies still leaks; write policies per table, then verify what each role can actually read and write. Read the fix guide: 'new row violates row-level security policy' in Supabase (403 / error 42501)
Tools that actually fix this
Recommended because they address the failure mode above, not because of the payout. Some are affiliate links; see how we choose.
If your AI-built app uses Supabase, Row Level Security is the actual fix for exposed data, and it is free. The dashboard's Security Advisor lists every table you left open.
Try Supabase →Drop-in authentication that handles sessions, tokens, and protected routes properly, so you stop shipping the hand-rolled auth an AI guessed at. Generous free tier for a real app.
Try Clerk →Frequently asked questions
What is CVE-2025-48757?
CVE-2025-48757 is the vulnerability pattern found in apps generated by the Lovable vibe coding platform, published on May 29, 2025. Lovable-generated apps made direct browser-side calls to Supabase with a public anon key and relied entirely on Row Level Security policies; where those policies were missing or misconfigured, anyone could query sensitive tables directly.
How many Lovable apps were leaking data in 2025?
A scan of 1,645 Lovable-built web apps found 170, about 10 percent, exposing sensitive data across 303 vulnerable endpoints. The exposed data included names, email addresses, financial information, and secret API keys for services like Stripe, Google Maps, and Gemini.
Who discovered the Lovable data leaks?
The Lovable data leaks were discovered by Matt Palmer, a Replit employee, who scanned 1,645 Lovable-built apps and reported the issue to Lovable on March 21, 2025. After roughly two months without a full fix, he published his findings and CVE-2025-48757 on May 29, 2025, the same day Semafor covered the story.
Did Lovable fix the RLS vulnerability?
Lovable initially downplayed the problem and later shipped a limited security scanner that could detect whether Row Level Security was enabled on a table but not whether the policies were configured correctly. The May 2025 episode became a precursor to Lovable's larger security incidents in 2026.
Is Supabase to blame for the Lovable leaks?
The vulnerable component was the generated apps, not Supabase itself. Supabase's browser-side anon key model depends on correctly configured Row Level Security policies, and Lovable's generated code relied entirely on RLS while frequently shipping without correct policies, which left tables open to unauthenticated queries.
Sources
- Semafor: The hottest new vibe coding startup Lovable is a sitting duck for hackers
- Superblocks: Breakdown of the Lovable vulnerabilities
- NVD: CVE-2025-48757 entry
Related error guides
Lovable Supabase RLS not enabled: anyone can read your app's data (CVE-2025-48757)
Supabase Row Level Security is off: your whole database is readable with the anon key
Lovable API key exposed: secrets visible in your client-side code
'new row violates row-level security policy' in Supabase (403 / error 42501)
The Vibe Oops briefing
One email when something ships to production that should not have. New incidents, new error guides, no filler.