Your AI assistant won't tell you about that CVE in your dependencies

I watched a developer paste a generated package.json into a fresh project last week. The AI assistant had suggested Express 4.16.0. That version has a known path traversal CVE. The developer didn't check. The assistant didn't mention it. The project shipped to staging before anyone noticed.

This is not a rare edge case. It is the default outcome when you treat an AI coding assistant as an oracle for setup tasks. These tools are trained on patterns from millions of repositories, many of which contain old, unpatched dependencies. The assistant will happily reproduce those patterns because they look correct. And they are correct, syntactically. They are just not safe.

Why ai assistants miss known cves

Dependency selection is a security decision disguised as a syntax decision. When you ask for "a quick Node.js server with JWT auth," the model predicts plausible package names and versions. It does not query the National Vulnerability Database. It does not check the release date against the last security advisory. It does not know that the version it just wrote was deprecated six months ago.

Some assistants now have plugins or retrieval steps that can check current versions. Most do not, or the check is optional and easy to skip. The model's confidence is not calibrated to security. You get a fluent, working-looking snippet that carries a hidden liability.

I think this is the most underrated risk in the AI coding boom. Everyone talks about prompt injection or model hallucinations. Nobody talks about the assistant quietly installing a library with a remote code execution bug from 2019.

The pattern that keeps showing up

You ask for a feature. The assistant returns code and a dependency block. The version numbers are frozen at whatever was common in the training data. You run npm install or pip install. The resolver picks that exact version because you pinned it. You never see the advisory that says "upgrade to 4.17.1 or later."

Here is a simplified example of what that looks like in practice:

{
  "dependencies": {
    "express": "4.16.0",
    "lodash": "4.17.15",
    "axios": "0.18.0"
  }
}

All three of those versions have known CVEs. Express 4.16.0 has CVE-2022-24999 (qs prototype pollution). Lodash 4.17.15 has CVE-2020-8203 (prototype pollution via zipObjectDeep). Axios 0.18.0 has CVE-2019-10742 (SSRF). None of these are exotic. They are in every advisory database.

Now look at what the assistant should have produced, or what you should produce after running a scan:

{
  "dependencies": {
    "express": "^4.19.2",
    "lodash": "^4.17.21",
    "axios": "^1.7.4"
  }
}

The fix is not clever. It is boring. Update the versions. Or better, do not let the assistant pin exact versions at all. Use a range that your package manager can resolve to the latest patched release. Then run npm audit or pip-audit or cargo audit before you commit.

What you should actually do

First, stop trusting version numbers from AI output. Treat them as placeholders. Open the package's advisory page. Check the latest release. Pin to a version that has no open high-severity CVEs.

Second, add a dependency scanning step to your workflow. It can be a pre-commit hook, a CI job, or a manual command you run once a week. The tool does not matter. The habit does. If you use GitHub, Dependabot is free and takes five minutes to configure. If you use GitLab, there is a similar feature. If you want something local, npm audit --production or pip-audit work fine.

Third, when you ask an AI assistant for a new dependency, ask it explicitly: "What is the latest stable version of this package, and are there any known CVEs in older versions?" Some models will still get it wrong, but the question forces you to verify. I have started doing this for every new library. It adds maybe thirty seconds. It has caught two vulnerable suggestions in the past month.

Fourth, do not let the assistant generate your lockfile. Let your package manager do that after you have chosen safe version ranges. The lockfile is a security artifact. Treat it like one.

The uncomfortable truth

AI coding assistants are excellent at boilerplate. They are terrible at supply chain security. They have no incentive to warn you about a CVE because the CVE is not part of the pattern they were trained to complete. The assistant sees express and predicts a version. It does not see a vulnerability.

You are the human in the loop. That means you own the dependency hygiene. The assistant writes code faster than you can review it, which makes the review step more important, not less. If you skip it, you are not moving fast. You are accumulating risk that will surface later, usually at the worst possible time.

I am not saying stop using AI assistants. I use them every day. I am saying stop treating their output as final. A generated package.json is a draft. Run the scanner. Update the versions. Then ship.

For teams that want a second set of eyes on dependency risk without adding a full security toolchain, Seaworthy provides automated scanning that flags known CVEs in project dependencies.