Is Vibe Coding Safe? What the Vulnerability Data Actually Shows

Three independent data sources point at the same conclusion from different angles. Veracode's 2025 GenAI Code Security Report tested over 100 large language models across 80 real coding tasks and found generative AI introduces security vulnerabilities in 45% of cases overall, with results varying sharply by language: Java failed more than 70% of the time, while Python, C#, and JavaScript ranged from 38% to 45%. Critically, this pass rate has not meaningfully improved across testing cycles from 2025 into 2026 despite newer model releases.

Escape.tech's 2026 scan took a different approach: rather than testing models on synthetic tasks, it scanned 1,400 real, already-deployed vibe-coded production applications. 65% had security issues, 58% contained at least one critical vulnerability, and the scan surfaced more than 400 exposed secrets across the sample. This is the more concerning of the two datasets, because it measures what's actually running in production rather than what a model produces in a lab test.

Academic research on GitHub Copilot specifically (Pearce et al., one of the earliest empirical studies in this area) found approximately 40% of generated programs contained vulnerabilities across a sample of 1,689 programs, with C code performing worse (around 50% vulnerable) than Python (around 39%). The consistency across a vendor benchmark, a real-world production scan, and independent academic research on a different tool is what makes this a data-backed risk assessment rather than an anecdotal concern.

The vulnerability classes showing up across these studies are not exotic. Research cited by the Cloud Security Alliance found every application tested lacked CSRF protection and had no security headers configured, and every tool evaluated introduced server-side request forgery (SSRF) vulnerabilities. In the same body of research, 86% of generated samples failed to defend against cross-site scripting and 88% were vulnerable to log injection.

Secrets exposure is a distinct and separately measured problem: AI-assisted commits expose secrets at more than double the rate of human-only commits (3.2% versus 1.5%). This tracks with how vibe coding typically works in practice -- an AI model given a task like "connect this to the database" will often hardcode a connection string or API key directly into the generated code rather than wiring it through an existing secrets management pattern the AI has no visibility into.

The throughline across all of these failure modes is that they are the kinds of vulnerabilities standard SAST tooling and secrets scanners are specifically built to catch -- which is what makes the fix tractable rather than open-ended.

The practical fix is treating AI-generated code as an untrusted contribution to the codebase, not a trusted one, and applying the same controls you'd apply to any external code you didn't personally write and review.

Run SAST scanning on every commit, not just before a release cut -- given the consistency of the CSRF, SSRF, XSS, and log injection findings above, a scanner configured for OWASP Top 10 coverage will catch a meaningful share of what these studies found. Add pre-commit secrets scanning specifically, since the AI-assisted secrets exposure rate is double the human baseline and this is one of the cheapest categories to catch automatically before it ever reaches a repository. Verify dependencies and run SBOM checks for hallucinated or typosquatted package names -- AI coding models have a documented failure mode of suggesting packages that don't exist, which attackers have in turn started registering preemptively. Require a human review gate specifically for authentication, authorization, cryptographic implementations, and any code path handling untrusted input, since these are the categories where a plausible-looking but subtly wrong implementation is hardest for automated tooling to catch and most consequential if it ships.

None of this requires slowing down AI-assisted development in general. It requires putting the same SDLC gates in front of AI-generated code that a security-mature team already puts in front of a first-time external contributor's pull request.