DEV Community

Cover image for Why Cursor Keeps Installing Vulnerable npm Packages
Charles Kern
Charles Kern

Posted on

Why Cursor Keeps Installing Vulnerable npm Packages

#security #webdev #ai #devsecops

TL;DR

  • AI editors pin package versions frozen at their training cutoff, so the "latest" they install is often months or years out of date and ships with known CVEs.
  • I keep finding lodash 4.17.11 and PyYAML 3.13 in fresh AI-generated projects. Both have public advisories for prototype pollution and remote code execution.
  • Audit dependencies at the moment code is generated, not a week later in CI.

Last week I asked Cursor to scaffold a small Node service. It wrote clean code, set up the routes, and dropped in a package.json. I almost shipped it. Then I ran an audit out of habit and found lodash pinned at 4.17.11.

That version has a public prototype pollution advisory, CVE-2019-10744. It was patched in 4.17.12, which shipped back in July 2019. The AI handed me a dependency that had been fixable for years.

This is not a one-off. I have seen the same pattern across enough AI-generated projects that I now treat every fresh package.json and requirements.txt as guilty until audited.

The vulnerable code

Here is the dependency the AI gave me:

// package.json generated by the AI
{
  "dependencies": {
    "lodash": "4.17.11"
  }
}
Enter fullscreen mode Exit fullscreen mode

lodash 4.17.11 is vulnerable to prototype pollution via defaultsDeep (CWE-1321, CVE-2019-10744). A crafted {constructor: {prototype: {...}}} payload can modify Object.prototype and quietly affect every object in your runtime.

Python is no safer:

# requirements.txt generated by the AI
PyYAML==3.13
Enter fullscreen mode Exit fullscreen mode

PyYAML before 5.4 allows arbitrary code execution through full_load and FullLoader (CVE-2020-14343). If any YAML you parse comes from a user, that is a remote code execution bug sitting in your install list.

Why this keeps happening

The model has a training cutoff. When it writes a dependency list, it reaches for the version that was current inside its training window. That version felt safe at the time. It is not safe now.

The AI has no live view of the npm or PyPI advisory database. It cannot know that 4.17.11 was superseded, or that a CVE landed after its cutoff. It is confidently recommending a snapshot of the past.

It gets worse with transitive dependencies. The package you pin pulls in its own tree, and those sub-dependencies are equally frozen. One outdated top-level package can drag in a dozen vulnerable ones you never typed out.

The fix

Audit at the moment the code is generated, not a week later in CI.

For npm:

npm audit
npm audit fix
Enter fullscreen mode Exit fullscreen mode

For the lodash case, bump it to the patched line:

npm install lodash@4.17.21
Enter fullscreen mode Exit fullscreen mode

For Python:

pip install pip-audit
pip-audit -r requirements.txt
Enter fullscreen mode Exit fullscreen mode

Then pin the patched version:

PyYAML>=5.4
Enter fullscreen mode Exit fullscreen mode

The general rule: never trust a version number an AI gave you. Cross-check it against the advisory database before it reaches your lockfile. A lockfile is good, but a lockfile full of vulnerable versions just makes the vulnerability reproducible.

I've been running SafeWeave for this. It hooks into Cursor and Claude Code as an MCP server and runs a dependency audit across npm, pip, cargo, go, and bundler the moment code is generated, so the outdated package never reaches my lockfile. That said, even a plain npm audit and pip-audit in a pre-commit hook will catch most of what is in this post. The important thing is checking versions early, whatever tool you use.

Top comments (0)