Quick Answer
The headline number: 62% of AI-generated code contains security vulnerabilities, per OX Security's 2026 analysis, with other recent studies landing between 40% and that figure depending on methodology. The trend line is worse than the snapshot: AI-linked CVEs grew roughly 6x from January to March 2026 — 6 CVEs in January, 35 in March — according to Georgia Tech's Vibe Security Radar, via a Cloud Security Alliance research note. And across 576,000 code samples generated by 16 models, 19.7% of the 2.23 million package references were to packages that don't exist, per the USENIX Security paper "We Have a Package for You!". None of these are api-doctor's numbers — sources linked throughout. The short version of what to do about it: the failures are concentrated in a handful of repeatable categories, which means deterministic checks catch most of them, and "have the AI review it" catches much less than you'd hope.
The numbers, before the takes
Vibe coding headlines run on fear, and fear is a bad input for engineering decisions. So here's the actual data, with sources, before any interpretation.
Vulnerability density. OX Security's analysis found 62% of AI-generated code samples contained at least one security vulnerability. Other studies over the past two years have landed lower — the commonly cited range across recent research is 40–62%, with the spread explained by what counts as a vulnerability, which languages were tested, and how realistic the prompts were. Pick whichever end of the range you find credible; there is no study that finds AI-generated code to be reliably secure by default.
Growth in real-world impact. Vulnerability density in lab samples is one thing; shipped CVEs are another. Georgia Tech's Vibe Security Radar, summarized in a Cloud Security Alliance research note from April 2026, tracked CVEs attributable to AI-generated code: 6 in January 2026, 35 in March. That's roughly a 6x jump in one quarter. Part of that curve is better attribution — researchers are getting better at identifying AI-written code in disclosed vulnerabilities — but part of it is the sheer volume of AI-generated code hitting production compounding month over month.
Hallucinated dependencies. From the USENIX Security study "We Have a Package for You!", also cited in the CSA research note: 16 models generated 576,000 code samples containing 2.23 million package references, and 19.7% of those references pointed to packages that do not exist. Roughly one in five dependency suggestions is a library the model invented.
And the case study everyone points to. In January 2026, the Moltbook incident put a face on the statistics: a founder shipped an app written, by their own description, entirely by AI — which then exposed 4.75 million records, including 1.5 million API tokens. It's the extreme case, not the typical one. But it's the extreme case of exactly the pattern in the data above, not a different phenomenon.
That's the landscape. Now the more useful question: what's actually going wrong in that 62%?
What's actually going wrong
The stats read like AI code fails in some diffuse, unknowable way. It doesn't. When you look at the failures underneath these numbers, they cluster into a handful of categories that repeat across every model and every coding agent — because they all come from the same root cause. Models optimize for code that runs, and security is precisely the set of properties you can't observe by running the code once.
Hardcoded secrets. The Moltbook breach wasn't 1.5 million tokens exposed through some exotic attack — it's what happens when secrets live where they shouldn't, at scale. Agents hardcode API keys because a literal string is guaranteed to work and an environment reference isn't, and they paste keys into client bundles because they have no model of your deployment boundary. The demo works identically either way, which is why it survives review.
No idempotency handling. Payment and mutation endpoints generated without idempotency keys work perfectly in testing, then double-charge customers the first time a network retry happens in production. Idempotency is invisible in the happy path, so a model optimizing for the happy path never learns it's load-bearing.
Skipped webhook verification. Agents generate webhook handlers that parse the payload and skip signature verification, because unverified handlers are simpler and test fine with the provider's CLI. The result is an endpoint that treats anyone on the internet as Stripe. The same happy-path blindness produces the auth flow mistakes that pattern-match a login flow from stale examples and quietly lock users out — or let the wrong ones in.
Hallucinated dependencies. That 19.7% figure is a supply chain problem wearing a correctness costume. When a model imports a package that doesn't exist, the failure isn't just a broken build — attackers register those hallucinated names on npm and PyPI ("slopsquatting") so the install succeeds and delivers their code. The model's confidence is the attack surface.
Four categories, one root cause: everything on this list is invisible at demo time. Vibe coding's core loop — describe, generate, run, looks good, ship — validates exactly the properties these failures don't touch.
Why review doesn't catch it — including AI review
The obvious response to "AI code is 62% vulnerable" is "review it harder." Two problems with that.
Human review doesn't scale to agent output. The economics that make vibe coding attractive — dramatically more code per engineer-hour — are the same economics that guarantee less scrutiny per line. Nobody adopts an agent to write code faster and then reads the output at pre-agent speed. The Moltbook founder wasn't uniquely lazy; they were an honest preview of what review coverage looks like when generation is free.
So teams reach for the next idea: have another AI review it. This is where the logic quietly breaks, and it's the argument I've made at length in why AI can't test AI code: the reviewing model shares the training priors of the writing model. If the priors say webhook handlers usually skip verification — because the training data is full of tutorial code that skips it — then the reviewer finds that pattern as unremarkable as the writer did. You're asking a system to flag output as wrong that it would have produced itself. It catches some things, genuinely. It's least reliable on exactly the confident, plausible, wrong patterns that dominate the failure categories above. And it's probabilistic: run it twice, get two different reviews, and your CI pipeline is now a slot machine.
That March CVE number — 35, up from 6 — is what it looks like when an industry's review capacity gets outrun by its generation capacity, with probabilistic review as the main backstop.
What actually works: deterministic checks
Here's the structural good news buried in the bad data: because the failures cluster into repeatable categories, they're checkable by machines that don't share the model's priors.
An AST rule parses code into a syntax tree and matches fixed patterns encoded from provider documentation. A literal string passed to an SDK constructor. A webhook handler with no signature verification call before the payload is used. A payment mutation with no idempotency key parameter. A "use client" file referencing a server secret. The rule fires or it doesn't — same input, same verdict, every run. No priors, no vibes, no second opinion needed. The full argument for why this beats prompting a reviewer model is in AST rules vs LLM prompts, but the one-line version: determinism is the one property the failure mode can't route around.
This is what api-doctor is: deterministic AST rules for the API-integration failure categories above, across providers like Stripe, Supabase, Resend, Firebase, and Twilio, run with one command:
npx @api-doctor/cli .
Put it in pre-commit or CI and the loop closes: the agent generates at agent speed, and every commit passes through a checker that is immune to plausible-looking wrong code. Hallucinated dependencies have their own deterministic answer — verify every import against the real registry (does the package exist, is it the package you think it is) before install, not after.
To be clear about scope: AST rules check API contract correctness, not your business logic or architecture. This isn't "don't use AI to write code," and it isn't "AI review is useless" — LLM review still earns its place on architecture and logic. It's a narrower claim the data supports directly: the failure categories driving these statistics are mechanical, repeatable, and machine-checkable, and the checking machine should not be built from the same material as the bug. If you're setting up guardrails for a specific agent, start with the Claude Code secrets management guide — same layered idea, applied to the tool most people are actually running.
Frequently asked questions
Q: What percentage of AI-generated code has security vulnerabilities? Between 40% and 62% of samples, depending on the study — OX Security's 2026 analysis sits at the top of that range. The spread is methodology; the floor is nowhere near zero.
Q: Are AI-linked CVEs really growing 6x? That's the January-to-March 2026 jump (6 to 35 CVEs) from Georgia Tech's Vibe Security Radar, per the CSA research note. One quarter of data, so treat the multiplier cautiously — but the direction is consistent with more AI code in production plus better attribution.
Q: Should I stop using AI coding agents? The data doesn't say that, and I wouldn't either — I build with them daily. It says the generate-run-ship loop validates the wrong properties, so you add checks for the properties it misses: deterministic scanning for the known failure categories, registry verification for dependencies, and human review budgeted for architecture rather than spent hunting hardcoded keys a machine finds instantly.
Q: Isn't AI review better than nothing? Better than nothing, yes. The trap is treating it as sufficient — it's weakest on exactly the confident-but-wrong patterns that dominate these statistics, because the reviewer shares the writer's priors. Use it for logic and architecture; use deterministic rules for the contract-level failures.
Next Steps
- Scan your project now —
npx @api-doctor/cli . - See what our own scans find in real codebases: the state of AI code quality — first-party data, not another citation
- The how-to companion to this post: vibe coding isn't the problem, skipping verification is
- See all rules on GitHub
- Read the deeper argument: why you can't test AI code with AI
- Lock down your own setup: hiding API keys from AI coding agents