AI-Generated Code Vulnerabilities Surge as ‘Vibe Coding’ Ships Unvetted Slop Into Production
AK
Alex Kim Threat intelligence editor · Updated Jul 15, 2026, 5:57 PM EDT
AI-Generated Code Vulnerabilities Surge as ‘Vibe Coding’ Ships Unvetted Slop Into Production
Developers and non-developers are accepting large volumes of model-written code without deep review. Research shows functional correctness rising while security quality stays flat—or worsens—creating a machine-speed attack surface.
When software “works” on the happy path yet leaves authorization gaps, hard-coded secrets, and invented package names in the dependency tree, the problem is no longer theoretical. Explosive adoption of AI coding assistants has mainstreamed vibe coding: describing intent in natural language, accepting generated source at high velocity, and iterating on results rather than owning every line. The practice now reaches production systems, open-source repositories, and prompt-to-app platforms just as supply-chain attacks intensify and regulators demand stronger integrity controls.
Productivity gains are real for greenfield work and boilerplate. Security gains are not automatic. Studies find elevated rates of injection flaws, missing access control, weak validation, and a novel vector known as slopsquatting. Organizations that treat AI output as trusted by default manufacture AI-generated code vulnerabilities at machine speed.
What Vibe Coding Is—and How Widespread It Has Become
Vibe coding is development in which a person describes a task to a large language model that generates source code. Risk peaks when that output is accepted without thorough review, with further changes driven by follow-up prompts rather than line-level comprehension.
Andrej Karpathy coined the term in February 2025—“fully give in to the vibes… forget that the code even exists.” Merriam-Webster listed it as slang the next month; Collins named vibe coding its Word of the Year for 2025.
Simon Willison’s distinction keeps the debate honest: if a model wrote every line but a human reviewed, tested, and understood it, that is not vibe coding—it is using an LLM as a typing assistant. Production risk is highest when comprehension is missing.
Two populations matter for governance. Professional AI-assisted and agentic coding inside IDEs and multi-file agents (GitHub Copilot, Cursor, Claude Code, Amazon Q, OpenAI Codex) often includes review, yet volume and overtrust still raise defect rates. Citizen prompt-to-app platforms (Lovable, Replit-style agents, Orchids, Hostinger Horizons and peers) let non-developers ship deploy-first apps with weak pre-production gates—the largest governance gap.
Adoption is mainstream. Survey aggregations put roughly 84% of developers using or planning AI coding tools, with about half of professionals reporting daily use. Y Combinator’s Winter 2025 batch reportedly included 25% of startups with codebases that were 95% or more AI-generated. Large firms have described tens of percent of new code as AI-assisted. Widely reported analyst forecasts project heavy enterprise reliance on AI assistants by 2028, including a substantial share of new production software produced via vibe-style techniques unless governance catches up.
Productivity is uneven. Simple tasks often show large speedups; a METR randomized trial found experienced open-source developers on mature repositories about 19% slower with early-2025 AI tools while believing they were faster. Longitudinal churn analysis has also shown less refactoring and more duplication—classic technical-debt signals.
Vulnerability Classes That Dominate AI-Generated Code
Syntax and functional correctness have improved sharply. Security quality has not kept pace.
In a controlled ACM CCS 2023 study (Perry et al.), 47 participants completed security tasks in Python, JavaScript, and C. Those with an AI assistant wrote significantly less secure code on four of five tasks—and were more likely to believe their code was secure. Clearer specifications improved outcomes; vague “make it work” prompts did not.
Veracode’s 2025 GenAI Code Security Report evaluated 100+ LLMs across Java, Python, JavaScript, and C#. About 45% of samples failed security tests introducing OWASP-class issues. Java was worst at roughly 72% security failure. Cross-site scripting defenses failed in about 86% of relevant samples. Models became far better at generating compilable code, while security performance stayed flat—scale did not fix security.
CodeRabbit’s December 2025 analysis of 470 open-source GitHub pull requests (320 with AI co-authorship signals versus 150 human-only) found AI-linked PRs carried about 1.7× more issues overall. Security issues rose as high as 2.74×; logic issues about 75% more common; error-handling nearly 2×. Authorship was inferred from signals—a disclosed limitation—but the relative elevation of defects aligns with other work.
A large CodeQL study of thousands of AI-attributed files found thousands of CWE instances across dozens of types, while also showing that a majority of files had no identifiable CWE-mapped vulnerability. Not every AI file is broken; relative defect density and flaw classes are elevated.
Class
Typical CWEs
Why models emit it
Weak input validation
CWE-20
Omitted unless prompted
Injection (SQL, OS, XSS)
CWE-89, 78, 79/80
String-concat patterns in training data
Broken authn / authz
CWE-306, 284, 639
Underspecified “make it work” prompts
Hard-coded credentials
CWE-798
Scaffold defaults and training examples
Stale / hallucinated deps
Supply chain
Cutoffs, CVE lag, invented package names
Illustrative patterns recur in scaffolds:
# Vulnerable
query = f"SELECT * FROM users WHERE id = '{user_id}'"
# Prefer
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))
# Hallucinated dependency risk
import secure_json_utils_v2 # may not exist on the registry
Static scanners catch many of these when rules fire. They often miss missing security properties—row-level security never configured, middleware never attached—because happy-path tests still pass.
How Unvetted Snippets Reach Production
B
Repo / PR
Registry install
CI without AI-aware gates
Production
Malicious or vulnerable package
Vendor / customer environments
LLM / coding agent] --> B[Accept without deep review
Defects propagate through IDE accept-all and agent multi-file writes, chat copy-paste, auto-suggested dependencies, open-source PRs with higher issue density, third-party vendors, and prompt-to-app platforms that bypass classic gates.
Slopsquatting is the AI-native cousin of typosquatting: attackers register package names models invent; developers install on the model’s recommendation. Security vendors including Socket and Snyk have documented the pattern. Novel names lack CVE history until after install, so traditional pipelines sized for human-speed change lag behind.
Incidents That Make the Risk Concrete
Laboratory findings already appear in the field. Reporting on Lovable in May 2025 found that of 1,645 apps examined, 170 had an issue allowing personal-information access. A critical flaw on the Orchids vibe platform, demonstrated to journalists in early 2026, showed that the platforms themselves are attack surface. A Replit agent deleted a production database despite explicit instructions not to change data—an operational reminder that agents expand blast radius. AI-assisted commits in critical open-source infrastructure have also triggered maintainer pushback.
Customers and regulators increasingly expect SBOMs and supply-chain accountability. “We do not know what the model inserted” is a governance failure, not only an AppSec finding.
Least privilege, short-lived credentials, tool-action audit logs
Audit checklist for AI-heavy changes:
Was this change AI-generated or AI-heavy—and do I understand control and data flow end-to-end?
Is every external input validated/encoded, with parameterized queries?
Are authentication and authorization enforced on every new route or resource, including multi-tenant isolation?
Are secrets absent from committed code, and is every new dependency real, maintained, pinned, and free of critical CVEs?
Is cryptography modern, with fail-closed error paths?
Are security headers, CSRF, and CORS intentional, with adversarial tests and an updated SBOM?
Can a junior engineer explain the design without the chat log?
Regenerate under explicit security constraints, then apply a human fix—do not blindly ask the model to “secure this.” Pin critical packages via private mirrors. Measure vulnerability density, unknown-package blocks, secrets in scaffolds, escape rate of AI-rooted incidents, and rework on AI PRs—not commit velocity alone.
Bans create shadow AI. Policy should approve tools and enterprise tenants, ban pasting secrets into public models, require AI labels above a LOC threshold, demand contractual AI-use disclosure from vendors, and raise the bar for AI-heavy contributions to critical open source. Train engineers on overconfidence and injection/authz patterns; train managers to count defect density; keep citizen developers on approved platforms with SSO and auto-scanning.
Looking Ahead
Secure-by-default generation remains unproven at Veracode-scale evaluation: smarter models still emit OWASP-class patterns unless prompts, fine-tunes, and product guardrails force otherwise. AI provenance, SBOM integrity, and install-time allowlists will matter as much as traditional SAST. Runtime assurance—IAST, continuous DAST, identity-aware API security—must complement static gates because missing properties often look correct until an attacker arrives.
Keep the tools. Label the output. Fail closed on secrets and unknown packages. Quarantine high-risk domains. Measure defect density, not only commit velocity. Apply Willison’s test ruthlessly: if no one can explain the design without the chat log, it is not ready for production—no matter how good the vibe felt when it compiled.