Yesterday, for roughly two hours, every npm install of the world's most popular HTTP client installed a Remote Access Trojan on your machine.
The axios package -- over 100 million weekly downloads, present in approximately 80% of cloud environments -- was compromised on March 30, 2026. A threat actor hijacked maintainer "jasonsaayman"'s npm account, published malicious versions axios@1.14.1 and axios@0.30.4, and within 2 seconds of npm install, before npm even finished resolving other dependencies, a cross-platform RAT was running on your machine. Windows, macOS, Linux. All of them.
If your AI coding assistant ran that install for you -- and thousands of developers let AI auto-run npm install every day -- you never even saw it happen.
This is the second major npm supply chain attack in March 2026. The first was the Trivy/CanisterWorm compromise on March 19, where 75 of 76 trivy-action GitHub Action tags were force-pushed to deploy self-spreading malware using blockchain-based command and control. Two attacks on critical infrastructure in eleven days. The trend line is not ambiguous.
Why Vibe Coders Are the Softest Target
Here is how a typical vibe coding session works:
- You prompt your AI: "Build me an HTTP client that fetches user data from the API"
- The AI generates code with
import axios from 'axios' - The AI (or you) runs
npm install axios - You test it. It works. You ship it.
At no point in this workflow does anyone:
- Check when the package version was published. axios@1.14.1 was published hours before the install. A human reviewing the npm page would have noticed the suspicious timing. An AI assistant does not check.
- Verify that the maintainer account has not changed hands. The attacker took over a real maintainer's account. The package name was legitimate. The version number looked normal.
-
Audit postinstall scripts. The malicious payload ran via a hidden dependency (
plain-crypto-js@4.2.1) that executed on install. AI assistants do not read postinstall scripts before running them. -
Pin exact versions. If your package.json says
"axios": "^1.14.0", npm happily installs 1.14.1 -- the compromised version. AI tools default to caret ranges. - Review lockfile diffs. The lockfile change would have shown a brand-new transitive dependency appearing out of nowhere. Nobody looks at lockfile diffs. AI certainly does not.
The AI assistant optimizes for one thing: does the code work? It does not optimize for is the dependency safe? And that gap -- between "it works" and "it is safe" -- is the blind spot this attack drove straight through.
We Already Had the Data
Two days before the axios attack, I published the results of auditing 5 vibe-coded web components against the OWASP Top 10. The findings:
49 vulnerabilities. 19 critical. Zero components would pass a security audit.
Every component worked as a demo. Every component was exploitable in production. The failure categories were consistent across all five:
| Category | Instances |
|---|---|
| Broken Access Control | 15 |
| Cryptographic Failures | 10 |
| Injection | 7 |
| Security Misconfiguration | 9 |
| Other (SSRF, path traversal, etc.) | 8 |
That audit focused on application-level vulnerabilities -- the code the AI generates. The axios attack reveals the other half of the problem: supply chain vulnerabilities in the dependencies the AI chooses.
When I cross-referenced the audit findings with the axios attack vector, the overlap was uncomfortable. Multiple items in the Vibe Coding Safety Checklist would have caught this specific attack:
-
Pin exact dependency versions (no
^or~) - Audit postinstall scripts before running them
- Review dependency diffs in lockfile changes
-
Use
npm ciinstead ofnpm install(fails on lockfile mismatch instead of silently updating) - Never let AI auto-run install commands without human review
The axios attack is the supply chain version of what we found in individual components. The pattern is the same: the AI optimizes for functionality and ignores security. The only difference is the attack surface -- your code versus your dependencies.
5 Things to Do Right Now
If you are vibe coding (and statistically, you probably are -- 84% of developers now use or plan to use AI coding tools), here are 5 changes to make today. Each one takes under 5 minutes.
1. Pin Your Dependency Versions
Stop using caret ranges. Right now, open your package.json and remove every ^ and ~.
// BEFORE: axios attack would auto-install
"axios": "^1.14.0"
// AFTER: only installs the exact version you vetted
"axios": "1.14.0"
Then run:
npm config set save-exact true
This makes all future npm install --save commands pin exact versions by default. Five seconds of setup, permanent protection against malicious patch releases.
2. Use npm ci Instead of npm install
npm install will happily resolve new versions that match your semver range. npm ci installs exactly what is in your lockfile and fails if there is any mismatch.
# In your CI/CD pipeline, replace:
npm install
# With:
npm ci
If the lockfile says axios@1.14.0 and someone pushes a change to axios@1.14.1, npm ci will fail loudly instead of silently installing the compromised version.
3. Disable Lifecycle Scripts in CI
The axios payload executed via a postinstall script. You can block this entirely:
# Run installs without executing any lifecycle scripts
npm ci --ignore-scripts
# Then explicitly run only the scripts you trust
npm run build
Add this to your .npmrc for permanent protection:
ignore-scripts=true
Yes, some legitimate packages use postinstall scripts (like sharp for image processing). You can allowlist those explicitly. But the default should be "do not run arbitrary code during install."
4. Implement a Version Cooldown
Do not install any package version published less than 72 hours ago. The axios malicious versions were live for approximately 2-3 hours before being yanked. A 72-hour cooldown catches most smash-and-grab supply chain attacks.
You can enforce this with Socket.dev (free for open source) or a simple CI check:
# Check publish date of a package version
npm view axios@1.14.1 time --json
If the publish timestamp is less than 72 hours old, block the install and flag for human review.
5. Stop Letting AI Auto-Run Install Commands
This is the most important one. When your AI coding assistant generates a dependency and runs npm install, insert yourself into the loop:
- Review what is being installed before it runs
- Check the dependency on npm -- when was it last published? By whom? Does it have new transitive dependencies?
- Diff the lockfile after install to see exactly what changed
The AI is your code generator, not your security reviewer. Treat every AI-suggested dependency the same way you would treat a dependency recommended by a stranger on the internet -- because that is effectively what it is.
The Pattern Is Accelerating
Two major npm supply chain attacks in eleven days. The Trivy/CanisterWorm attack on March 19 compromised a security scanner -- the very tool developers rely on to catch vulnerabilities. The axios attack on March 30 compromised an HTTP client that exists in the vast majority of JavaScript projects.
The attack surface is expanding at the same rate as AI-assisted development adoption. More developers are shipping faster with less review. Attackers have noticed.
This is not a call to stop using AI for coding. The productivity gains are real, and I use AI coding tools daily. But there is a difference between using AI as a tool and trusting it as a security reviewer. It is not one. It has never claimed to be one. And the axios attack is the clearest proof yet that treating npm install as a safe operation -- especially when an AI is the one running it -- is a gamble with escalating odds.
Get the Full Checklist
The 5 steps above are a starting point. They are extracted from the Vibe Coding Safety Cheat Sheet -- a free 10-point quick reference covering the most critical security checks for AI-generated code.
If you want the complete system -- all 32 checklist items, 10 security-enhanced prompt templates, before/after exploit examples, and CI/CD configs that automate these checks -- the full Vibe Coding Safety Checklist is available on Gumroad.
The axios attack will not be the last supply chain compromise. The question is whether the next one hits your project before or after you add these checks to your workflow.
Previously in this series: I Bought a $100 Product for One Cent Using Vibe-Coded Checkout -- Plus 4 More Exploits -- a step-by-step audit of 5 vibe-coded components revealing 49 security vulnerabilities.
Top comments (0)