Vibe Coding

AI-Generated Code Security: 92% Have Critical Flaws

Zack Jones · June 6, 2026

Vibe CodingVibe Coding Watch

92% of AI-generated codebases contain at least one critical vulnerability. That figure comes from Sherlock Forensics, which conducted security assessments on dozens of applications built with GitHub Copilot, Claude, ChatGPT, and Cursor between January and April 2026. The average AI-coded application had 8.3 exploitable findings.

This is the security article we flagged in our earlier piece, What Is Vibe Coding?. That article explained the trend. This one quantifies the risk.

The data from multiple independent research teams now converges on the same conclusion: AI coding tools produce functional code at extraordinary speed, and that code carries measurable, systemic security debt.

The Velocity-Vulnerability Tradeoff

In September 2025, Apiiro published one of the first large-scale empirical studies of AI-assisted development. Their Deep Code Analysis engine monitored 7,000+ developers across 62,000 repositories at Fortune 50 enterprises. The results were stark.

AI-assisted developers produced 3-4x more commits than their non-AI peers. But those commits were packaged into fewer pull requests overall, each one significantly larger in scope, touching more files and services per change. By June 2025, AI-generated code was introducing over 10,000 new security findings per month across the repositories studied. That represented a 10x spike in just six months, from December 2024 to June 2025.

The pattern is consistent: velocity up, review quality down.

AI-assisted teams shipped 10x more security findings while PR volume actually fell by nearly a third. Fewer reviewers were looking at larger, more complex changesets. The traditional gate that catches vulnerabilities before they reach production was being bypassed not by policy failure, but by sheer volume.

Credential exposure followed the same trajectory. Apiiro found that AI-assisted developers exposed Azure Service Principals and Storage Access Keys at nearly twice the rate of non-AI peers. Across public GitHub commits, AI-generated code showed a 3.2% secret-leak rate compared to a 1.5% baseline.

74 CVEs and Counting

Georgia Tech’s AI Code CVE Tracker has been tracing vulnerabilities back to their original AI-authored commits across open-source repositories. By March 2026, the project had confirmed 74 CVEs across approximately 50 AI coding tools.

The acceleration is significant. January 2026 saw 6 confirmed CVEs. February: 15. March: 35. AI coding tools shipped more CVEs in March 2026 than in all of 2025.

Lead researcher Hanqing Zhao estimates the actual number of AI-linked vulnerabilities in the open-source ecosystem is five to ten times higher than what the tracker detects. Many AI-assisted commits lack the metadata signatures needed to trace them back to their origin. The estimated actual total: 400-700 AI-introduced CVEs across the open-source ecosystem.

The vulnerability types are not random. Privilege-escalation paths increased 322%. Architectural design flaws increased 153%. Approximately 20% of AI-generated code samples reference packages that do not exist, a hallucination pattern attackers exploit through “slopsquatting,” where they register the hallucinated package names and populate them with malicious code.

Case Study: Lovable’s 48-Day Exposure

In April 2026, the vibe coding platform Lovable provided a concrete demonstration of what these statistics look like in production.

Lovable, valued at $6.6 billion with eight million users, had a broken object-level authorization (BOLA) vulnerability that allowed any free account holder to access source code, database credentials, AI chat histories, and customer data belonging to other users. Security researcher @weezerOSINT disclosed the flaw.

The exposure window ran from February 3 to April 20, 2026. Forty-eight days. Every project created before November 2025 was potentially affected, exposing tens of thousands of developers and their end users.

Lovable’s initial response made the situation worse. The company first stated it “did not suffer a data breach,” calling the exposed data “intentional behaviour.” It then blamed its own documentation. Then it blamed its bug bounty partner HackerOne, claiming reports were “closed without escalation.”

The Next Web described it as a “structural failure of vibe coding security.” That framing is accurate. The vulnerability was a basic authorization check, the kind of flaw a manual code review catches on the first pass. But when code generation is automated and review processes are not scaled to match, basic flaws survive to production.

Mapping the Risks

