The axios source code was fine. That's the detail that made me read the writeups twice. Someone hijacked a maintain...
The axios source code was fine. That's the detail that made me read the writeups twice. Someone hijacked a maintainer's npm account and pushed 1.14.1 and 0.30.4, not by modifying axios itself, but by injecting a fake dependency called plain-crypto-js into the package manifest. That package runs a postinstall hook. Silent. No prompt. setup.js executes on install, phones home to sfrclak[.]com, and drops a RAT. Three separate platform-specific payloads: PowerShell on Windows, Python on Linux, a compiled C++ binary on macOS. Someone built this deliberately, for multiple targets. Not opportunistic.
Attribution is Sapphire Sleet, also known as BlueNoroff, a North Korean state-sponsored group. I'll be honest that I don't fully understand their specific target profile for this operation and I'm not going to speculate past what's been reported. What I do know is that "state actor targeting developer infrastructure" is a meaningfully different category than a random package squatter, and it changes how you think about the intent behind the credential harvesting.
The spread vector was nothing exotic. Just ^. Most package.json files auto-resolve to the latest compatible version, CI/CD pipelines included. Nobody made a bad decision. Tuesday morning, routine install, done.
If You Have Axios in a Project, Do These Things
Downgrade and pin. Lock your package.json to "axios": "1.14.0" with no caret. Add an overrides block in case it's arriving transitively through something else:
"overrides": { "axios": "1.14.0" }
I only remembered the overrides move because we got burned by a transitive dep pulling in a bad version on a completely different package last year. Not this one, but same principle.
For CI, run npm ci --ignore-scripts. This should have been standard already. It wasn't for us everywhere, which is embarrassing to say out loud but also true and probably worth saying.
On credential rotation, this is where I don't have a clean answer. "Rotate everything accessible from any environment where a compromised install ran" is technically correct advice. It's also the kind of advice that sends someone into their infrastructure at 11pm, rushing, and breaks three things in the process. What's actually at risk depends entirely on what was accessible from the environment where the install happened: cloud keys, npm tokens, SSH keys, CI secrets. I can't triage that for you. If the install ran somewhere that had meaningful access, you probably already know which credentials matter.
Artifact paths if you want to check directly: %PROGRAMDATA%\wt.exe on Windows, /tmp/ld.py on Linux, /Library/Caches/com.apple.act.mond on macOS.
The Part I Haven't Fully Worked Out Yet
The thing I'm still working through is the popularity heuristic. Axios has 70-something million weekly downloads. If that's not a safety signal, what is? Probably nothing on its own that's the uncomfortable answer. Obscure packages are still riskier in different ways, so the heuristic doesn't fully collapse. But it clearly can't carry the weight we've been putting on it.
I'm writing this partially to figure out what I actually think, not just to relay what happened. If you're building on Node.js and want a second set of eyes on your dependency security posture, CI/CD configuration, or npm practices, ATX Software works with teams on exactly this kind of infrastructure hygiene. No pitch, just practical engineering work.
References
- Microsoft Security Blog, April 1, 2026. Mitigating the Axios npm supply chain compromise
