15 Vulnerabilities in Your package.json. 2 Seconds to Find Them.

Date: March 3, 2026

Tool: npm audit (npm 10.x built-in)

Category: Supply Chain Security

Result: ✅ Pass — 8/8

Scan time: 2.1 seconds

Methodology note: We built a controlled Node.js project with 8 intentionally pinned-old vulnerable packages. Zero setup beyond a package.json — npm audit is already installed on every machine running Node. The results are real. The packages shown exist and the vulnerabilities are documented.

What We Tested

The target was a controlled Node.js project with a deliberately poisoned package.json. Eight packages, all pinned to old vulnerable versions. The kind of dependency tree that accumulates over years in any active codebase — especially where nobody owns "keep packages updated."

We ran: npm audit --json. No extra tools, no install, no configuration. npm audit ships with every Node.js installation since npm 6. It queries the GitHub Advisory Database in real time and returns a structured report.

Scan time: 2.1 seconds. Cost: nothing.

The 8 packages we planted — and what was wrong with them:

Package	Version	Vulnerability	Severity	Fix
`node-serialize`	0.0.4	RCE via IIFE deserialization	🔴 CRITICAL	No fix — abandoned
`minimist`	0.0.8	Prototype Pollution	🔴 CRITICAL	Update to ≥1.2.6
`lodash`	4.17.15	Command Injection	🟠 HIGH	Update to ≥4.17.21
`axios`	0.19.0	Server-Side Request Forgery (SSRF)	🟠 HIGH	Update to ≥1.6.0
`express`	4.16.0	XSS via response.redirect()	🟠 HIGH	Update to ≥4.19.2
`marked`	0.3.6	XSS from data URIs	🟠 HIGH	Update to ≥4.0.10
`js-yaml`	3.12.0	Denial of Service	🟠 HIGH	Update to ≥3.13.1
`serialize-javascript`	1.6.1	Cross-Site Scripting	🟠 HIGH	Update to ≥3.1.0

Detection rate: 8/8 planted packages (100%). Total vulnerabilities reported: 15 (2 critical, 10 high, 3 low — some packages have multiple CVEs). False positives: 0.

The Two Critical Findings

node-serialize: Remote Code Execution With No Fix

node-serialize version 0.0.4 contains a Remote Code Execution vulnerability that has been public since 2017. The mechanism is JavaScript's Immediately Invoked Function Expression (IIFE) syntax: if an application calls node-serialize.unserialize() with user-controlled input, an attacker can embed an IIFE that executes arbitrary code on the server.

The payload is compact:

{"cmd":"_$$ND_FUNC$$_function(){require('child_process').exec('id',function(error,stdout,stderr){console.log(stdout)});}()"}

Calling unserialize() on that string runs id on the server. Replace id with anything — a reverse shell, a data exfiltration script, a ransomware loader.

The brutal part: the package is abandoned. There is no patched version. The maintainer made no further commits after the vulnerability was disclosed. The only remediation is to completely remove the package from your dependency tree and replace it with a safe deserialisation library, or rearchitect the code path that needs serialisation entirely.

This is the class of supply-chain risk that's often harder to address than a simple version bump. "We can't update until the next sprint" doesn't work when the patch doesn't exist. You need to audit every code path that touches node-serialize.unserialize() and ensure no user-controlled data can reach it — immediately, not in the next sprint.

minimist: Prototype Pollution

minimist is the argument-parsing library that powers hundreds of thousands of Node.js CLI tools. Version 0.0.8 has a prototype pollution vulnerability: passing __proto__ as a key in the parsed arguments contaminates the base Object.prototype for the entire Node.js process.

In practice:

minimist(['--__proto__[admin]', 'true']) // Now every object in the process has .admin === 'true' // if (req.user.admin) { ... } just became true for every request

Authentication bypasses via prototype pollution are real. The CVE has been exploited in production. The fix — update to minimist ≥1.2.6 — is a one-line change in package.json. But it requires someone to actually run npm audit first.

The Supply Chain Problem npm audit Actually Solves

npm audit doesn't catch supply-chain injection attacks — it won't detect a malicious package that was deliberately backdoored before it hit the registry (that's a different tool category: Socket.dev, Snyk, Phylum). What it catches is arguably more common: known vulnerable versions of packages you chose to install, that have published CVEs, that nobody updated.

The XZ Utils backdoor (CVE-2024-3094) was widely covered. The event-stream compromise got front-page treatment. But the mundane version of this story — a project running lodash@4.17.15 with a command injection CVE for three years because nobody ran npm audit — affects far more organisations and causes real breaches with no press coverage.

Look at the packages in this demo. Lodash, axios, express, js-yaml — these are foundational Node.js dependencies. They're in millions of projects. The vulnerable versions are in production codebases right now, in companies that have never run npm audit at all.

SecurityClaw's supply-chain scanner runs npm audit automatically on every campaign. That means it surfaces dependency risk alongside network findings and web scanning results in a single unified report — not in a separate "run this tool sometimes" process that falls off the team's radar.

Run It Now — It Takes 2 Seconds

From the root of any Node.js project:

npm audit

For a machine-readable report:

npm audit --json | jq '.vulnerabilities | to_entries[] | select(.value.severity == "critical")'

To fix everything with an automatic update:

npm audit fix

Note: npm audit fix won't help with abandoned packages like node-serialize. Those require manual removal and replacement. But it will handle the 6 version-bump fixes immediately.

For teams building security into CI/CD pipelines, the setup is one line in your pipeline config:

# In GitHub Actions, GitLab CI, etc. npm audit --audit-level=high

This fails the build if any HIGH or CRITICAL vulnerability is detected. That's the correct default behaviour. You want to know before you deploy, not after.

For the deeper understanding of why these vulnerabilities exist and how attackers exploit them: The Web Application Hacker's Handbook covers prototype pollution, SSRF, and XSS in the depth that changes how you write code. Black Hat Python (2nd Edition) walks through building the exploitation tooling that turns these CVE descriptions into working attacks — understanding the attack makes the defence concrete.

What npm audit Doesn't Catch (Being Honest)

Scope matters. npm audit is useful precisely because it does one thing well. It doesn't cover:

Licence risk — It won't flag a GPL dependency in a commercial project. Use license-checker for that.
Typosquatting — A malicious package named loddash or expres won't appear in the advisory database. Socket.dev is the right tool there.
Supply-chain injection — If a maintainer's account was compromised and malicious code was injected into a new version, npm audit won't catch it until a CVE is published (which may take weeks).
Runtime behaviour — npm audit knows what a package's version is; it doesn't know how your code uses it. A vulnerable code path that's never reachable in production is still reported as a vulnerability.

These are gaps in npm audit specifically, not in the practice of dependency scanning. The honest answer is that supply-chain security needs multiple layers — npm audit is the fast, free, always-available baseline. It should be running on every build.

See the Full SecurityClaw Pipeline

Supply chain scanning is one layer. See how SecurityClaw combines secrets detection, web scanning, and dependency auditing into a single campaign view:

Learn about SecurityClaw →

SecurityClaw is in active development. The demos section documents real campaign results as the platform matures.