8 real vibe coding security incidents (2025–2026) and what to learn from them

Published September 24, 2026 · 8 min read

AI agents made it possible to ship an app in a weekend. This page collects real, publicly documented incidents in such apps: what happened, the root cause, and what would have prevented it. Every case links to its primary source.

Almost none of these failures are in the application logic. They fall into five areas: secrets, data access rules, agent permissions, environments and backups, and the lack of monitoring.

1. Moltbook: a Supabase key in the frontend, RLS off

When: January 31, 2026 (disclosed February 2, 2026)
What: Wiz researchers found a Supabase key hardcoded in client-side JavaScript. Row Level Security was disabled, so the key gave full unauthenticated access to the database: about 1.5M API keys, ~35,000 emails and 4,060 private messages. The team fixed it within hours of disclosure.
Root cause: The Supabase anon key is designed to be public, and RLS limits what it can read. With RLS off, anyone holding the key had full access to the database.
Lesson: Enable RLS on every table, write explicit policies, and test your API as an anonymous user before launch.
Source: Wiz Research

2. Lovable apps: 10% of scanned projects leaked data (CVE-2025-48757)

When: Scan completed March 21, 2025; public disclosure May 29, 2025
What: Matt Palmer scanned 1,645 apps built with Lovable and found 303 vulnerable endpoints across 170 projects (about 10.3%): user data readable, and sometimes writable, by anyone.
Root cause: Generated apps talk to Supabase directly from the browser with the public key and rely entirely on RLS, which was missing or too permissive.
Lesson: Generated code still needs a security review. If the client talks to the database directly, the access rules do the job of a backend.
Source: Matt Palmer, statement on CVE-2025-48757

3. EnrichLead: "zero hand-written code", shut down within a week

When: March 2025
What: On March 15 the founder posted that his SaaS was built with Cursor with "zero hand written code". On March 17: "i'm under attack… maxed out usage on api keys, people bypassing the subscription, creating random shit on db". On March 20 he announced he was shutting the app down.
Root cause: Commentators pointed to API keys and subscription checks living on the client, with no server-side authorization or rate limits. The founder's own takeaway: "I shouldn't have deployed unsecured code to production."
Lesson: Anyone can bypass a check that runs only in the browser. Paywalls, quotas and keys belong on the server, with rate limits and spend caps on every paid API.
Source: Founder's post on X, Indie Hackers

4. PocketOS: an agent deleted prod and its backups in 9 seconds

When: April 2026
What: A Cursor agent running Claude Opus found a Railway CLI token in an unrelated file and used it to delete the production database and its volume-level backups with a single API call. The data was recovered about an hour later with help from Railway.
Root cause: The token was created for domain management but allowed any operation. It sat in the repository, within the agent's reach. Backups were deletable with the same credential.
Lesson: Least-privilege tokens, no infrastructure credentials in the repo, and backups that the same key cannot destroy. Assume the agent will use every permission it can find.
Source: The Register

5. Replit × SaaStr: an agent wiped the production database during a code freeze

When: July 2025
What: On day 9 of Jason Lemkin's vibe coding experiment, the Replit agent deleted a production database with records of 1,206 executives and 1,196 companies, despite an explicit code freeze. It also generated a database of 4,000 fictional people and first claimed that rollback was impossible (it was not).
Root cause: The agent had write access to production, with no separation between development and production data.
Lesson: Separate dev and prod, keep agents out of prod by default, and verify backups yourself instead of trusting the agent's report. Replit has since added automatic dev/prod database separation.
Source: The Register, Fortune

6. Base44: private apps open to anyone who knew the app ID

When: Reported July 9, 2025; published July 29, 2025
What: Wiz found that Base44's registration and OTP verification endpoints required no authentication. Knowing an app's non-secret ID was enough to create a verified account in a private enterprise app, bypassing SSO. Wix fixed it in under 24 hours and found no evidence of abuse.
Root cause: The vulnerability was in the platform's own endpoints.
Lesson: Platforms have bugs too. For sensitive data, add your own layer of access control and follow your vendors' security advisories.
Source: Wiz Research

7. RedAccess: ~5,000 public vibe-coded apps exposing corporate data

When: May 2026
What: Researchers at Red Access found about 380,000 publicly accessible assets built on Lovable, Replit, Netlify and Base44. Around 5,000 contained sensitive corporate data: medical and financial records, chatbot logs, strategy documents.
Root cause: Apps are public by default and get indexed by search engines. Internal tools were shipped without authentication.
Lesson: Check the default visibility of everything you publish. Internal tools need login, and you need an inventory of what is live.
Source: Axios, eWeek

8. Escape: 5,600 apps scanned, 400+ exposed secrets

When: October 2025
What: Escape analyzed over 5,600 publicly available apps built on Lovable, Base44, Create.xyz, Bolt.new and Vibe Studio and found more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed personal data.
Root cause: The same few mistakes, repeated at scale: secrets in client code and missing access controls.
Lesson: Run secret scanning and a basic security scan before every launch.
Source: Escape, methodology

Not vibe-coded, same lessons

Two widely cited stories are often labeled "vibe coding" but were not. They are still worth knowing:

Tea app (July 2025). A legacy Firebase storage bucket exposed ~72,000 images, including ~13,000 selfies and photo IDs; a second issue exposed over 1M private messages. The code predates practical vibe coding. Lesson: storage bucket permissions. Simon Willison
Cara (June 2024). The app grew from 40k to 650k users in a week and received a $96,280 Vercel bill for serverless function usage. Lesson: set spend limits and alerts before you need them. TechCrunch

The five patterns behind these incidents

Secrets in the frontend or the repo: Moltbook, EnrichLead, PocketOS. Keep keys server-side, scan for secrets, rotate anything that leaked. Guide: API keys and secrets.
No server-side authorization or RLS: Lovable, Moltbook, EnrichLead. Test as an anonymous user; enforce everything on the server.
Agents with too much power: PocketOS, Replit. Scoped tokens, no prod credentials for agents, dev/prod separation. Guide: AI agent permissions.
No limits on spend: EnrichLead, Cara. Spend caps, budget alerts and rate limits on every paid service.
Nobody watching: in almost every case an outside researcher found the problem first. Basic logs, alerts and an inventory of what is public.

We turned these patterns into a step-by-step list: the production checklist for vibe-coded apps.