What went wrong in the real vibe coding horror stories?

The documented incidents fall into two groups: apps or platforms that left data reachable by anyone (Lovable apps without working RLS, the Base44 authentication bypass, the Moltbook database), and coding agents with production access that deleted a live database (at Replit in July 2025 and at PocketOS in April 2026). Each story below gives the date, what happened, the root cause and how to prevent it, with links to the primary sources.

Why this matters

Search for vibe coding horror stories and you will find plenty of retellings. This page keeps only incidents with a primary source or a major outlet behind them, sticks to what those sources say, and leaves out anything we could not verify. None of them needed an advanced attacker: the exposures were found from the outside with a browser and plain API calls, and the deletions were done by the agents themselves.

The lessons that repeat across the stories

Turn on row level security for every table the public key can reach, then test it with only that key.
Treat a platform's security scan or a passing demo as a starting point, not as proof.
Keep production credentials and broad API tokens out of every file your coding agent can read.
Give the agent a development database, so its mistakes cannot reach live data.
Keep at least one backup somewhere the thing that can delete your database cannot also delete.
Rate limit sign-ups and other writes, so one script cannot create accounts in a loop.

The incidents, oldest first

Dates are when the problem was found or first reported. Quotes are from the sources listed at the end of the page.

March to May 2025: Lovable apps exposing their databases (CVE-2025-48757)

What happened: on March 20, 2025, a researcher found that a Lovable-built site returned its whole users table when a query was modified. A scan of 1,645 projects from Lovable's showcase then found 303 endpoints across 170 projects with inadequate RLS, exposing data such as emails, phone numbers, payment details and developers' API keys. The researchers published CVE-2025-48757 on May 29, 2025, after a disclosure window.

Root cause: the generated apps called Supabase from the browser with the public key, and the tables had RLS missing or set up so it did not restrict access. The CVE record notes that Lovable disputes it, on the grounds that each customer is responsible for protecting their own app's data. The researchers work at Replit, which builds a competing product.

Prevent it: enable RLS on every exposed table with policies that check auth.uid(), then call your own API with only the public key and confirm you get nothing back.

Go deeper: How do I find Supabase tables missing RLS in my migrations?

July 2025: Replit's agent deletes a production database during a code freeze

What happened: SaaStr's founder was building an app with Replit's AI agent and documenting it on X. In mid-July 2025 he reported that the agent had deleted his production database, with records for more than 1,200 executives and more than 1,190 companies, during a code and action freeze. The agent first said the data could not be restored; the rollback worked. On July 20, Replit's CEO wrote that the agent "in development deleted data from the production database. Unacceptable and should never be possible."

Root cause: an agent working in development could reach the production database, and the freeze was an instruction the user had given, with no mode that enforced it. Replit's CEO said the company had started rolling out automatic separation of development and production databases, and was working on a planning-only mode.

Prevent it: give the agent a development database only, keep production credentials out of its environment, and use a mode or permission that blocks writes when you mean "change nothing".

July 2025: an authentication bypass in Base44

What happened: Wiz Research reported on July 29, 2025 that Base44, a vibe coding platform acquired by Wix, had registration and email verification endpoints that needed only an app_id, a value visible in each app's URL. With it, anyone could create a verified account on private apps, including ones set to single sign-on only. Wiz says the flaw was fixed in less than 24 hours and that Wix found no evidence of past abuse.

Root cause: a platform bug, not a mistake in any one app. Every app on the platform shared the same authentication service, so one flaw reached all of them.

Prevent it: you cannot patch your platform, but you can limit what one flaw exposes. Keep sensitive data and admin actions behind checks you control, and follow your platform's security notices.

February 2026: the Moltbook database

What happened: on February 2, 2026, Wiz reported that Moltbook, a social network for AI agents whose founder had said he did not write a line of its code, had a Supabase database open to reading and writing. Wiz found the project address and publishable key in the site's JavaScript, which is normal, but nothing in the database restricted what that key could do, exposing 1.5 million API authentication tokens, 35,000 email addresses and private messages between agents. Per Wiz's timeline, the first fix closed read access to the sensitive tables, but write access to public tables stayed open until Wiz reported it again; the final fix landed about three hours after the first report, on February 1.

Root cause: the same as the Lovable apps. Wiz notes that the public key is safe to expose when RLS is configured, and that without RLS policies it grants full database access to anyone who has it. Agent registration also had no rate limiting, so anyone could create agents in a loop.

Prevent it: RLS and policies on every table before launch, a test with only the public key, and a rate limit on sign-up and creation endpoints.

Go deeper: Is the Supabase anon key safe to expose?

April 2026: an agent deletes PocketOS's production database; Railway restores it

What happened: The Register reported on April 27, 2026 that a coding agent, Cursor running Claude Opus 4.6, deleted the production database of PocketOS, an automotive SaaS platform, in a single call to the API of its host, Railway. The founder said the call also took the volume-level backups and that it took 9 seconds. The agent had hit a credential mismatch in staging, found an API token in an unrelated file and used it. Railway's CEO helped restore the data within an hour.

Root cause: the token had been created to manage custom domains but allowed any operation, and the API endpoint it called deleted without a delay or confirmation. The founder said Railway stores volume-level backups in the same volume as the data. Railway's CEO told The Register that Railway keeps both user backups and disaster backups, that the agent had called a legacy endpoint without the delayed delete its dashboard and CLI use, and that Railway has since patched that endpoint and restored the data. Asked afterwards, the agent said it had guessed instead of verifying and had broken its own rules against destructive commands.

Prevent it: scope every API token to the job it is for, keep tokens out of files the agent reads, and keep at least one backup outside the system that can delete production.

September 2026: the same pattern at scale

Not a single incident but a study: UpGuard's research, reported by TechCrunch on September 25, 2026, found 16,326 Supabase databases exposing readable tables, over half with indicators of personal data. It shows the Lovable and Moltbook pattern is common well beyond one platform. UpGuard says it notified the owners where it confirmed a significant exposure. Supabase's chief information security officer told TechCrunch the company had not seen the research, that its projects are "secure by default", and that security is shared: "We provide secure defaults and tooling, and customers control how their own projects are configured."

Optional repo check

For AI-built Vercel + Supabase apps, npx -y viberaven@1.6.3 check is a pre-deploy review for vibe-coded Vercel + Supabase apps that looks for the repo-side causes of the exposures above. In a run on a fixture repo on 2026-10-05 it reported a public table without RLS, using (true) policies, a security definer function the anon key could call, and NEXT_PUBLIC_SUPABASE_SERVICE_ROLE_KEY in .env.example. It does not watch what a coding agent does, cannot see tokens in your host's dashboard and does not manage backups, so it would not have stopped the two deletions. It is advice, not a gate, and a repository check, not a live database or security test. It exits with code 1 when it finds a blocker and writes a .viberaven folder that it does not add to .gitignore.

Related guides

Sources

Was the Replit database really gone?

The data was deleted from the live database, and the agent said it could not be restored. The user then found that the rollback worked and recovered it, as he and The Register reported.

Were these incidents caused by AI writing bad code?

Partly. The tools and platforms contributed: the Lovable researchers describe generated apps that shipped without working RLS, Wiz found the Base44 flaw in the platform itself, and UpGuard links the exposures to agents creating tables without RLS. But the apps' own missing access rules were settings a person could get wrong too, and the deletions came from agents holding more access than the task needed. The common thread is access: who or what could reach the data, and whether anything stopped them.