Forget the 45%. The Number That Matters Is Eight.

April 2026: Three Breaches, One Pattern

April 2026 was an unusually rough month for the AI coding ecosystem. Within roughly a week, three different stories broke that, when you read them together, point to a problem most companies haven’t really grappled with yet.

First Breach: The Lovable Breach: 11 Weeks of Exposure

Lovable, the vibe-coding platform now valued at $6.6 billion and used by about eight million people, published its own postmortem acknowledging that for nearly eleven weeks between February 3 and April 20, 2026, the source code and AI chat histories of public projects on the platform had been readable by any logged-in Lovable user.

Private projects and Lovable’s enterprise cloud were never affected, the company says. The cause was a backend regression in February that quietly reintroduced public access. 

What makes the story interesting beyond the technical fault is the process failure: researchers had filed multiple valid reports through Lovable’s HackerOne program starting on February 22, but each one was closed without being escalated to the security team, because of outdated triage documentation Lovable had given to its triagers. 

The issue only surfaced when a researcher disclosed it publicly on April 20.

Second Breach: The Vercel Breach: OAuth Tokens and a Supply Chain Pivot

A few days earlier, Vercel had confirmed it was breached through a third-party AI tool called Context.ai, which had OAuth access to some of its internal systems via a Google Workspace integration that a Vercel employee had authorized. 

A Context.ai employee had been infected with the Lumma Stealer infostealer in February 2026; the attacker harvested OAuth tokens and used one of them to pivot into Vercel’s Google Workspace and then into Vercel’s environment.

Among the environment variables the attackers ended up touching were API keys and database credentials that customers had not marked as “sensitive” and that, as a result, were not encrypted at rest. In a follow-up thread on X, Vercel’s CEO Guillermo Rauch suggested that the attackers may have moved unusually quickly through the environment, possibly with AI assistance, although he was careful to frame this as a suspicion rather than a confirmed forensic finding.

Third Breach: The MCP Flaw: 200,000 Servers at Risk

In the same window, OX Security disclosed a design flaw in Anthropic’s Model Context Protocol that they argued could expose up to 200,000 MCP server instances to remote code execution. 

The confirmed number of publicly reachable affected servers is closer to 7,000, but the underlying flaw is baked into Anthropic’s official SDKs across Python, TypeScript, Java and Rust, so the long-tail exposure is substantial. Anthropic’s response, after months of correspondence, was that the behavior was “expected.” OX’s disclosure was published on April 15.

These were three different vectors at three different scales, but the common thread was hard to miss: the security stack most companies bought to defend against the previous generation of attack surface isn’t built for the one that emerged in the last eighteen months.

What’s the Root Cause? Configuration Nobody Told the AI About

Moltbook hadn’t enabled Row Level Security on its database, which is the configuration that determines whether the “anon” Supabase key in the front-end bundle is actually safe to expose. Supabase tells you it’s safe if you’ve enabled Row Level Security, and an experienced backend engineer knows to enable it before going to production. The AI that wrote the code didn’t think so. 

The founder didn’t know. The model produced something that worked at the demo stage and silently relied on a configuration that nobody told it about and that the founder didn’t know existed.

Moltbook turned out not to be a one-off. A first-quarter 2026 assessment by the security firm GuardMint, which examined more than two hundred vibe-coded applications, found that 183 of them (91.5%) contained at least one vulnerability traceable to AI hallucination or missing security context. 

According to agency audits from Beesoul cited by The Next Web, around 70% of Lovable apps in production ship with Row Level Security disabled. Bolt.new, a competing platform, ships its generated applications with that setting off by default.

The pattern repeats at the largest scale, too. Roughly six weeks after Moltbook, Anthropic itself shipped a 59.8 megabyte source map inside its Claude Code npm package because someone forgot to add a single line to a config file. The result was that 512,000 lines of proprietary TypeScript were exposed in a download anyone could pull.

You can map almost every public vibe-coding breach in the last year onto the same shape. The model wrote code that worked. It demoed cleanly. It passed whatever tests the team had thought to write. And it depended, silently, on a setting that nobody had been told to check. This is the part of the story that the “45% of AI-generated code is vulnerable” headline doesn’t capture, and it’s also the part that most of the security tooling on the market doesn’t address.

Which Languages Fail and How the Numbers Differ?

There are at least two reasonable ways to measure which AI coding tools produce the most vulnerabilities, and the two methods give measurably different answers.

The Veracode Benchmark

The Veracode benchmark tested more than a hundred large language models across eighty controlled coding tasks in Java, Python, C# and JavaScript, scanning every output with static analysis. Python, C# and JavaScript clustered at somewhere between 38 and 45% failure. Java came in at roughly 72%. 

