Vibe Coding Has a Security Problem Nobody Wants to Talk About
The Numbers Are Bad
Andrej Karpathy coined "vibe coding" in February 2025. Stop reading diffs. Accept all changes. Copy-paste error messages. Let the AI handle it. "I just see stuff, say stuff, run stuff, and it mostly works." 4.5 million people watched that tweet. A movement was born.
A year later, we have data on what happens when millions of developers take that advice.
Veracode tested over 100 large language models across 80 coding tasks. Result: 45% of AI-generated code contains OWASP Top-10 vulnerabilities. Two years of model improvements haven't moved that number. Models get better at writing code that compiles — not at writing code that's safe.
Java hit a 70% failure rate. Python, C#, and JavaScript ranged from 38% to 45%. Cross-site scripting defenses failed 86% of the time. Log injection, 88%.
A December 2025 paper from the University of Virginia sharpened the picture. Researchers tested coding agents on 200 real-world feature requests — tasks pulled from open-source projects that had previously produced vulnerable code when humans wrote them. Agents passed functional tests 61% of the time. Of those passing solutions, only 10.5% were actually secure.
Six out of ten solutions work. One out of ten is safe. That's the ratio.
Every Iteration Makes It Worse
Here's the part that should scare anyone shipping vibe-coded software: the code gets less safe over time.
When researchers asked models to revise their output through multiple rounds — paste the error, let the AI fix it, paste the next error, the way vibe coding actually works — critical vulnerabilities increased by 37% after five iterations. Prompts emphasizing feature completion over security produced 158 new vulnerabilities. Twenty-nine of them critical.
The fix-it loop that makes vibe coding feel productive is exactly what degrades security.
5,600 Apps, 2,000 Vulnerabilities
Escape.tech scanned 5,600 publicly available vibe-coded applications built on platforms like Lovable, Bolt.new, and Create.xyz. Across 14,600 assets, they found over 2,000 vulnerabilities, 400 exposed secrets, and 175 instances of leaked personal data — medical records, bank account numbers, phone numbers.
That's a conservative count. They deliberately used passive scanning to avoid breaking anything. The real number is higher.
Real Tools, Real Flaws
Security startup Tenzai tested the five most popular vibe coding tools — Claude Code, OpenAI Codex, Cursor, Replit, Devin — by building three identical applications with each. Fifteen apps. Sixty-nine vulnerabilities. Six critical. Four of those critical flaws came from Claude Code.
None of the tools produced exploitable SQL injection or cross-site scripting. Classic bugs are well-represented in training data. Models have learned to dodge them.
Business logic is another story. Access control failures. Authorization bypasses. Flaws where you need to understand what the application should do, not just what it can do. Claude generated PHP code that deleted products without checking user authentication. Most agents allowed users to order negative quantities. Negative prices when sellers created products.
Tenzai's researchers put it plainly: "While human developers bring intuitive understanding that helps them grasp how workflows should operate, agents lack this common sense and depend mainly on explicit instructions."
Tell an AI to build a payment system. It won't understand that users shouldn't modify other users' orders — not unless you spell it out. Vibe coding is specifically about not spelling things out.
The Supply Chain Angle
Not just the code the AI writes. The code the AI trusts.
CVE-2025-54135 (CurXecute): arbitrary command execution on a developer's machine through Cursor's MCP connection. CVE-2025-53109 (EscapeRoute): Anthropic's own MCP server let attackers read and write arbitrary files — access restrictions simply didn't work. CVE-2025-55284: data exfiltration from Claude Code through DNS-based prompt injection during code analysis.
Then there's the Nx supply chain compromise. Attackers exploited a vulnerability in AI-generated code to steal publishing credentials, then used those credentials to trojanize a popular development tool. One flawed fragment opened the entire distribution chain.
A Security Tool That Wasn't Secure
January 2026. Security firm Intruder used AI to generate code for a honeypot — a tool designed to capture attack traffic. During testing, attackers exploited a vulnerability in the AI-generated honeypot itself.
What happened: the AI added logic to extract client-supplied IP headers and treat them as trusted data. Headers are user-controllable. An attacker injected a payload, gained partial control of program execution, and could have escalated to file disclosure or server-side request forgery.
Neither Semgrep nor GoSec caught it. Static analysis can't reason about trust boundaries.
An experienced security team, building a security tool, using AI to write the code, missed a basic trust violation because the AI put it there and nobody read the diff. One sentence summary of the vibe coding failure mode.
What Doesn't Work
"Just add security prompts." Tested. Doesn't work.
Researchers tried security-focused prompting, CWE self-identification, direct hints about which vulnerability categories to watch for. None of it reliably closed the gap between functional and secure.
This isn't a prompting problem. It's a training problem. Models learn to produce code that passes tests, not code that resists attacks. And vibe coding's incentive structure — speed, acceptance, minimal review — actively selects against the slow, suspicious reading that catches authorization flaws and trust boundary violations.
Palo Alto Networks recently introduced SHIELD, a security governance framework specifically for vibe coding. That a major security vendor built a dedicated framework tells you how real the problem has become.
The Actual Risk
Nobody's going to stop vibe coding. The productivity gains are real. But right now the industry is building a massive inventory of applications where the person who deployed the code has never read it, and the system that wrote it has a 45% chance of including a vulnerability that static analysis can't catch.
The Tea dating app leaked 72,000 images including 13,000 government IDs because the AI set up Firebase with default permissions and nobody checked. Enrichlead, whose founder proudly announced "100% of code written by Cursor AI," launched with authorization flaws that let anyone access paid features.
The security industry has a term for software nobody audits: legacy code. Vibe coding is producing legacy code at startup speed.
What Actually Helps
Three things, none of them exciting:
Read the diffs. Not all of them. But every authentication flow, every authorization check, every data access pattern. If the AI writes a payment handler, read the payment handler. Karpathy can afford to vibe code his personal projects. You probably can't afford to vibe code your users' data.
Test for authorization, not just function. Your CI pipeline catches crashes. It doesn't catch "user A can read user B's records." Write those tests yourself. The AI won't write them because it doesn't know they matter.
Treat AI code like vendor code. You wouldn't deploy a third-party library without reviewing its security posture. AI-generated code deserves the same suspicion, for the same reason: you didn't write it and you don't know what assumptions it made.
Vibe coding is a tool. Like every tool, it has a failure mode. The failure mode here is a class of bugs invisible to automated testing, undetectable by static analysis, produced by a system that doesn't understand what your application is supposed to prevent.
The only defense is a human who reads the code and asks: "but should this be allowed?"
That's not a vibe. That's engineering.

