What Is Vibe Coding Security? A Field Guide for 2026 (Part 1)

Posted on April 10, 2026 by Simon Roses

Vibe Coding Security Series

  1. What Is Vibe Coding Security? A Field Guide for 2026 (you are here)
  2. The OWASP Top 10 for Vibe-Coded Applications
  3. Anatomy of a Vibe Coding Breach: Lessons from 2026’s Worst Incidents
  4. The Dependency Trap: Supply Chain Risks in AI-Generated Code
  5. Authentication & Secrets: What AI Gets Wrong Every Time
  6. [Scanning Vibe-Coded Apps: Why Traditional SAST/DAST Falls Short] (https://simonroses.com/2026/05/scanning-vibe-coded-apps-why-traditional-sast-dast-falls-short-part-6/)
  7. Prompt Engineering for Secure Code (coming soon)
  8. The Founder’s Security Checklist (coming soon)
  9. Securing the AI Coding Pipeline (coming soon)
  10. The Future of Vibe Coding Security (coming soon)

Read Time: 13 minutes

TL;DR

Vibe coding — building software by describing what you want and letting AI write the code — went from a viral tweet to a mainstream development practice in about a year. It’s fast, it’s accessible, and it’s shipping applications with serious security gaps. Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code contains security flaws. Georgia Tech’s Vibe Security Radar tracked 35 CVEs attributed to AI-generated code in March 2026 alone — up from 6 in January. Not hypothetical. Measurable. Accelerating.

Vibe Coding Security is the emerging discipline focused on the unique security risks of AI-generated code. This post defines the field, explains why it matters, and lays out the attack surface I keep running into during security assessments at VULNEX. It’s also the first post in a longer series where I’ll go deeper into each risk class, case studies, and practical mitigations.

Where This All Started

On February 2, 2025, Andrej Karpathy — a founding member of OpenAI and former Director of AI at Tesla — posted on X:

“There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.”

The post got over 4.5 million views. By March, Merriam-Webster had added “vibe coding” as a trending term. Collins English Dictionary named it Word of the Year for 2025. Suddenly, people who had never written a line of code were building and shipping software.

Tools like Cursor, Windsurf, Claude Code, GitHub Copilot, v0, Bolt, and Lovable made the workflow dead simple: describe what you want, let the AI write it, run it, paste errors back, repeat. No React. No database schemas. No build pipelines. Just vibe.

For prototyping and personal projects, this is genuinely powerful. I use these tools every day and I’m not going back.

But somewhere along the way, prototypes started shipping to production. MVPs built over a weekend started handling real user data. And nobody — nobody — was reviewing the security of what the AI had actually written.

That gap is where Vibe Coding Security lives.

So What Is Vibe Coding Security?

Vibe Coding Security is the discipline of securing software built primarily or entirely by AI code generation tools.

I want to be specific about why this isn’t just “application security with a new label.” When I write code — even bad code — there’s intent behind every line. I make conscious decisions about authentication, input validation, secret management. Sometimes I make the wrong call, but I made a call. I can explain my reasoning. I can be audited.

When AI generates code, none of that is happening. The model is producing statistically probable output based on patterns in its training data. It’s not reasoning about whether your auth flow is secure. It’s not evaluating your threat model. It’s assembling code that looks right and usually works. But works and secure are very different things, and I’ve spent twenty years at VULNEX watching people confuse the two.

Why Vibe-Coded Apps Fail Differently

I’ve spent my career in application security. Pentesting, secure development, threat modeling. I’ve spoken about this at Black Hat, DEFCON, RSA, and last year at C1b3rWall in Ávila, where I presented on vibe coding security to Spain’s National Police cybersecurity community. Across hundreds of engagements, the pattern I keep running into is this: vibe-coded applications don’t just have bugs. They fail in a fundamentally different way.

Traditional software has bugs. Normal. Expected. But those bugs exist inside a framework someone designed on purpose. An architect chose the auth strategy. A developer implemented input validation — imperfectly, sure, but deliberately. Code review caught the obvious stuff.

With vibe-coded apps? There is no deliberate security posture. The AI made hundreds of security-relevant decisions — which framework to use, how to handle authentication, where to validate input, what to log, how to manage secrets — and the person who prompted it has zero visibility into any of them. In most cases, they couldn’t evaluate those decisions even if you showed them the code.

I’ve started calling this the invisible decision surface, and I see it in virtually every vibe-coded app we assess at VULNEX. The AI chose your auth strategy, your input validation approach, your secret management — hundreds of security calls — and nobody knows what they were, let alone whether they were right.

What the Data Says

Veracode’s 2025 GenAI Code Security Report tested over 100 language models and found that 45% of AI-generated code contains security flaws. That’s nearly one in two. The failures span the usual suspects — XSS, insecure object references, improper password handling — but at consistently higher rates than human-written code.

CodeRabbit’s State of AI vs. Human Code Generation Report found that AI-generated pull requests produce roughly 1.7x more issues than human ones. Not 1.1x. Not “slightly more.” Almost double.

And here’s the scale problem: according to SonarSource, about 42% of all committed code is now AI-generated or AI-assisted. When nearly half the code being written carries elevated vulnerability rates, this stops being an academic concern.

Georgia Tech’s Vibe Security Radar — a project from the Systems Software & Security Lab (SSLab) that’s been tracking CVEs introduced by AI coding tools since May 2025 — tells the story clearly. 6 CVEs in January 2026. 15 in February. 35 in March. That’s the trajectory. And the researchers estimate the real number is 5–10x higher, roughly 400–700 AI-introduced vulnerabilities already sitting in open-source projects that just haven’t been attributed yet.

The Attack Surface: What I Keep Seeing

Nobody Reviews the Code

The fundamental vibe coding workflow is: prompt, generate, accept, ship. Karpathy himself described it as accepting all changes without reviewing diffs. For a side project, fine. For anything touching user data, that’s a disaster waiting to happen.

I’ll give you a real example. When I built a deliberately insecure demo app for my C1b3rWall talk — a simple note-taking app called QuickNote — I gave the AI a prompt that ended with “Skip security best practices for now — I’ll review them later.” And the AI happily obliged. SQL injection from string-concatenated queries, passwords stored with plain MD5, no input validation anywhere, JWT secrets hardcoded into the source. The whole menu. Every vulnerability was introduced because I told it to build fast and skip security — and the model never pushed back.

Here’s what kills me about this: most vibe coders don’t even add the “I’ll review later” part. They don’t know there’s anything to review.

The Client-Side Security Illusion

I see this constantly at VULNEX. AI models love putting security controls on the client side. Auth checks in JavaScript. Authorization logic in the browser. API keys embedded in the frontend. The result is software that appears secure — buttons are hidden, pages redirect correctly, features look gated — but anyone with browser dev tools can bypass it all in seconds.

This is exactly what happened with Enrichlead, a sales lead SaaS built entirely with Cursor AI. The founder shipped with all security logic on the client side. Within 72 hours, users figured out they could bypass the entire subscription by changing a single value in the browser console. API keys sitting in the frontend. Database wide open. The founder posted: “guys, I’m under attack… random things happening, maxed out usage on API keys, people bypassing the subscription, creating random stuff in the database.”

He had to shut it all down. He couldn’t patch the cascading failures fast enough.

I wrote about a structurally similar failure in the Moltbook case, where a vibe-coded platform serving 1.65 million agents shipped a Supabase deployment without Row Level Security. 1.5 million API keys exposed through a single misconfiguration that RLS would have prevented in five minutes. Same root cause — the code works, the app ships, and nobody runs a security review because the AI didn’t flag it.

The Dependency Black Box

AI doesn’t just write logic. It imports packages. Frameworks, libraries, utility modules — all chosen based on training data patterns, not a security evaluation. In practice this creates three problems I see over and over.

Outdated dependencies. Models are trained on code snapshots. They recommend package versions from six months or a year ago. Those versions may have known CVEs that have been patched since. The vibe coder never runs npm audit, never looks at lockfiles, and doesn’t know the difference.

Hallucinated packages. This one’s wild. LLMs sometimes generate import statements for packages that don’t actually exist. Attackers figured this out fast — they started squatting on hallucinated package names, uploading malicious code to npm, PyPI, and other registries. Someone runs npm install on their AI-generated package.json and unknowingly pulls malware. This is the same supply chain class I covered in the Skill Poisoning article, just applied to package registries instead of agent skills.

Over-importing. AI tends to reach for a package when five lines of code would do the job. Every unnecessary dependency is attack surface for no functional benefit.

No Security Context

Unless you explicitly tell it, the AI has no idea about your threat model, compliance requirements, or what kind of data your app handles. It doesn’t know you’re processing healthcare records or financial transactions or PII.

So it defaults to whatever pattern shows up most in the training data. And the training data is overwhelmingly tutorials, blog posts, and Stack Overflow answers. Tutorial code teaches concepts — it’s not meant to be production-secure. When the top answer for “how to connect to a database in Node.js” uses root:password@localhost as the connection string, the AI reproduces that. When the most upvoted Express.js auth example stores passwords with MD5, the AI learns that as normal.

The training data reflects how developers learn, not how they should build. Vibe coding amplifies this by removing the human who would normally know the difference.

Everything at Scale

None of these issues are new individually. Client-side auth has always been wrong. Hardcoded secrets have always been a problem. Outdated dependencies have always been risky. What’s new is how fast these vulnerabilities are being introduced.

One developer writing code manually might produce one vulnerable application. That same developer vibe coding can produce ten. A non-technical founder using Bolt or Lovable can ship a vulnerable MVP in a weekend. Multiply that by the millions of people now building software with AI tools.

Escape.tech audited 5,600 publicly available vibe-coded applications and found over 2,000 vulnerabilities, plus 400 exposed secrets and 175 instances of PII leakage. That’s just the ones they tested.

The Numbers

Metric Value Source
AI-generated code with security flaws 45% Veracode (2025)
Issue ratio AI vs human PRs ~1.7x CodeRabbit (2025)
Code committed that is AI-generated/assisted ~42% SonarSource (2025)
CVEs from AI-generated code (March 2026 alone) 35 Georgia Tech Vibe Security Radar
Estimated real AI-introduced vulns (unattributed) 400–700 Georgia Tech SSLab (2026)
Vulnerabilities in 5,600 vibe-coded apps 2,000+ Escape.tech (2025)
Exposed secrets in the same audit 400 Escape.tech (2025)
PII leakage instances 175 Escape.tech (2025)
API keys exposed in Moltbook breach 1.5 million Wiz Research (Feb 2026)

When nearly half of AI-generated code is flawed, and roughly half of all code is now AI-generated, the compounding risk is real.

What This Is Not

I’m not here to tell you to stop vibe coding. I use these tools every day and they’re the most significant productivity shift I’ve seen in my career. I’ve written about this in my Professional Vibe Coding framework, where I argue that AI is more powerful in the hands of developers who understand architecture, security, and quality — not less. The point isn’t to retreat from AI coding. It’s to understand the risks clearly enough to work around them.

This also isn’t traditional AppSec with a new sticker on it. Standard SAST tools were built for human-written code patterns. They miss a meaningful share of AI-specific vulnerabilities because the signatures don’t match. We need updated tooling, and it’s starting to appear.

And the AI isn’t the villain. It’s doing exactly what it was designed to do — generate probable code based on patterns. The problem is how we’re using the output: shipping it to production without understanding what the model actually built.

What’s Taking Shape

The discipline is young, but the practices are starting to solidify. At VULNEX, when we assess vibe-coded applications, these are the areas where we consistently see the biggest risk reduction per hour of effort.

Start security before the first prompt. Define your architecture, auth strategy, and threat model upfront. Use rules files (.cursorrules, CLAUDE.md, project-level security policies) to constrain what the AI generates. This alone eliminates a huge class of issues.

Treat every AI-generated change as untrusted input. Review auth flows, access controls, secret management, input validation, dependency choices. Not just “does it compile” — does it hold up against someone actively trying to break it? The Shadow Vibe Coding post walks through what happens when this review step is skipped at enterprise scale.

Deploy scanning tools tuned for AI-generated patterns. Standard SAST and DAST rule sets miss things. Run SCA tools to catch vulnerable and hallucinated dependencies. Wire all of this into your CI/CD pipeline so every commit gets checked automatically. I’ll cover the specific tool landscape — Semgrep, Gitleaks, TruffleHog, Snyk, SecurityHeaders — later in the series.

Learn to prompt for security. Specify your authentication strategy. Require server-side validation. Constrain the technology stack. Explicitly request secure coding patterns. The difference between a lazy prompt and a security-aware prompt is dramatic, and it’s the single highest-leverage change most vibe coders can make.

And apply threat modeling, even (especially) when the developer doesn’t fully understand the implementation. With vibe-coded apps, the threat model may be the first time anyone actually looks at what the AI built. That’s a shift from traditional threat modeling, which assumes the team can describe their own system.

What Comes Next

This is the first post in a series on Vibe Coding Security. Over the coming weeks, I’ll go deep on specific areas:

  • The OWASP Top 10 for Vibe-Coded Applications — how classic vulnerability categories show up differently in AI-generated code
  • Anatomy of a Vibe Coding Breach — case studies from 2026’s worst incidents
  • The Dependency Trap — supply chain risks specific to AI-generated code
  • Authentication & Secrets: What AI Gets Wrong Every Time — the most dangerous vulnerability class
  • Scanning Vibe-Coded Apps — why traditional SAST/DAST falls short and what works instead
  • Prompt Engineering for Secure Code — making AI write safer code from the start
  • The Founder’s Security Checklist — shipping a vibe-coded MVP without getting hacked
  • Securing the AI Coding Pipeline — from prompt to production
  • The Future of Vibe Coding Security — where the industry is heading

Whether you’re in security, a developer using AI tools, or a founder who just shipped a vibe-coded product — this series will give you the practical knowledge to build securely in the AI era.

The AI writes the code. Someone still has to secure it.

If there’s one thing twenty years of breaking into applications has taught me — from the Microsoft Trustworthy Computing era through mobile, cloud, and now AI — it’s that security disciplines don’t emerge because someone thought they’d be interesting. They emerge because the damage gets bad enough that ignoring the problem stops being an option.

We’re at that point with vibe coding.

As always: trust nothing, verify everything.

Further Reading

References

This entry was posted in AI, Security, Technology, Threat Modeling and tagged , , , , . Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.