The Axios Supply Chain Attack: What Happened and What to Do Now

Critical: Axios npm Supply Chain Attack — March 31 2026

On March 31 2026, two malicious versions of axios — one of the most downloaded npm packages in the world with over 300 million weekly downloads — were briefly published to the npm registry via a compromised maintainer account.

The affected versions (1.14.1 and 0.30.4) were live for roughly two hours before being pulled. In that window, any developer or CI/CD pipeline that ran npm install could have silently installed a cross-platform Remote Access Trojan (RAT).

Safe versions: Everything except 1.14.1 and 0.30.4. If neither appears in your lockfile, you are not affected.

---

How the Attack Worked

The attacker did not touch a single line of Axios source code. Instead, they injected a malicious transitive dependency — plain-crypto-js@4.2.1 — into the package.json of the new Axios releases. That package's postinstall hook ran node setup.js automatically during npm install, which was the entry point for the compromise.

The dropper used two layers of obfuscation — reversed Base64 encoding and an XOR cipher — to evade static analysis. It then detected the host OS and downloaded a second-stage platform-specific RAT from a remote command-and-control (C2) server.

To cover its tracks, the malware deleted setup.js and replaced the package.json containing the postinstall hook with a clean file. Inspecting node_modules/plain-crypto-js after the fact showed no obvious signs that anything malicious had ever run.

Platform-specific payloads

Platform	Payload
macOS	Binary disguised as an Apple background daemon, beaconing every 60 seconds
Windows	PowerShell RAT hidden behind a fake Windows Terminal binary
Linux	Python RAT launched as an orphaned background process via nohup

---

Who Was Actually at Risk

The blast radius was determined by timing and lockfile hygiene.

Highest risk:

• CI/CD pipelines that run npm install on a schedule and do not pin dependency versions — especially those running overnight or in the early hours UTC.
• Developers who ran npm install or npm update during that specific two-hour window.

Not affected:

• Projects whose package-lock.json or yarn.lock was committed before the malicious versions were published and whose install did not update it. Lockfiles are your first line of defence here.

---

Immediate Actions

1. Check whether you installed an affected version

# Check lockfile for malicious versions
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# Check for the malicious dependency in the dependency tree
npm ls plain-crypto-js

2. Check for indicators of compromise (IOCs)

Platform	What to look for
macOS	/Library/Caches/com.apple.act.mond
Windows	%PROGRAMDATA%\wt.exe
Linux	/tmp/ld.py
Network	Outbound traffic to sfrclak[.]com / 142.11.206.73:8000

3. If you were affected — treat it as a full breach

Isolate the system immediately.

Then:

• Rotate every credential on the affected machine: API keys, SSH keys, cloud credentials, npm tokens, GitHub tokens. Do not rotate in place — revoke and reissue.
• Rebuild environments from a known-clean snapshot. Do not attempt to sanitise a compromised machine.

---

Hardening Your Supply Chain Going Forward

This attack was preventable with the right controls in place.

Use npm ci in CI/CD — not npm install

npm ci enforces lockfile integrity. It fails if the lockfile is out of sync with package.json, preventing unexpected version resolution in your pipelines.

Commit your lockfiles — always

Lockfiles are not optional. They pin the entire resolved dependency tree and are your most reliable protection against transient malicious versions.

Disable postinstall scripts in CI where possible

npm ci --ignore-scripts

This prevents postinstall hooks from running. It would have blocked this specific attack vector entirely. Be aware that it can break packages that legitimately need post-install steps, such as native addons — so test first.

Set up dependency auditing in your pipelines

Run npm audit as part of your CI gates. Integrate a software composition analysis (SCA) tool — options include open-source tools like audit-ci — and block builds when high-severity vulnerabilities are detected.

Monitor for unexpected outbound network traffic from build agents

Build environments should have restricted egress. Any unexpected connection to an unknown domain from a CI runner is a red flag worth alerting on.

Consider a private npm registry or mirror

Using a private registry (Azure Artifacts, JFrog Artifactory, Nexus) lets you control which packages are available to your builds and adds a quarantine layer before new versions reach your pipelines.

---

The Bigger Picture

This attack follows a now-familiar pattern: compromise a legitimate maintainer account, publish a malicious version of a trusted package, and rely on the ecosystem's implicit trust of registered packages. What makes Axios particularly significant is scale — 300 million weekly downloads means even a two-hour window represents an enormous potential blast radius.

The lesson is not to stop using npm or distrust open source. It is to understand which supply chain controls would have caught this: lockfile enforcement, postinstall script auditing, and runtime monitoring for unexpected process spawns or outbound connections from build environments.

Every team running Node.js at scale should be able to answer these questions today:

• Are our lockfiles committed and enforced in CI?
• Do our build agents run with --ignore-scripts where possible?
• Do we have egress monitoring on build infrastructure?
• Do we have SCA scanning in our pipelines?

If the answer to any of these is "no" or "I'm not sure" — this incident is your reminder to fix that.

---

Questions about securing your application's dependencies or build pipeline? Get in touch with our team.