Vibe-coded app security in 2026

In our first post we called security the weak link of vibe coding, on the strength of two 2025 scans. Since then the evidence has piled up: outside scans of tens of thousands of live apps, a run of public incidents, peer-reviewed benchmarks that try to exploit what AI agents write, and a string of default changes from the platforms. This post puts it together. The short version is that vibe-coded apps fail in a narrow, repeatable way. The problem is mostly who is allowed to read and change data, not exotic AI bugs, and we found no evidence that the rate is improving.

One caveat runs through all of it. Nearly every number below comes from a company that sells a scanner, a code reviewer or a detection product, and one widely cited study came from people who worked at a competitor of the platform they studied. We name the vendor and what it sells next to each figure. The only measurements with no vendor behind them are academic, and we lean on those for "how often". "Exposed" also doesn't mean "breached": none of the incidents here comes with a confirmed count of malicious exploitation.

What live scans find#

Five groups have scanned live apps from the outside since March 2025. Their headline numbers get quoted side by side as if they measured the same thing. They don't: each percentage is a share of a different population, and one of the most cited figures isn't a percentage at all. Read the denominator first.

The longest-running data point is CVE-2025-48757. In March 2025, Matt Palmer and a colleague found 303 endpoints across 170 of 1,645 apps from Lovable's showcase, about 10.3%, where the Supabase row-level security (RLS) rules were missing or wrong. They also inserted a record marked as paid, bypassing Stripe. The CVE carries a 9.3 score from MITRE. Lovable disputes it, per the NVD entry, on the grounds that each customer is responsible for their own app's data, and the researchers worked at Replit, a Lovable competitor.

The largest scan so far is Reeve's, run on 12–14 August 2026 by a solo developer who sells the same scanner and published the data under CC BY 4.0. It covered 30,998 live apps on the builders' default domains, including 18,554 on Lovable, 5,438 on Base44, 3,042 on Replit, 1,790 on v0 and 1,123 on Bolt. Most of what makes the headline number confusing is visible in how the sample narrows.

By builder, Reeve found a readable table in 57% of the 3,553 testable Lovable apps and 77% of 35 testable Bolt apps; Base44, Replit and v0 had too few checkable apps to say. Here is a rough comparison, and it is our arithmetic, not Reeve's: 57% of 3,553 is about 2,025 Lovable apps, or roughly 10.9% of the 18,554 Lovable apps in the sample. Palmer's figure seventeen months earlier was 10.3%. The methods differ (Reeve counts any readable table, including ones meant to be public), so this isn't proof that nothing improved. It is the absence of any evidence that something did.

UpGuard's study, published in September 2026 and covered by TechCrunch and BleepingComputer, came at the problem from the database side. Of roughly 300,000 domains showing signs of Supabase, it found 16,326 databases with tables anyone could read, about 5.4% by our arithmetic. More than half held personal data. UpGuard is explicit that its scans don't establish that the sites were built with an AI agent, so the honest framing is "16,326 Supabase databases", the default backend for vibe-coded apps, not "16,326 vibe-coded apps". Between Reeve and UpGuard, somewhere between one in five open databases (Reeve: 394 of 2,096) and one in two (UpGuard) hold personal data.

Keys in the bundle#

A Supabase "anon" key in the page's JavaScript is not a leak: it's public by design, and the RLS rules are what's supposed to protect the data. As Wiz put it about Moltbook, without RLS policies that key "grants full database access to anyone". That's why "an app ships a key" is a much weaker finding than "an app ships a key that matters". Reeve separated the two.

The same pattern shows up upstream in source code. GitGuardian, which sells secret detection, says Claude Code-assisted commits on public GitHub leaked secrets at a 3.2% rate, against a 1.5% baseline for all public commits.

The incidents#

The scans describe a rate. The incidents show what the rate looks like when someone finds it. The timeline below has twelve disclosures from the last eighteen months. The incidents among them sort into three groups: apps whose access rules were wrong, platforms whose own authorization had a hole, and agents that destroyed data they had credentials for.

Moltbook is the largest proven case. It's a social network for AI agents whose founder posted that he "didn't write a single line of code" for it. Wiz, which sells cloud security, found a Supabase key in the client JavaScript and no RLS behind it: 1.5 million API authentication tokens, 35,000 email addresses and private messages between agents, about 4.75 million records in all, readable and writable by anyone. Wiz says it made contact at 21:48 UTC on 31 January 2026 and the database was fully fixed by 01:00 UTC on 1 February. The story made Fortune the same week.

