A supply chain attack quietly installed a remote access trojan on developer machines worldwide. We found it in our stack within hours — here’s our full response, and what you need to do right now.
axios@1.14.1 and axios@0.30.4 were published via a hijacked maintainer account on npm
They silently install plain-crypto-js@4.2.1, a RAT dropper that exfiltrates your secrets
The malicious versions were live for roughly 2 hours on March 31, 2026 UTC
Downgrade to axios@1.14.0 or axios@0.30.3 immediately and rotate all credentials
We audited every project in our company, notified clients, and triggered full credential rotation
What actually happened
On March 31, 2026, attackers published two poisoned versions of axios — one of the most downloaded npm packages on the planet, with over 100 million weekly installs — to the npm registry.
This wasn’t a typosquat or a rogue fork. The attacker hijacked the npm account of one of the primary axios maintainer. They changed the registered email to an anonymous ProtonMail address and manually pushed the malicious releases via the npm CLI — completely bypassing the project’s normal GitHub Actions CI/CD pipeline. There are no corresponding GitHub tags. No SLSA provenance attestations. No source code changes. The only modification in the entire package was a single new line in package.json: a dependency on plain-crypto-js@4.2.1.
What makes this attack nasty
No axios source code was touched. Traditional diff-based code review wouldn’t catch it. The attack was invisible unless you were checking for new, unexpected dependencies.
The attack timeline
March 30, 2026 — 05:57 UTC
Attacker publishes plain-crypto-js@4.2.0, a clean copy of the legitimate crypto-js library. Zero malicious code. Purpose: build a publishing history to fool automated scanners.
March 30, 2026 — 23:59 UTC
Malicious plain-crypto-js@4.2.1 published. Contains the obfuscated RAT dropper in setup.js. Socket’s automated detection flags it within 6 minutes.
March 31, 2026 — 00:21 UTC
axios@1.14.1 published via compromised maintainer account. Injects plain-crypto-js@4.2.1 as a runtime dependency.
March 31, 2026 — 01:00 UTC
axios@0.30.4 published. Both 1.x and 0.x branches poisoned within 39 minutes of each other — maximizing blast radius.
March 31, 2026 — 03:29 UTC
Malicious versions removed from npm following StepSecurity and Socket disclosures. But anyone who ran npm install in that ~3 hour window is potentially compromised.
The 18-hour head start on seeding the clean plain-crypto-js@4.2.0 was deliberate: most automated security scanners look for brand-new packages with no publish history. By the time the malicious version dropped, the account looked credible.
What the malware actually does
When npm install runs, npm resolves the dependency tree, pulls in plain-crypto-js@4.2.1, and automatically executes its postinstall hook: node setup.js. That’s it. That’s the moment of compromise.
The dropper in setup.js uses two layers of obfuscation — reversed Base64 with padding substitution, followed by an XOR cipher — before reaching out to the C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73) to download a platform-specific second-stage RAT.
After execution, it covers its tracks: deletes itself, removes the package.json containing the postinstall hook, and replaces it with a clean decoy. Inspecting node_modules/plain-crypto-js afterward looks completely innocent — unless you know that the folder shouldn’t exist at all.
macOS artifact
/Library/Caches/com.apple.act.mond
Linux artifact
/tmp/ld.py
Windows artifact
%PROGRAMDATA%wt.exe
C2 indicators of compromise
Block and audit outbound connections to sfrclak[.]com and IP142.11.206.73on port 8000. If any machine shows this traffic in network logs, assume full compromise.
Who is at risk
Risk is highest if any of the following applied to your environment between 00:21 UTC and 03:29 UTC on March 31, 2026:
CI/CD pipelines that don’t pin dependency versions and run npm install on a schedule or commit
Developers who ran npm install or npm update in that window
Projects using caret ranges (^1.14.0 or ^0.30.0) in package.json — these auto-pull the latest minor/patch
Anyone pulling @shadanai/openclaw or @qqbrowser/openclaw-qbot@0.0.130 — secondary packages that vendor the same payload
If your lockfile was committed before the malicious versions were published and your install did not update it, you were not affected. But verify before assuming.
How we responded at our company
Our incident response, step by step
Step 1
Immediate audit across all projects. We reached out to every tech lead the moment the alert hit. The ask was clear: check axios versions in every project you own right now — run cat package-lock.json | grep axios or npm list axios and report back. No exceptions, no “we’ll get to it later.”
Step 2
Check for the malicious dependency. Tech leads were also asked to run npm list plain-crypto-js on every project and every active dev machine. Any output at all = affected.
Step 3
Client notification — before patching. We contacted our clients proactively. We told them what happened, what we were checking, what the risk window was, and what we were doing. Transparency first. This matters for trust, and in some cases it’s contractually required.
Step 4
Patch, then build. Affected projects were downgraded to axios@1.14.0 (for 1.x) or axios@0.30.3 (for 0.x), lockfiles updated, plain-crypto-js directory manually removed from node_modules, then clean reinstall with npm install –ignore-scripts. Only after a clean verified build did we promote to any environment.
Step 5
Credential rotation for any potentially exposed machines. Any dev machine or CI runner that ran a fresh npm install in the risk window: all .env values, AWS keys, npm tokens, SSH keys, and CI secrets rotated immediately. Don’t assume you’re safe — rotate anyway.
Step 6
Network log audit. Checked network logs for any outbound connections to sfrclak.com or 142.11.206.73. Found nothing — but checking was non-negotiable.
Your remediation checklist
1.Audit every project for the affected version
Run npm list axios or grep the lockfile. Any project showing 1.14.1 or 0.30.4 needs immediate action.
2.Search for the malicious dependency
npm list plain-crypto-js — if anything prints (other than empty), the dropper has run.
3.Downgrade and reinstall clean
npm install axios@1.14.0 (or 0.30.3). Then npm install –ignore-scripts to prevent postinstall scripts from running.
4.Check for RAT files on every machine
macOS:ls /Library/Caches/com.apple.act.mond ·Linux: ls /tmp/ld.py ·Windows: Test-Path “$env:ProgramDatawt.exe”
5.Rotate all credentials on affected machines
All .env secrets, AWS/GCP/Azure keys, npm tokens, SSH keys, CI secrets. Do not wait. Rotate even if you’re unsure.
6.Audit network logs for C2 communication
Block and scan for sfrclak[.]com and 142.11.206.73:8000. Any hit = full machine compromise assumed.
Preventing the next one
This attack worked because open source supply chain trust is implicit. A package published under a maintainer’s account looks legitimate. We need to break that assumption permanently.
Hardening your CI/CD now
Always run npm install –ignore-scripts in CI environments. This blocks postinstall scripts — the exact mechanism used to deploy this RAT. For production lockfiles, commit and check them in — never rely on floating ranges like ^1.14.0 in high-stakes environments. Consider a tool like Socket, Snyk, or StepSecurity for real-time supply chain monitoring.
Require npm accounts with publishing rights to use hardware MFA — not TOTP — and audit your own team’s npm token hygiene. Long-lived classic tokens (the likely attack vector here) should be rotated for granular automation tokens with limited scope.
Final thought
Supply chain attacks are not going away. The axios incident follows the same playbook used against Chalk, Debug, and the Shai-Hulud npm worm in late 2025. The pattern: compromise a maintainer’s account, publish a poisoned version, exploit the ecosystem’s implicit trust in registered packages.
The only real defense is layered: pin versions, verify provenance, block postinstall scripts in CI, monitor for new unexpected dependencies, and have an incident response plan before you need it. We had ours. That’s why we could move fast.
If you found this useful, share it with your team leads. The people who need this aren’t always reading security blogs — they’re building features and might not know their npm install this morning dropped a RAT.
The post Supply Chain attack: Axios Was Compromised. Here’s Exactly What Happened and What We Did. appeared first on Spritle software.