Why Vibe-Coded Apps Die in Production: The 2025–26 Evidence

Vibe coding — describing an app to an AI and shipping whatever comes out — has produced a wave of real products built by people who never wrote a line of the code they deployed. Some of those products make money. Many of them are also, quietly, wide open.

This isn't a hot take. Over the past year and a half, the failure pattern has been documented by peer-reviewed academic benchmarks, formally disclosed CVEs, and security scans of thousands of live applications. I went through that evidence and had every claim adversarially fact-checked against primary sources. This post is what survived.

The short version: vibe-coded apps don't usually die because the AI wrote code that doesn't work. They die because the AI wrote code that works — and silently skipped the authorization layer. And the person who shipped it couldn't tell the difference.

The 48-hour case study

The canonical story is Enrichlead, in March 2025.

On March 15, 2025, founder leo (@leojr94_) announced a paying SaaS on X: "my saas was built with Cursor, zero hand written code. AI is no longer just an assistant, it's also the builder."

Two days later — the tweet timestamps are verifiable from the post IDs — he posted again: "guys, i'm under attack... maxed out usage on api keys, people bypassing the subscription, creating random shit on db... I'm not technical so this is taking me longer that usual."

Unpack that one tweet and you find four distinct failures: exposed API keys, missing authorization on paid features, a database anyone could write to, and — the one that sealed it — a builder who couldn't read the code well enough to respond. His follow-up posts admitted the API endpoints had shipped with no authentication at all. The product went offline within roughly a week of launch.

One anecdote proves nothing on its own. What makes Enrichlead worth telling is that every failure it exhibited shows up, at scale, in the systematic research.

Failure mode 1: The database has no lock

The single most documented failure in vibe-coded apps is missing authorization — specifically, missing Row-Level Security (RLS) on Supabase-backed apps.

Here's the mechanism. Platforms like Lovable, Bolt, and v0 typically generate a frontend that talks directly to a Supabase database using a public "anon key" embedded in the client-side JavaScript. That's by design, and it's safe — if RLS policies are configured to restrict what each user can see and change. The AI generators routinely skip that step. The result is a production database that any visitor can query, and often write to, with no login.

This got a formal designation: CVE-2025-48757 (CVSS 9.3, disclosed May 29, 2025), covering Lovable-generated apps whose databases allowed "remote unauthenticated attackers to read or write to arbitrary database tables of generated sites." The researchers behind the disclosure scanned 1,645 apps from Lovable's own showcase and found 303 vulnerable endpoints across 170 of them — roughly one in ten — exposing names, emails, third-party API keys, and financial records, including the ability to modify payment status.

And it kept happening after disclosure. A June 2026 scan of 1,072 live vibe-coded apps (built with Lovable, v0, Bolt.new, Replit, Windsurf, and Tempo) found 172 apps where anyone could delete database records without logging in, and another 172 that allowed unauthenticated modification.

Failure mode 2: Secret keys shipped to the browser

The same June 2026 scan found exposed Supabase keys in client-side JavaScript on 308 of 1,072 apps — its single most common high-severity finding. An independent scan by Escape of 5,600+ vibe-coded apps found 400+ exposed secrets. And in January 2026, the "Chat & Ask AI" app was found running a Firebase instance configured with allow read: if true — exposing roughly 406 million records.

Exposed keys are what turned Enrichlead's launch week into a bill: attackers maxed out his API usage limits within two days.

Failure mode 3: User data spills at scale

When these apps hold real user data, the failures stop being abstract. In July 2025, the Tea app — a women's safety app that required government-ID verification — suffered two breaches in one week: an unprotected storage bucket exposed ~72,000 images including ~13,000 ID photos, and days later an API endpoint with no per-user authorization let any logged-in user pull over 1.1 million private messages.

An honest caveat: Tea's codebase hasn't been publicly confirmed as AI-generated. But the flaw class — an unconfigured backend-as-a-service, authentication present but authorization absent — is exactly the signature the vibe-coding scans keep finding. Escape's scan of production vibe-coded apps separately documented 175 PII exposures, including medical records and bank account numbers.

Failure mode 4: The code is insecure at the source — and models aren't fixing it

