Vibe coding's security debt: the AI-generated code CVE surge
Most of the AI-coding-security coverage this year has been about the tools themselves: prompt-injection-to-RCE in Cursor, symlink hijacks across six agents at once, trust-dialog bypasses in Claude Code and Copilot. Those are real and I've written about several of them. But they're only half the bill. The other half is quieter and bigger: the security debt in the code these tools write for you.
The numbers are starting to land
Georgia Tech's Vibe Security Radar tracked 35 CVEs in a single month (March 2026) directly attributable to AI coding tools, and the researchers estimate the true count is five to ten times higher once you account for the open-source projects that never file a CVE at all. The Cloud Security Alliance published a research note this year on the same trend under a blunt title: an AI-generated code vulnerability surge.
That tracks with what shows up in production. When AI writes a larger share of your code, you inherit a larger share of whatever bad habits live in its training data. And the training data is full of tutorial-grade code: the kind that hardcodes a secret to keep the example short, concatenates a SQL string because parameterized queries are three extra lines, or sets CORS to a wildcard so the demo works on localhost.
Why generated code skews insecure
Three patterns explain most of what I see when I audit AI-assisted code.
It optimizes for "works," not "safe." A model rewarded for producing code that runs will reach for the shortest path to a green checkmark. Input validation, authorization checks, and error handling are the parts a human skips under deadline pressure, so they're underrepresented in the training corpus, so the model skips them too. The output compiles, passes the happy-path test, and ships with a missing auth check on an admin route.
It is confidently wrong about security primitives. Ask for a password hash and you might get MD5 with no salt, presented with the same calm tone as a correct argon2 implementation. The model has no internal signal that one is a liability. There's no warning label, so a reviewer who trusts the fluency ships the flaw.
It hallucinates dependencies. Slopsquatting is the supply-chain version of this problem: a model invents a plausible package name, an attacker registers that name with a payload inside, and your install pulls it. I wrote about that one separately, but it belongs in this list because it's the same root cause. Confident output, no grounding in what exists.
The volume multiplier is the real story
Here's the part the raw CVE count understates. AI doesn't change the per-line vulnerability rate as much as it changes the line count. If a team ships five times more code at a constant defect rate, it ships five times more defects. Generation speed scaled up overnight. Review bandwidth did not.
That gap is where the debt accrues. A senior engineer reviewing a 40-line human diff catches the missing validation. The same engineer rubber-stamping a 600-line AI diff at the same pace does not. The tooling made it trivial to produce code faster than any human can meaningfully read it, and the security review process never got the same upgrade.
So you get a compounding effect: more code, written faster, reviewed shallower, by people who increasingly assume the AI got it right because it usually does on the surface.
What I do about it
None of this means stop using AI to write code. I use it every day. It means treating the output like what it is.
Review AI code like a junior dev's PR, not your own. The dangerous mode is reading generated code as if you wrote it, which means skimming for intent and assuming the details are fine. Read it as if a fast, fluent, slightly overconfident junior submitted it. Look specifically at auth checks, input handling, secret management, and anything touching a query or a file path.
Keep a security linter in the loop. Static analysis that flags SQL concatenation, hardcoded secrets, and weak crypto catches the boring high-frequency failures before review. The point is to spend human attention on the subtle stuff by letting a tool handle the obvious stuff. This matters more, not less, as generated volume goes up.
Pin and audit dependencies. Lockfiles, a dependency-audit step in CI, and a quick sanity check on any package name you don't recognize. If the AI suggested a library you've never heard of, confirm it exists and is maintained before it lands in your install graph.
Scan the deployed surface, not the repo. Code review catches what's in the diff. It misses the misconfigured header, the exposed endpoint, the debug route that survived to production. A scan of the live surface closes the gap between "the code looked fine" and "the running app is fine," which are not the same claim when AI is generating config and infra too.
The honest summary
The AI-coding-tool CVEs get the headlines because a one-click RCE in a popular editor is dramatic. The generated-code debt gets less attention because it's diffuse: a missing check here, a weak hash there, a hallucinated package once a quarter. But it's the larger liability over time, because it scales with how much code you ship, and we're all shipping more.
The fix is not new. It's the same review discipline and the same scanning that good teams already had, applied with the awareness that the volume going through that pipeline went up by a factor nobody planned for. Treat the AI as a productive junior whose work you always read. The teams that do this will be fine. The ones that ship the green checkmark unread are the ones filling next month's radar.