Is Vibe Coding Safe? Security Risks of AI-Generated Code Every Team Must Know

When a developer asks an AI model to add authentication to a Node.js application, the model reaches for whatever package was most prevalent in its training data. That might be a library that was widely used two years ago and has since accumulated unpatched CVEs, been abandoned by its maintainer, or been quietly compromised in a supply chain attack.

The practical failure mode: a vibe-coded Express application pulls in a JWT library pinned to a version with a known algorithm confusion vulnerability, or uses a Mongoose plugin that has not had a security patch in 18 months. The code runs fine in development. It passes functional tests. It ships to production. The dependency audit never ran.

The second and more dangerous failure mode is package hallucination. AI models occasionally generate import statements for packages that do not exist, or that exist only as names the model constructed from patterns in its training data. Attackers monitor for hallucinated package names and publish malicious packages under those names, waiting for developers to run npm install and pull the payload into their build pipeline. Security researchers have demonstrated this technique against multiple AI coding tools.

What this looks like during a codebase audit: check the package-lock.json or yarn.lock for packages with no npm homepage, no GitHub repository, or zero weekly downloads. Cross-reference every dependency that handles cryptography, authentication, or network requests against the GitHub Security Advisory Database before accepting a vibe-coded PR.

This is the most consistent finding in vibe-coded codebases. AI models generate example code with placeholder values that look like real credentials. Developers accept the generated code, wire it up to their actual secrets by editing the string in place rather than moving the value to an environment variable, and commit the file.

The pattern appears in dozens of forms: a database configuration file ships with a connection string containing the actual production password; a generated authentication module includes a JWT_SECRET hardcoded as a 32-character random-looking string the developer never replaced; an AWS SDK integration has access keys embedded directly in the source file.

These secrets end up in version control. Once they are in git history, rotating the value in the current file is insufficient. The credential exists permanently in every commit that contains it, accessible to anyone with repository access and to automated secret scanners that index public repositories within minutes of a push.

The mitigation is non-negotiable: GitLeaks or TruffleHog must run as a pre-commit hook and as a CI gate. Run TruffleHog against the full git history of any vibe-coded repository on first audit: not just the current HEAD. The history is where the credential you rotated three weeks ago still lives.

AI models generate happy-path code. When you ask a model to build a user profile endpoint, it generates the code that handles the case where the user sends a valid request. It does not generate the code that handles the case where the user sends a crafted SQL fragment in the username field, a JavaScript payload in the bio field, or an internal IP address in the avatar URL field.

This is not a model failure. It is a framing problem. The developer described what the feature should do for a legitimate user. The model generated exactly that. Adversarial inputs were never part of the specification.

The vulnerability patterns that result are predictable from OWASP Top 10. SQL injection appears in database queries that concatenate user input directly into query strings instead of using parameterized queries. Cross-site scripting appears in template rendering that outputs user-supplied content without encoding. Server-side request forgery appears in features that fetch URLs provided by users, where the generated code does not validate that the target is an external host before making the request.

SSRF is particularly common in vibe-coded applications because the feature description sounds benign: "fetch the metadata for this URL the user provided." The model generates functional code that makes the request. It does not add validation that prevents the user from pointing that request at the EC2 metadata endpoint at 169.254.169.254.

Authentication code generated by AI models tends to be functionally correct and security-incomplete. The login flow works. Passwords get hashed. Sessions get created. But the implementation skips the defenses that protect users when something goes wrong.

CSRF protection is the most common omission. A vibe-coded form submission handler will process the request but will not validate a CSRF token unless the developer specifically asked for CSRF protection, which most do not.

JWT implementation errors are the second most common pattern. AI models generate JWT verification code that calls the verify function with the correct library. They frequently fail to pin the allowed algorithm, leaving the implementation open to algorithm confusion attacks where an attacker downgrades from RS256 to HS256 and forges tokens using the public key as the HMAC secret. The code looks correct on inspection. The vulnerability is in what is absent, not what is present.

The audit approach for auth flows is manual review with a checklist, not automated scanning. SAST tools catch some patterns but miss structural gaps. Confirm that every state-changing endpoint validates a CSRF token, that JWT verification pins the algorithm explicitly, and that sessions regenerate on login and logout.

This risk category is specific to vibe-coded applications that themselves use an LLM. When a developer asks an AI model to build a feature that takes user input and passes it to another AI model, the generated code almost never sanitizes or structurally separates the user input from the system instructions before making the API call.

The vulnerability is straightforward. The application concatenates a system prompt with user-supplied text and sends the combined string to the model. A user who understands this architecture can craft input that overrides the system instructions, extracts confidential prompt content, or causes the model to perform actions outside its intended scope. In applications with tool-calling enabled, this can mean the model executes file operations, API calls, or database queries that the attacker specified through the injected input.

The mitigation requires structural separation of trusted and untrusted content. User input should be passed in a separate message role, not concatenated into the system prompt. Applications with tool-calling should apply strict allowlists to what tools can be triggered and what parameters they accept. Output from the model should be treated as untrusted if it will be rendered to other users or used to trigger downstream operations.

This is a new attack surface that most security teams are not yet scanning for systematically, which makes it a high-value target for attackers in vibe-coded applications.

The packages an AI model recommends are constrained by its training data cutoff. A model trained through late 2024 recommends packages that were active and maintained as of that date. It has no visibility into what happened to those packages after training ended.

A package that was safe when the model learned about it may have been compromised since. Maintainer account takeovers in the npm ecosystem result in malicious versions being published under trusted package names. A model that confidently recommends a package because it appeared in thousands of training examples cannot warn you that the maintainer's account was phished three months ago and version 2.4.1 contains a credential harvester.

Vibe-coded applications tend to accumulate dependencies faster than hand-written code because the friction of adding a dependency is lower when the model is doing the selection. A hand-written codebase might have 40 direct dependencies with 300 transitive. A vibe-coded codebase of similar functionality might have 80 direct with 600 transitive, because the model reached for a specialized package to handle each subproblem rather than using a standard library primitive.

The gate for this risk is non-negotiable: npm audit or its equivalent must run in CI and block merges on high-severity findings. Snyk adds reachability analysis that identifies which vulnerabilities are actually exploitable given the application's code paths.

The controls that catch vibe coding vulnerabilities are not new. What is new is the urgency of enforcing them consistently when AI-generated code can produce an entire feature's worth of vulnerable surface in minutes rather than days.

SAST scanning before merge is the baseline. Semgrep, CodeQL, and Bandit (for Python) catch the most mechanical vulnerability patterns: SQL injection via string concatenation, hardcoded credential strings, known-insecure function calls. These tools will not catch every vibe coding vulnerability, but they catch the ones that appear most reliably.

Secret scanning must run as a pre-commit hook, not just in CI. By the time a secret reaches the CI pipeline, it has already been committed to local history. GitLeaks with a pre-commit hook stops secrets before they enter version control. TruffleHog against the full git history catches anything that made it through.

Dependency auditing with npm audit and Snyk should block on high-severity CVEs. This catches the outdated package problem and some compromised package scenarios. Manual review of authentication flows and data validation is not optional and cannot be replaced by automated tooling. DAST on staging, using OWASP ZAP or Burp Suite, provides the adversarial perspective that static analysis cannot.

None of these controls are exotic. All of them exist in mature DevSecOps pipelines. The change vibe coding requires is treating them as mandatory rather than aspirational.