Three out of four times a model was asked to write Java, the resulting code contained a known vulnerability. Veracode’s hypothesis is that the models have been trained on millions of lines of older Java code, much of it from before modern security frameworks existed, and when asked to produce Java they default to the patterns they saw most often.

The Schreiber and Tippe Study

The Schreiber and Tippe paper from late 2025 scanned 7,703 GitHub files attributed to AI coding tools using CodeQL, looking for vulnerabilities in real production code. Python files had a 16 to 18% vulnerability rate. JavaScript came in at 8 to 9%. TypeScript was at 2.5 to 7%.

The two findings aren’t really in conflict.

• Veracode is measuring what a model does when given a Java task in a lab
• Schreiber and Tippe are measuring what’s actually shipping to GitHub.
• Python tops the in-the-wild ranking because Python is what people are mostly using AI for, including a lot of security-sensitive work.
• TypeScript consistently produces less vulnerable code than JavaScript, the type system seems to constrain the model in a way that helps.

The Bug Classes That Actually Matter

Across every language tested in the Veracode work, 86% of AI-generated code samples failed to defend against cross-site scripting, and 88% failed at log injection. SQL injection (the bug everyone thinks of first) has actually been largely solved at the model level. It’s the bug classes that don’t show up in introductory security training where the models fall apart.

How Different Tools Fail Differently

Tenzai published a controlled comparison of AI coding tools, with testing done in December 2025 and results released in January 2026. They handed identical prompts to five major tools (Claude Code, Cursor, Codex, Replit, and Devin), and had each build the same three web applications. Fifteen applications in total. Every one audited.

The most capable, most autonomous tool produced the worst critical-severity outcomes. The answer isn’t that Claude Code is sloppy. It’s that more autonomous tools make more architectural decisions on the developer’s behalf. When the agent is the one deciding whether to add authentication to a new endpoint, the agent’s mistake becomes the application’s mistake. Less-autonomous tools tend to leave more of those decisions to the developer, who at least has the chance to ask.

As Hanqing Zhao at Georgia Tech put it: “When an agent builds something without authentication, that’s not a typo. It’s a design flaw baked in from the start.”

The Stack Pattern Is More Consistent Than the Tool Pattern

Most vibe-coded breach disclosures share the same backbone: a front-end framework (usually React or Next.js) doing too much work in the browser; a Supabase backend with Row Level Security disabled; API keys somewhere they shouldn’t be. Lovable’s stack matches this exactly. So did Moltbook’s.

The model didn’t invent these patterns. It learned them from public code. The fix isn’t a smarter model so much as a different set of defaults at the platform level.

Your Asset Inventory Doesn’t Know These Apps Exist

Even if your scanner were doing useful work, you’d still need to know what to scan. Most security teams don’t.

An Israeli firm called RedAccess uncovered something like 380,000 publicly accessible assets built with Lovable, Base44, Replit and Netlify during a research project on shadow AI.

About 5,000 of those, roughly 1.3%, contained sensitive corporate information, a shipping company’s vessel schedule, a UK clinical trial roster, full unredacted customer service conversations for a British cabinet supplier.

All of them sitting on the open web, indexed by Google within hours of deployment. None of them appeared in any of those companies’ asset inventories.

Traditional asset discovery was built to find servers, cloud instances and containers. It doesn’t have a way to find a marketing configurator that a product manager built on Lovable over a weekend, connected to a Supabase database holding live customer records, and shared with three external contractors through a public URL. 

Privacy settings on most of these platforms default to the public. The PM who built the thing doesn’t realize they need to switch it. Security never hears about the project. There’s nothing to put on a vendor list, because there’s no vendor. There’s just an employee with a Lovable account.

The breaches you read about are the ones that got discovered. Behind them, there’s a much larger universe of vibe-coded applications quietly hosting customer data or proprietary information, and nobody, including the companies that own the data — has a map of where any of them are.

The fix is partly cultural and partly tooling. The cultural part is convincing your engineering organization that “I built it on Lovable” needs to go through the same approval flow as “I provisioned a server.” 

The tooling part is monitoring for subdomain assignments on the major vibe-coding platforms. RedAccess found their 380,000 assets through subdomain enumeration on lovable.dev, base44.com, bolt.new and others, combined with Shodan fingerprinting. The same playbook works defensively.

If you don’t know which apps in your environment were vibe-coded, none of the mitigations below are going to do much for you. The first task is finding the ones you don’t know about.

Your Scanner Doesn’t See These Bugs

In February 2026, ProjectDiscovery generated three full-stack web applications using AI coding tools and ran four security tools against the same builds: Claude Code as a reviewer, Snyk, Invicti, and Neo (which pairs AI review with runtime testing).