The platform-level cases matter because one flaw reaches every tenant. In July 2025 Wiz found that Base44's undocumented registration and one-time-code endpoints accepted an app's public ID, which opened private enterprise apps meant for single sign-on only; Wix fixed it in under 24 hours. In April 2026 Lovable disclosed that between 3 February and 20 April, the source code and AI chat history of public projects "could potentially be accessed by any Lovable user" with a project link. Reports filed on HackerOne from 22 February were closed, and Lovable first called it intended behavior. The researcher also says database credentials were readable, according to The Register; Lovable's post doesn't say so.

The model can also write the access check backwards. In February 2026 a researcher told The Register that an EdTech app featured by Lovable had 16 vulnerabilities, including an AI-written check that ended up "blocking authenticated users and allowing access to unauthenticated users". He says 18,697 user records were exposed, 4,538 of them student accounts. Lovable's CISO said acting on its scanner's recommendations "is at the discretion of the user".

Why it happens: access control, not injection#

The live-app failures are almost all about authorization: who can read a row, who can change it, whether the check runs on the server or only in the browser. Controlled studies of AI-written code say the same thing from the other side. Models have mostly learned the textbook bugs and keep missing the ones that depend on what the app is for.

Veracode's 2026 report tested more than 100 models on four weakness classes with static analysis. The average security pass rate "sits at 56 percent", which Veracode, a static-analysis vendor, calls "virtually unchanged" from the year before. The average hides a split.

The averages are flat, but individual models differ: GPT-5.5 leads Veracode's table at 68%, and reasoning models score 56% against 51% for non-reasoning ones. "Newer models aren't more secure" is too strong. "Security lags correctness, and the average hasn't moved" is what the data supports.

When researchers audit real apps by hand, access control comes out on top. Deng, Fan and Meng, with no vendor behind them, sampled 200 deployed apps from 9,041 vibe-coded GitHub repositories, audited the code and confirmed each finding with a harmless live proof of concept. 182 of the 200 had at least one vulnerability, with 1,186 in total.

GitHub sees the shift across all code. In its 2025 Octoverse report, broken access control overtook injection as the most common CodeQL alert, flagged in 151,000+ repositories, up 172% in a year. GitHub links it partly to "AI-generated scaffolds that skip critical auth checks"; that's a correlation it draws, not a measured cause. OWASP's Top 10:2025 keeps broken access control at number one and adds "Inappropriate Trust in AI Generated Code" as a next-steps entry.

Correct is not the same as secure#

The benchmarks that actually try to exploit the code are the strongest evidence, and they're academic. BaxBench, from ETH Zurich and LogicStar (ICML 2025), asks models to build 392 backends and then attacks the ones that work.

Asking nicely doesn't fix it reliably. With a generic "be secure" reminder in the prompt, BaxBench reports that Claude Opus 4.5 Thinking rises to 66.1% correct and secure while GPT-5 falls to 46.2%, because its correctness drops.

SusVibes (CMU and others, ICML 2026) tests agents on something closer to real work: 186 feature requests in real repositories where a human once committed a vulnerable version. SWE-agent running Claude 4 Sonnet solved 57% of them, but only 11.8% securely, so 79.3% of its working solutions were insecure. The best setting in the paper's main results table, Gemini 3 Pro in SWE-agent, reached 12.9%.

Reviews of real pull requests point the same way. CodeRabbit, which sells AI code review, compared 320 AI-co-authored pull requests with 150 human ones and found 10.83 issues per PR against 6.45, with security issues "up to 2.74× higher".

The agents are part of the attack surface#

Through 2025 the conversation was about the apps agents write. By 2026 the agents themselves had become a risk: what they're allowed to do, which files they trust, and what they install.

Destructive actions. Every deletion in the incident timeline involved an agent holding production credentials with no human gate. At PocketOS, a Cursor agent working on staging found an unrelated Railway token with account-wide authority and deleted the production volume, and the backups stored on the same volume, in under 10 seconds, The New Stack reports. At DataTalks.Club, Claude Code ran terraform destroy against a stale state file and took out the production database, network, cluster and automated snapshots; the owner, Alexey Grigorev, blames his own over-reliance on the agent. In both cases the backups sat inside the same blast radius.

Config files that execute. Check Point found that a cloned repository's .claude/settings.json hooks and .mcp.json servers could run commands before the user accepted Claude Code's trust dialog, and that a project setting could redirect API traffic and leak the user's API key (CVE-2025-59536 and CVE-2026-21852). Cato Networks showed that a prompt injection could silently rewrite Cursor's MCP config and run attacker commands before the user approved anything (fixed in Cursor 1.3). The NVD lists a command-injection flaw in GitHub Copilot and Visual Studio that let an attacker run code locally. Developers read these files as metadata, not code, which is why they rarely get reviewed.

