The Vulnerability Count in AI-Generated Code Just Tripled, Twice, in a Row

Most of what circulates about AI-generated code and security is a war of anecdotes. Someone posts a horror story, someone else posts a productivity win, and the argument never resolves because neither side is holding a dataset. Georgia Tech's Systems Software & Security Lab built something that resolves it, at least partially: the Vibe Security Radar, a project that pulls entries from public vulnerability databases — CVE.org, NVD, GitHub Advisory Database, OSV, RustSec — finds the commit that fixed each one, and traces backward through git history to determine whether an AI coding tool introduced the original flaw. They track signatures from roughly 50 tools, including Claude Code, Copilot, Cursor, Devin, Windsurf, and Aider.

The monthly count: 6 in January 2026, 15 in February, 35 in March. That's not linear growth. That's the number roughly doubling each month, three months running, and March alone produced more confirmed cases than all of 2025 combined. By the end of March, the project had 74 confirmed cases total — 14 rated critical severity, 25 rated high. More than half the confirmed list is serious enough that "we'll patch it eventually" isn't really an option.

The number that matters more than the trend line

Here's the part I keep coming back to. Researcher Hanqing Zhao, working from the same dataset, estimates the true count is 5 to 10 times higher than what the radar can detect — because detection depends on metadata. If a commit carries an explicit AI co-author trailer, or a bot email address, or a tool-specific marker, it gets flagged. If a developer generates code in one tool and pastes it into an editor without that trail, the radar has nothing to trace. Which means the 74 confirmed cases are a floor, not a count, and the realistic range sits somewhere between 400 and 700 AI-introduced vulnerabilities already sitting in open-source projects, unflagged.

That reframes the trend line. The visible curve — 6, 15, 35 — isn't the actual growth rate of the problem. It's the growth rate of what's visible, in a population where most of the iceberg is admitted to be below the waterline by the people who built the instrument measuring it.

What the breakdown by tool actually tells you, and doesn't

Of the 74 confirmed cases, Claude Code accounts for 27 — the largest single share, ahead of Copilot's 4, Devin's 2, and Cursor's 1. I use Claude Code daily, so I want to be straightforward about what that number does and doesn't support. The researchers themselves flag the likely explanation: Claude Code's commit signatures are unusually explicit and easy to trace, and its adoption in open-source workflows is high, both of which inflate its share of a metadata-dependent count without saying anything about the relative security of its output compared to a tool that leaves a fainter trail. A ranking built on traceability isn't the same as a ranking built on defect rate, and treating the two as interchangeable is exactly the kind of category error the underlying data doesn't support. What the aggregate trend does support — regardless of which tool tops the list — is that AI-assisted commits are entering production and open-source codebases with security review skipped often enough to show up as a measurable, accelerating pattern.

Veracode's Spring 2026 update adds the uncomfortable second half of the picture: security pass rates on AI-generated code have stayed flat around 55% even as the underlying models have visibly improved at everything else. The models write code that compiles more reliably, handles edge cases better, and reads more like something a senior engineer would produce. None of that has moved the security number. Capability and safety are apparently not the same axis, and nothing about scaling one is currently scaling the other.

What it looks like when it goes wrong for one person

The aggregate data is useful for arguing about industry trends. It's the Enrichlead case that made the mechanism click for me, because the failure wasn't exotic.

In March 2025, a founder building a sales lead-generation SaaS — entirely with Cursor, by his own account zero handwritten code — launched, and within two days posted that he was under attack: maxed-out API usage, users bypassing the subscription paywall, random data appearing in the database. What had actually happened was almost boring. Every security control lived on the client side. The subscription check was a conditional render in the frontend — change a value in the browser console and the paywall disappeared. The API keys were sitting directly in the shipped JavaScript bundle, visible to anyone who opened the network tab. The database had no row-level security and no query-level restrictions, so anyone with the API endpoint — which was, again, visible in the frontend — could read, write, or delete freely. No rate limiting anywhere, so the API key exposure turned into a billing disaster before anyone had diagnosed what was wrong.

None of that required an attacker in the traditional sense. Curious users found it by opening dev tools. The founder tried prompting his way back out of it, and by his own account the AI kept breaking other parts of the codebase with each fix — because the application was roughly 15,000 lines he hadn't written and couldn't read, and patching one hole meant touching code whose dependencies nobody, including the AI mid-session, had ever mapped. The product shut down within a week.

What makes this worth sitting with isn't that the founder was careless. It's that the AI built precisely what it was asked for. Told to add a subscription paywall, it produced a working paywall UI — because a paywall UI is what "subscription paywall" specifies, and enforcing it server-side is a separate, unstated requirement that a human engineer applies out of instinct and an AI applies only if someone thinks to ask. The gap between "a working paywall" and "an enforced paywall" is exactly the gap between a demo and a product, and it's invisible until someone finds it from the outside.

The tool itself can be the vulnerability, not just its output

There's a second category worth naming separately, because it's a different failure mode entirely: the coding tool as attack surface, rather than the code it generates.

In June 2025, a security researcher reported a vulnerability in GitHub Copilot that Microsoft patched as CVE-2025–53773, rated CVSS 7.8. The attack chain: a malicious instruction gets planted somewhere Copilot will read it — a GitHub issue, a PR description, a code comment — sometimes hidden in invisible Unicode so it's undetectable to a human scanning the same text. The instruction tells Copilot to add one line to a settings file, enabling what the security community nicknamed "YOLO mode" — auto-approval of tool actions without user confirmation. Once that's set, the same injected prompt can tell Copilot to run arbitrary shell commands, silently, with whatever privileges the developer's own account has. Researchers flagged a wormable variant: a compromised repository could plant the same instruction in files that get pushed onward, so every developer who opens the infected repo with Copilot enabled inherits the same payload.

Microsoft fixed the specific vulnerability. The design pattern it exploited — an AI coding tool with the ability to modify files and execute commands with minimal confirmation — isn't unique to Copilot. It's close to the operating assumption of every agentic coding tool on the market, including the ones I use every day. That doesn't mean the model is unsafe to use. It means the permission model around it is now a real part of the attack surface, in a way that didn't exist when the worst thing an editor could do was suggest a bad autocomplete.

What I'm actually doing differently

Nothing here is a reason to stop using AI coding tools, and I don't think that's the honest takeaway even from a dataset this stark. It's a reason to stop treating AI-generated code as pre-reviewed just because it compiled and passed the tests I thought to write.

The concrete change: I've started treating anything an agent touches that involves auth, payment logic, or direct database access as requiring the same review discipline I'd apply to a pull request from someone I'd never worked with before — because functionally, that's what it is. Not a vibe check on whether the feature works. A specific pass for the categories Enrichlead got wrong: is enforcement happening server-side, are secrets actually out of anything shipped to the client, does the database have access controls that don't depend on the application layer behaving correctly. And separately, a look at what permissions the tool itself has been granted — whether file modifications and command execution are actually gated by a confirmation step, or whether convenience settings have quietly turned that off somewhere along the way.

None of this is expensive. It's the five-minute check that, in every incident above, nobody happened to run before shipping. The Georgia Tech data doesn't say AI-generated code is uniquely dangerous. It says the volume of code shipping without that five minutes is growing faster than anyone's catching it, and that the trend was invisible until someone built the instrument to measure it.

Let's Connect! I'm Bhavyansh — a software engineer sharing lessons from building and breaking production systems. Subscribe to my Substack — thanks for reading.