Same misconfiguration. Three headlines, a year apart. The default never moved.
I spent this week reading disclosure reports instead of writing code, chasing something that kept nagging at me: every "vibe-coded app leaks data" headline this year describes the same bug.
May 2025 — 170 apps, one CVE
A researcher discloses CVE-2025-48757 — 170 apps built on Lovable, 303 endpoints, exposing arbitrary database tables to anyone who asked. Root cause: Lovable's generated Supabase projects shipped with Row Level Security off by default. The public anon key sitting in the client JS was enough to read or write any table. CVSS 9.3. Lovable disputed the severity — their stated position was that protecting the data is the customer's responsibility. Fair or not, they updated the code-generation pipeline to include RLS by default soon after.
January 2026 — one app, 1.5 million tokens
Moltbook launches, a social network for AI agents. Three days later, Wiz finds the same shape of hole in a different stack entirely: a Supabase key exposed in client-side JavaScript, no RLS. Not 170 apps this time — one. But it was 1.5 million agent API tokens, tens of thousands of email addresses, and over 4,000 private conversations, all readable by anyone who found the key. Fixed within a day of disclosure.
May 2026 — 380,000 apps, one pattern
RedAccess scans 380,000 public assets built on vibe-coding platforms — Lovable, Base44, Replit, and Netlify deployments among them. Roughly 5,000 look like real corporate deployments. Roughly 2,000 of those are leaking something: medical records, bank financials, customer chat logs, internal strategy documents. The report's own framing isn't "these tools are insecure" — it's blander and worse: new projects default to publicly accessible, and the people building on them have no reason to know that's what "default" means.
Three different platforms, three disclosures compressed into about a year, and it's the same bug every time: a database that assumes someone locked the door, generated by a tool whose entire premise is that you shouldn't have to know there's a door.
The failure isn't in the code
This isn't an argument for "don't vibe-code." The application code these tools write is usually fine. The failure sits one layer down, in a decision nobody in the loop is positioned to make: does this table need a policy restricting who can read it? A developer learns to ask that question by getting burned once, early, in a context where the blast radius is a Slack channel — not 35,000 email addresses. Someone who described an app in plain English and got a working one back was never in the room where that lesson gets taught.
Every fix I read about, after the fact, is the same fix: turn RLS on, rotate the keys, audit the tables you didn't know existed. None of it is hard. All of it requires knowing to look — and "knowing to look" is exactly the expertise these tools are selling you out of needing.
The honest fix isn't a security checklist bolted onto onboarding. It's not connecting a database straight to the public internet in the first place — an architecture decision, not a discipline problem. Every platform in these three reports made the opposite trade: reachable by default, secured by configuration, if you knew to configure it. Until that flips, the leak wave isn't a phase. It's the default setting, working exactly as built.
Sources: CVE-2025-48757 (NVD), disclosed 29 May 2025. Wiz Research, "Exposed Moltbook Database Reveals Millions of API Keys," disclosed 31 Jan 2026, remediated 1 Feb 2026. RedAccess "Shadow Builders" report, published May 2026, as covered by The Hacker News, VentureBeat and Security Boulevard. Figures as reported at publication; exact sub-counts vary slightly across outlets covering the same disclosures.
FAQ
Why do vibe-coded apps leak data?
Overwhelmingly, the same root cause across every documented case: the app's database (usually Supabase) is created with Row Level Security off, and the public API key needed by the client app is enough on its own to read or write any table. It isn't a hacking problem. It's a database left reachable, with no policy restricting who can query it, by default.
What is CVE-2025-48757?
A disclosed vulnerability affecting Lovable-generated applications: an insufficient Row-Level Security policy that let remote, unauthenticated attackers read or write arbitrary database tables. Disclosed 29 May 2025, scoped to 170 apps and 303 endpoints at the time, CVSS 9.3. Lovable disputed the severity, and later updated its code generator to include RLS by default.
What happened with Moltbook?
Moltbook, a social network for AI agents, launched in late January 2026. Within days, security researchers at Wiz found a Supabase API key exposed in the client-side JavaScript with no Row Level Security enabled, exposing roughly 1.5 million agent API tokens, tens of thousands of email addresses, and thousands of private agent-to-agent conversations. It was fixed within about a day of disclosure.
How widespread is the vibe-coding data exposure problem?
A May 2026 scan by security firm RedAccess ("Shadow Builders") checked 380,000 public assets built on vibe-coding platforms including Lovable, Base44, Replit and Netlify. Roughly 5,000 looked like real corporate deployments, and roughly 2,000 of those were leaking something sensitive - medical records, financial data, or internal chat logs - with no exploit required, just the public URL.
How do I check if my AI-built app is exposed?
If your app uses Supabase (or a similar backend-as-a-service) and you didn't explicitly configure Row Level Security policies, assume it's off. Check the dashboard's authentication/policies section for each table, rotate any API keys that have been public, and confirm the anon/public key can't read tables it shouldn't.
Made with FOKL — little apps your family keeps.