Two malicious axios versions — 0.30.4 and 1.14.1 — were published to npm with a crypto-stealing dependency injected. I had 12 repos using pnpm with axios somewhere in their dependency trees. I needed to know if they were affected, fast.
The Advisory
The compromised versions bundled plain-crypto-js, a package that exfiltrated private keys and wallet data. This wasn’t a typosquat or a dev dependency — it was injected into a legitimate, widely-used HTTP client.
The Process
For each repo, three checks:
1. Lock file inspection. The lock file is the truth — not package.json. Search for the exact compromised versions:
grep -n "axios@0.30.4\|axios@1.14.1\|plain-crypto-js" pnpm-lock.yaml
If it’s not in the lock file, the repo isn’t affected regardless of what’s in package.json.
2. Codebase grep. Check if plain-crypto-js appears anywhere — imports, bundled code, or injected scripts:
grep -r "plain-crypto-js" --include="*.js" --include="*.ts" --include="*.json" .
3. Audit command. Let the package manager’s built-in audit confirm:
pnpm audit --prod
The Results
12 repos scanned, zero affected. Every repo was on axios 1.7.x (the latest legitimate version at the time). No lock file had 0.30.4, 1.14.1, or plain-crypto-js anywhere in the dependency tree.
Why Lock Files Matter
A repo could have "axios": "^0.30.0" in package.json and still be safe — if the lock file pins to 0.30.3 (the last clean version). The caret range ^0.30.0 would resolve to 0.30.4 on a fresh install, but existing lock files don’t auto-upgrade.
This is exactly why you commit lock files and don’t run pnpm install without reviewing lock file changes.
Takeaway
When a supply chain advisory drops, scan the lock files first — not the source code, not the package.json. The lock file tells you exactly what’s installed. A 30-second grep across your lock files is faster and more reliable than running full dependency audits on every repo.