You might assume this all gets solved by better models. The longitudinal data says no.

Veracode has been benchmarking LLM code generation since 2023 — now covering 150+ models across the same 80 tasks. Their Spring 2026 update: only 55% of generation tasks produced secure code, even as syntax correctness climbed past 95%. The security pass rate has been flat between 45–55% since 2023, across GPT-5.x, Gemini 3, and Claude 4.5/4.6. Newer models write prettier code, not safer code.

The peer-reviewed benchmarks are harsher, because they measure the gap that actually kills apps — the gap between "works" and "safe":

On SusVibes (accepted at ICML 2026), SWE-Agent with Claude 4 Sonnet produced functionally correct solutions 61% of the time — but only 10.5% were also secure. Every one of the nine agent/model configurations tested landed between 6% and 12.5% on security. On SecureVibeBench (accepted at ACL 2026), the best agent-model combination produced correct-and-secure solutions just 23.8% of the time; in most configurations, more than half of the functionally correct solutions contained security flaws.

Two more results close the escape hatches:

• Prompting doesn't reliably fix it. A May 2026 study across five LLMs and four languages found that no prompting strategy — including explicitly security-aware prompts — produced a statistically significant reduction in vulnerabilities (all p > 0.05).
• Iterating makes it worse. A peer-reviewed controlled experiment (IEEE ISTAS 2025) found that asking an LLM to iteratively "improve" its own code increased critical vulnerabilities by 37.6% after just five iterations. The model fixes what it can see and quietly introduces what it can't.

Failure mode 5: Nobody can fix what nobody wrote

The largest direct audit of deployed vibe-coded apps to date (arXiv 2606.23130, June 2026) took 200 deployed apps built with Claude Code and Lovable, exploit-tested the findings, and had two human security experts independently review them.

The results: 90% of the apps contained at least one vulnerability. Median of 7 per vulnerable app. 76.7% of all flaws were critical or high severity — only 2.2% were low. Broken access control alone accounted for 36% of everything found and appeared in three out of four apps.

The study also explains why: about half the flaws traced to knowledge defects — security rules the model simply doesn't apply unprompted — and no mitigation the authors tested (better models, production-ready prompting) cut the failure rate by more than 27%. None eliminated any category entirely.

Which is the deeper problem. A traditional codebase has at least one person who understands it. A vibe-coded app in production has zero. When Enrichlead came under attack, its founder's honest summary — "I'm not technical so this is taking me longer that usual" — is the fifth failure mode in one sentence. Incident response requires exactly the expertise that vibe coding promised to make unnecessary.

What this doesn't mean

It doesn't mean AI-assisted development is doomed — the same tools in the hands of someone who reviews the output are a genuine productivity multiplier, and this post's research was itself AI-assisted. Some caveats worth keeping:

• Much of the scan data comes from security vendors with tooling to sell. Their methodologies are published and the numbers are directionally corroborated by independent academic work, but no study includes a human-coded control group.
• The benchmark security rates (6–24%) come from deliberately security-sensitive tasks — they're not a base rate for all AI code.
• Platforms have shipped mitigations since the 2025 disclosures (Lovable added a security scanner; Supabase added RLS warnings), so today's baseline is likely better than the 2025 numbers.

If you're shipping a vibe-coded app anyway

The failure modes above are a checklist. Before real users touch it:

1. Turn on Row-Level Security for every table, and test it: open an incognito window and try to read and write your database with no login.
2. Assume every key in your frontend bundle is public. Anything that must stay secret belongs server-side; rotate anything already shipped.
3. Test authorization, not just authentication. Log in as user A and try to fetch user B's data. That single test would have prevented the 1.1M-message leak.
4. Get one human security review before launch — a few hours of a professional's time is cheap against a breach involving ID photos.
5. Don't ask the AI to "make it secure" and call it done. The evidence says that reliably doesn't work.

These five checks catch the failures that killed the apps in this post. The full audit we run covers 25 — including payment-flow abuse, rate limiting, backup recovery, and the checks specific to Lovable, Bolt, and Cursor output. Get the 25-Point Vibe-Code Production Checklist (PDF) → (free, sent to your email)

Ship fast. Just don't ship naked.