Hallucinated packages. The USENIX Security 2025 study by Spracklen and colleagues generated 576,000 code samples with 16 models and checked every package they referenced.

Attackers have noticed. Aikido, which sells supply-chain security, points to unused-imports, a malicious npm package sitting on a name that gets suggested in place of the real eslint-plugin-unused-imports.

Poisoned tools. In February 2026, Koi audited 2,857 skills on OpenClaw's ClawHub marketplace and found 341 malicious, most of them installing a macOS stealer, The Hacker News reported. A compromised MCP server on npm, postmark-mcp, quietly BCC'd every outbound email to an outside domain, Snyk reported. Malicious versions of the Nx build tool prompted the victim's own Claude, Gemini and Amazon Q CLIs with flags like --dangerously-skip-permissions to scan the disk for secrets. And an unauthorized cline@2.3.0 was live on npm for about eight hours in February 2026, published with a stolen token that a researcher traced to a prompt-injection flaw in Cline's AI issue-triage workflow, SafeDep wrote.

Builder domains as phishing infrastructure#

The same things that make builders great for prototypes make them great for phishing: a page goes live in minutes, on a reputable domain, with a valid certificate and no identity check. Security vendors that sell email and web filtering have been documenting it since early 2025.

Proofpoint says it has seen tens of thousands of Lovable URLs detected as threats in email each month since February 2025. One campaign, using the Tycoon phishing kit, sent hundreds of thousands of messages and hit more than 5,000 organizations; others delivered crypto-wallet drainers and malware. Lovable says its safety program blocks about 1,000 malicious projects a day, per Dark Reading; that number is self-reported. Okta saw v0 used to build fake sign-in pages, with the impersonated logos hosted on Vercel too. And Kaseya's INKY team blocked 6,283+ phishing emails aimed at 2,030+ organizations from December 2025 to May 2026 from three separate campaigns that all used vercel.app, citing "instant deployment, no identity verification, valid TLS certificates" and the domain's reputation.

What platforms changed#

Platforms did respond, usually quickly and usually right after a public incident. The changes fall into two kinds: scanners that look at an app before or after it's published, and defaults that change what happens when nobody configures anything.

The Supabase change is the most consequential, because it moves the default for the backend most of these apps share. Supabase's changelog gives the reason in one line: "agents, CLI scripts, and AI platforms create tables too". A table an agent creates through a migration never touches the dashboard, so the January RLS-on default never applied to it. From 30 October 2026, on every project, a new table isn't reachable through the API until someone grants it.

The pattern is consistent. A default changes the outcome for everyone who never thinks about security, which is most people building this way. A scanner helps the people who read its findings and act on them, and Lovable's CISO said in February 2026 that acting on them is the user's call. Lovable's first scanner checked that a policy existed, so a wrong policy passed. Both Lovable and Supabase still describe application security as the customer's job: Supabase's own 2025 security retro says it "remains the responsibility of each customer".

Governments have started to say the same. Richard Horne, head of the UK's National Cyber Security Centre, told RSAC in March 2026 that AI coding tools "must be designed and trained from the outset" not to introduce vulnerabilities, and asked for secure-by-default output and secure hosting platforms, Infosecurity Magazine reported.

What this means if you build with AI#

None of this argues against building with AI. A personal habit tracker and a team's internal tool are worth having even if nobody reviews every line. But the data points to a short list of habits that cover most of the measured harm, and most of them take minutes.

1. Assume everything in your page bundle is public. Anyone can open developer tools and read your JavaScript, including the database URL and key. That's fine for a Supabase anon key, as long as the access rules behind it are right: the rules are the security, not the key.
2. Never put a service key or a secret API key in client code. Reeve found 52 apps shipping keys that can spend money or read the whole database. A Stripe secret, an OpenAI key or a service_role key belongs on a server. If your app has no server, it can't use that key safely.
3. Test your access rules as a stranger. Open the app signed out and in a private window, then as a second account, and try to read and change someone else's data. A scanner that checks whether a rule exists won't catch a check written backwards. Ask your agent to write that test and run it before every share.
4. Keep apps private until they need to be public. An internal tool for five colleagues doesn't need to be reachable by everyone on the internet. In one scan, 5,000+ apps had virtually no authentication, WIRED reported.
5. Turn on the safer defaults now. On Supabase, opt in to unexposed tables now rather than waiting for 30 October, and make sure every table has RLS on, including the ones your agent created through migrations.
6. Don't give agents production credentials. Give them a copy of the data, a key scoped to the task, and keep backups somewhere their credentials can't reach. Every deletion in the timeline, at PocketOS, DataTalks.Club and SaaStr, started with an agent holding production credentials.
7. Treat agent config as code. Review .claude/, .mcp.json, .cursor/ and any skills or MCP servers before you run an agent in a repo you didn't write, and keep the agent updated: several of the CVEs above ran before anyone approved anything.
8. Pin and check your dependencies. Before installing a package your agent suggests, confirm it exists, is the one you meant and has a history; one reference in five in the USENIX study pointed at nothing. Commit a lockfile so the next install gets the same thing.
9. Read the diff where it touches auth, money or personal data. Even the best model in BaxBench writes a working backend that can be exploited about a third of the time. Vibe the layout; review the permissions.