The vulnerabilities emerging from AI-generated code map cleanly to established frameworks. Organizations already using OWASP and CIS have the taxonomy they need. What they may lack is the operational process to apply those frameworks to AI-generated output.

OWASP LLM Top 10

The OWASP Top 10 for Large Language Model Applications identifies the relevant risk categories:

Insecure Output Handling (LLM02): Applications that trust LLM-generated responses without validation, sanitization, or constraints. When developers accept AI-generated code without review, they are accepting unvalidated output directly into their codebase. The downstream risks include XSS, SSRF, and remote code execution.
Supply Chain Vulnerabilities (LLM03): AI models trained on public repositories may recommend deprecated, vulnerable, or nonexistent dependencies. The 20% hallucination rate for package references creates a direct supply-chain attack surface.
Sensitive Information Disclosure (LLM06): Developers pasting credentials, API keys, and internal configurations into AI prompts risk those values being logged, cached, or leaked. The Lovable incident demonstrated this at platform scale.

CIS Controls

Several CIS Critical Security Controls apply directly to the AI-generated code problem:

CIS Control 16 (Application Software Security): Requires establishing and maintaining a secure application development process, including code review. AI-generated code that bypasses code review violates this control at a procedural level.
CIS Control 2 (Inventory and Control of Software Assets): The hallucinated-dependency problem maps here. Organizations need to verify that every package referenced in AI-generated code actually exists and is the intended package.
CIS Control 3 (Data Protection): Credential exposure in AI-assisted commits is a data protection failure. The 2x credential exposure rate documented by Apiiro represents a measurable gap.

What Organizations Should Require

AI coding tools are not going away. 25% of startups in Y Combinator’s Winter 2025 cohort reported codebases that were 95% AI-generated. The question is not whether developers will use these tools. It is whether organizations will establish governance before the security debt compounds further.

These are the minimum controls that should be in place before AI-generated code reaches production.

Mandatory code review for AI-generated output. Treat AI-generated code the same way you treat code from a new contractor: review everything. The Apiiro data shows that PR volume dropped while commit volume surged. That gap is where vulnerabilities enter production. Require that AI-generated changes go through the same review gates as human-written code.

Automated security scanning in CI/CD. Static analysis, dependency checking, and secret detection should run on every commit, not as a periodic audit. The 3.2% secret-leak rate in AI-assisted commits means credentials are entering repositories faster than manual review can catch them. Automate the detection.

Dependency verification. Every package referenced in AI-generated code should be verified against a known-good registry before it is installed. The 20% hallucination rate for package references is an open invitation for supply-chain attacks via slopsquatting.

Prompt hygiene policies. Developers should never paste credentials, API keys, internal architecture details, or customer data into AI coding prompts. Enforce this through policy and monitor for violations through secret-scanning tools that cover prompt logs where available.

AI code provenance tracking. Establish metadata standards that identify which code was AI-generated, which tool produced it, and when. Georgia Tech’s CVE tracker can only trace vulnerabilities to AI-authored commits when the metadata exists. Without provenance tracking, organizations cannot measure their own exposure.

Periodic security assessments that include AI-generated code. Traditional application security assessments may not account for the specific vulnerability patterns introduced by AI coding tools. Assessments should explicitly cover AI-generated code, with attention to the categories where AI tools fail most frequently: authorization logic, credential handling, and dependency management.

The Governance Gap

The data is unambiguous. AI coding tools accelerate development. They also accelerate the introduction of security vulnerabilities, at a rate that outpaces the productivity gains.

Organizations that have adopted AI coding tools without updating their security governance are accumulating risk. The 92% figure from Sherlock Forensics, the 10x finding rate from Apiiro, the accelerating CVE count from Georgia Tech, and the Lovable incident all point to the same gap: code generation has been automated, but code governance has not.

Closing that gap does not require banning AI coding tools. It requires treating AI-generated code as untrusted input and applying the same verification standards that organizations already use for third-party code, open-source dependencies, and junior developer output.

The frameworks exist. The controls are defined. The missing piece is operational adoption.

Sources

← Back to all posts