CyberIntelAI
·6 min read

Vibe Coding Is a Security Risk: The Hidden Cost of AI-Generated Code

Developers are shipping AI-generated code faster than ever. Security researchers are finding the vulnerabilities just as fast.

"Vibe coding" — the practice of describing what you want to build and letting an AI generate the implementation — has become the default workflow for a growing share of developers. Tools like Cursor, Windsurf, and GitHub Copilot make it trivially easy to ship features at speed. But the security tradeoff is no longer theoretical: academic studies have shown code-generating models repeatedly produce CWE-class weaknesses such as SQL injection and cross-site scripting, and real-world supply-chain incidents like the ctx/colourama typosquatting campaign on PyPI and the 2024 ultralytics compromise show how quickly a single unsafe install can turn developer convenience into an attack path.

The Problem Isn't That AI Writes Bad Code

The framing of "AI writes insecure code" is slightly off. AI models write code that works — that passes the tests, satisfies the prompt, and ships the feature. The security problem is that working code and secure code are not the same thing, and AI models optimized for usefulness have no particular incentive to distinguish between them.

When a developer asks a coding assistant to "add user authentication," the model will generate something functional. Whether it uses parameterized queries, properly hashes passwords with bcrypt or Argon2, validates session tokens, and avoids timing attacks depends on the model's training, the specificity of the prompt, and luck. The developer, trusting that the code works, often doesn't look closely enough to find out.

What Researchers Are Finding

Security researchers have systematically tested AI-generated code for common vulnerability classes. A widely cited NYU study, Asleep at the Keyboard?, found that participants using OpenAI's Codex were more likely to produce insecure solutions in several scenarios even while believing their code was more secure. Trail of Bits has also documented how LLM-assisted development can introduce familiar classes of weaknesses, and Snyk has repeatedly shown AI-generated examples that include issues like SQL injection, XSS, and unsafe dependency choices when prompts omit explicit security requirements.

SQL injection appears when prompts ask for database queries without mentioning parameterization, for example generating string-concatenated SQL instead of prepared statements. Cross-site scripting appears when prompts ask for user-facing output without mentioning escaping or templating safeguards. Insecure deserialization, hardcoded credentials, path traversal, and SSRF all map cleanly to well-known CWEs and OWASP Top 10 categories, and they continue to show up in code generated by leading models. The models aren't malicious; they're pattern-matching to "code that looks like it does what was asked."

The Confidence Gap

What makes vibe-coded vulnerabilities particularly dangerous is the confidence gap: developers trust AI-generated code more than they trust their own first drafts. There's a psychological effect at play — the code looks polished, is syntactically correct, handles obvious edge cases, and was generated by a system trained on billions of lines of code. It feels authoritative.

This confidence means developers are less likely to scrutinize AI-generated code in code review, and security teams often lack the bandwidth to review AI-generated PRs at the velocity they arrive. Vulnerabilities that would have been caught in review slip through. The same dynamic has played out in other high-confidence software failures: polished output gets a pass that rough draft code would not.

The Dependency Problem Is Worse

Beyond the code itself, AI models routinely suggest dependencies — npm packages, pip libraries, Go modules — without checking whether they're maintained, whether they have known CVEs, or, in some cases, whether they even exist.

The last point isn't hypothetical. Socket researchers documented "slopsquatting," where attackers can register package names hallucinated by AI coding tools and wait for developers to install them. That risk fits neatly into an ecosystem already proven vulnerable to package confusion and typosquatting. Real incidents include the malicious ctx package on PyPI, which stole environment variables from developers who intended to install the legitimate python3-ctx, and the colourama typosquatting campaign that targeted Python users. More recently, the legitimate ultralytics package was compromised in December 2024 to deliver a cryptominer, underscoring that even "real" packages suggested by AI still need verification.

What Secure Vibe Coding Looks Like

Always include security context in your prompt. "Add user authentication with parameterized queries, bcrypt password hashing, and CSRF protection" produces significantly safer code than "add user authentication." The models respond to specificity — use it.

Treat AI-generated code as untrusted input. The same way you'd review a PR from a new contractor, review AI-generated code with security in mind. Ask the model to explain its security choices; models will often self-correct when pressed.

Run SAST tools on every commit, regardless of origin. Tools like Semgrep, CodeQL, and Snyk Code work whether the code was human-written or AI-generated. If you weren't running them before because "we write secure code," that reasoning no longer applies in an AI-assisted workflow.

Verify dependencies before installing. Before running npm install or pip install on any package an AI suggested, check that it exists on the registry, has meaningful download counts, a credible maintainer history, and no obvious advisories in sources like GitHub Security Advisories, OSV, or Snyk.

Don't let AI generate cryptography or auth from scratch. These domains require precision that prompt-based generation cannot reliably provide. Use established libraries and services such as jose, Passport.js, Auth0, or framework-native auth stacks, and let AI help with the integration, not the implementation.

The Bottom Line

AI-assisted development is net positive for productivity. It's net neutral or negative for security unless teams actively compensate for its blindspots. The organizations that add security context to their prompts, maintain rigorous code review, and automate vulnerability scanning will capture the speed benefit. Those that don't are accumulating technical debt of a particularly exploitable kind.

Key Takeaways

  • Add explicit security requirements to prompts every time: ask for prepared statements, output encoding, secure session handling, and approved libraries instead of generic "build auth" or "write an API" requests.
  • Treat every AI-generated diff like untrusted third-party code: require human review, run Semgrep or CodeQL in CI, and block merges on high-confidence findings.
  • Never install AI-suggested packages blindly: verify the exact package name, maintainer, release history, and advisories before using npm install or pip install.
  • Keep AI away from greenfield crypto and authentication logic: use vetted components like Auth0, Passport.js, or jose, and limit the model to glue code and documentation.

References

← All posts