Some of these habits are defaults on host0, the cloud we're building for apps like these: new apps are private by default behind a sign-in gate, on a domain (host0.app) separate from the platform. Shared data goes through a records API whose access rules are declared in an h0.json manifest and validated at deploy, so there's no database key in the page bundle and no RLS policy to forget.

Methodology#

This post is built on a data pack we compiled on 6 October 2026 from a deep-research run covering five angles: incidents, ecosystem scans of live apps, controlled code studies, abuse and agent risks, and platform responses. We then spot-checked about 20 of the numbers the post leans on hardest: we fetched each primary page live, pulled the exact sentence, and looked for an independent outlet that reported the same figure. Each claim in the pack carries a tier: verified against the primary, spot-checked across two or more outlets, or single-sourced. Single-sourced claims are attributed in the text ("X says"). Before publishing, we re-opened every single-sourced page we cite and dropped anything it no longer said.

We left out several widely repeated claims:

• The Tea app breach as a vibe-coding failure. Tea blamed a legacy storage system; nothing links it to AI-written code.
• "Wiz: 20% of vibe-coded apps are at risk." Wiz's one in five refers to organizations building on these platforms, not to apps.
• "62% of AI code is vulnerable." We found no primary source for it.
• "CodeRabbit: 75% more misconfigurations." CodeRabbit's 75% is about logic and correctness issues.
• "11% of apps leak credentials." That count is mostly anon keys, which are public by design.
• A 376% rise in AI credential theft, and related figures, found only in blog aggregators.
• A paid press release claiming 16% of Supabase apps were writable by strangers, with no published method.
• Details we couldn't re-confirm on the source page: a 992% rise in leaked Supabase secrets, Supabase's automatic revocation of leaked keys, the claim that postmark-mcp was the first malicious MCP server and had shipped 15 clean versions, a "free" label on Bolt's audit, a per-tool SusVibes score for Claude Code, and the claim that the unused-imports package steals credentials.

Limitations:

• Almost every number comes from a vendor that sells the fix. Reeve, UpGuard, Escape, Wiz, RedAccess, Veracode, CodeRabbit, GitGuardian, Glow, Proofpoint, Trend Micro, Okta, Kaseya and Aikido all sell scanning, review or detection. The academic studies (BaxBench, SusVibes, the USENIX package study, Deng et al.) are the only ones with no product attached.
• Denominators differ. The scans sample different populations (showcase apps, apps on default domains, domains showing Supabase) and count different things (apps, endpoints, databases, findings). Don't compare them on one axis.
• Passive scans are lower bounds. They see only public, outside-testable apps. Apps behind their own backend are invisible to them, and they say nothing about private apps.
• Exposed is not breached. No incident here has a confirmed exploitation count. WIRED couldn't confirm RedAccess's data was real; UpGuard doesn't claim its databases were AI-built.
• Everything has a date. Supabase's change reaches existing projects on 30 October 2026, GitHub's 2026 Octoverse is due later in October, and the BaxBench leaderboard had no rows for the newest models when we read it.

Open questions#

The public data leaves gaps nobody has filled:

1. Has anything improved? No one has repeated a scan with the same method, and no platform publishes a before-and-after exposure rate.
2. How often can strangers write, not just read? The only figure for write exposure comes from a press release with no published method.
3. Is the exposed data real? Nobody measures whether open rows belong to real people or are test data.
4. How often do guardrails fire? Netlify's 17% is the only published rate for any platform's guardrail.
5. Do defaults beat scanners? The evidence is circumstantial: defaults change outcomes for everyone, but no one has measured the difference.
6. How broad are the keys agents hold? Every destructive incident involved an over-scoped credential, but there's no data on how common that is.
7. How much phishing do builders take down? No builder publishes 2026 takedown numbers for its shared domain.

We plan to come back to several of these with data of our own.