This isn’t a criticism of those tools. They were built for a different generation of bug — tuned to find textbook SQL injection, classic cross-site scripting, the patterns that show up in every security training. AI coding tools have largely learned to dodge those. What the scanners can’t see is what the AI is actually getting wrong.

What AI Actually Gets Wrong

Every one of Tenzai’s fifteen apps had server-side request forgery in the link-preview feature. None of them had cross-site request forgery protection. None of them set basic security headers like CSP or HSTS. Only one of the fifteen attempted rate limiting, and that implementation could be bypassed by setting a single HTTP header.

At the business-logic level: three of the five tools produced stores in which users could create products with negative prices. Four of the five didn’t verify that order quantities had to be positive numbers. Nothing about any of this looks wrong if you read the source code. The vulnerability is the absence of a business rule that nobody asked the model to include. A senior engineer would have thought to add it; the model didn’t, and the scanner couldn’t see what wasn’t there.

What Actually Works, Starting with the Cheapest Fix

The Eight-Fold Improvement That Costs Nothing

A 2022 paper at the International Conference on Software Engineering ran an online experiment with 150 professional developers. Each was given the same code review task containing two embedded security vulnerabilities. Participants were randomly assigned to groups: one reviewed with no security instructions, another got one additional sentence asking them to focus on security issues.

The finding was almost embarrassingly simple. Participants who were just told to focus on security were at least eight times more likely to detect the vulnerabilities than the no-instructions group. Adding a checklist on top didn’t improve detection any further. The one-sentence change to the review brief did almost all the work.

This is the cheapest high-impact security mitigation in the research literature. If you do nothing else after reading this piece, rewrite your review checklist to put “look for security issues” before “check for correctness and style.” That’s the 8x number. It costs nothing.

Pre-Commit Secret Scanning

GitGuardian’s data shows that Claude Code commits leak secrets at 3.2%, about twice the 1.5% baseline across all of public GitHub. The single most common vibe-coding incident pattern is a key in a JavaScript bundle, found by an automated scraper, in the first 24 hours after launch. Running gitleaks or ggshield as a pre-commit hook is a few hours of setup work and catches the Moltbook class of mistake before it ships.

Security Prompting in the Development Workflow

The FORGE 2025 benchmark found that adding security-focused prompt prefixes can reduce vulnerabilities in generated code by up to 56%. The catch is that generic warnings like “write sensitive code” don’t work. You have to name specific weakness classes and run iterative review loops in which the model audits its own output, identifies the bugs, and rewrites them.

AI as a Code Reviewer in Your PR Pipeline

In ProjectDiscovery’s test, Claude Code as a reviewer caught 41 of the 74 vulnerabilities they had confirmed, including a number of business-logic issues that no static scanner would touch. The tradeoff is false positives, but between missing real bugs and reading through noise, that isn’t a hard call.

Runtime Validation

The Neo tool, which combined AI review with runtime testing, caught 66 out of the 74 vulnerabilities in the same ProjectDiscovery test, including 24 that nothing else had found. In March 2026, Lovable embedded Aikido’s autonomous pentesting in their build pipeline at $100 per test. The equivalent test three years ago would have cost $20,000 and taken three weeks. The economics of dynamic security testing have flipped, and most security teams haven’t updated their assumptions yet.

Reasoning-Mode Models

Sonar’s leaderboard shows Claude Sonnet 4.5 producing 198 blocker vulnerabilities per million lines of generated code, while Opus 4.5 in extended-thinking mode produces 44 per million — roughly 4.5 times fewer bugs from the same family of model, just by enabling the deeper thinking mode.

Auto-Remediation

Once a vulnerability has been found, GitHub’s Copilot Autofix reduces median fix time from 90 minutes to 28. For SQL injection specifically, the fixes are about 12 times faster than manual repair.

What Not to Rely On

Traditional static analysis as your main control on AI-generated code. The empirical capture rate on high-severity bugs in that role is approximately zero. Keep static analysis for dependency scanning and known legacy patterns. Don’t tell yourself it’s doing real work against the new threat class.

The Gap That’s Getting Wider

The framing that captures most of this argument comes from Trend Micro’s research team, published in late March 2026: “The real risk of vibe coding isn’t AI writing insecure code. It’s human shipping code they never had a chance to protect.”

The model writes code that works. The founder doesn’t know what to check. The scanner is tuned for a previous decade. The reviewer wasn’t told to focus on security. The breach lives in the gap between “this works” and “this is safe to ship,” and the gap is getting wider every month.

If you put one number on a whiteboard before any others, make it eight. Then go pick the tools.