The CVE You Never Read: Why AI Code Assistants Keep Shipping Known Vulnerabilities
By Seaworthy · 16 September 2026
Photo by Markus Spiske on Unsplash
I get it. You ask an AI assistant for a quick script to parse some JSON, and it spits out a package.json with [email protected]. That version has a known prototype pollution CVE. You run npm install, push to production, and move on. No one notices until a scanner flags it six months later. By then, you've forgotten the dependency even exists.
This is not a hypothetical. I've seen it in real repos. The code works. The tests pass. The security team is the only one who cares, and they're always the bad guys until something breaks.
Why AI assistants make this worse
AI models are trained on public code. Most public code is old. A model that learned from GitHub in 2023 will happily recommend [email protected] because that's what thousands of tutorials used. The model doesn't know that version has a CVE for server-side request forgery. It just knows the pattern.
You, the developer, are in a hurry. You paste the suggestion, run the install, and see no errors. The assistant never says, "Hey, this version is three years old and has a known vulnerability." It doesn't check CVE databases. It doesn't run npm audit. It just generates.
That's the core problem: AI assistants optimize for plausible code, not secure code. And dependency hygiene is boring, so you skip it.
What a known CVE actually means
A CVE is a public record of a security flaw. When a dependency has a known CVE, an attacker can look it up and craft an exploit. You don't need to be a target. Automated scanners crawl the web for vulnerable versions. If your app uses [email protected], you're on a list.
The fix is not always "upgrade immediately." Sometimes the upgrade breaks your code. Sometimes the vulnerability only affects a feature you don't use. But you can't make that call if you don't know the CVE exists.
The pattern that keeps showing up
Here's a typical scenario. You ask an AI for a Node.js API with JWT auth. It gives you this:
{
"dependencies": {
"express": "^4.17.1",
"jsonwebtoken": "^8.5.1",
"lodash": "^4.17.20"
}
}
All three have known CVEs as of this writing. [email protected] has a verification bypass. [email protected] has a command injection via template. [email protected] has an open redirect. The AI didn't mention any of this. It just gave you working code.
Now you run npm install and you're vulnerable. You won't see it in your editor. You won't see it in your tests. You'll see it when a penetration tester finds it, or when someone exploits it.
How to fix it without losing your mind
You don't need to become a security engineer. You need to add one step to your workflow: after the AI generates dependencies, run an audit.
For npm:
npm audit
For Python:
pip-audit
For Go:
govulncheck ./...
These tools compare your lockfile against CVE databases. They tell you exactly which package and version is vulnerable, and often suggest a safe upgrade.
The second step is to pin versions explicitly. AI assistants love caret ranges (^1.2.3) because they allow minor updates. But that also means you might install a version with a new CVE tomorrow. Pinning to an exact version (1.2.3) gives you control. You decide when to upgrade, not npm.
Third, use a lockfile. package-lock.json, poetry.lock, go.sum. Commit it. The lockfile records the exact tree of dependencies. Without it, a fresh install can pull different versions than what you tested.
Fourth, set up automated scanning in CI. GitHub's Dependabot, Snyk, or a simple npm audit --audit-level=high in your pipeline. This catches new CVEs in existing dependencies. You don't have to remember to check.
My reaction: this is a tooling failure, not a skill failure
I don't blame developers for skipping dependency checks. The tools we use every day don't force the issue. AI assistants are eager to please. They generate code that runs. They don't generate code that is secure by default.
That's a design flaw. A responsible assistant would say, "I'm suggesting [email protected], but that version has a known CVE. Here's a safe alternative." None of them do that today. So you have to be the safety net.
The good news is that it takes five minutes to add an audit step. Five minutes now saves you a breach later. And if you're using an AI assistant, you can even ask it to generate the audit command for your stack. Just don't trust its dependency suggestions without checking.
A final note
You can automate this. Seaworthy is a tool that scans your project dependencies for known CVEs and provides fix suggestions. It is not a replacement for good hygiene, but it makes the check part of your normal workflow. No pitch, just a fact.
This article was generated by AI and summarises publicly available sources.
Seaworthy scans your repo for the issues covered in articles like this one.
Security gaps, exposed secrets, and misconfigurations — caught before you deploy. Free to run, no account needed.