Your npm Package Just Installed a Trojan: The Axios Supply Chain Attack Explained

Author

How hackers poisoned one of the most downloaded JavaScript libraries on earth — and what every developer needs to know.

Imagine running a routine npm install on a Monday morning and unknowingly handing attackers full remote access to your machine. No suspicious email. No dodgy download link. Just a dependency update you had every reason to trust.

That nightmare became reality on March 31, 2026, when security researchers at StepSecurity discovered that axios — one of the most popular JavaScript libraries on the planet — had been compromised on npm. The attack deployed a cross-platform Remote Access Trojan (RAT) to developers and CI/CD systems worldwide, and it was almost invisible.

What Is a Supply Chain Attack — And Why Is npm So Vulnerable?

A software supply chain attack does not target your code directly. Instead, attackers infiltrate the tools, libraries, and services your code depends on. By poisoning a trusted component upstream, they reach thousands of victims through a single point of compromise.

Think of it like a food supply chain. Rather than breaking into every home individually, an attacker contaminates ingredients at the factory. Everyone who consumes the product downstream is affected without doing anything wrong.

npm — the Node Package Manager — is one of the most attractive targets in the world for this type of attack. It hosts over two million packages and serves billions of downloads every week. The JavaScript ecosystem runs on a web of nested dependencies, meaning a single malicious package can silently reach millions of projects. The 2020 SolarWinds attack introduced this threat to mainstream awareness, but the npm ecosystem has faced repeated incidents — from the event-stream compromise in 2018 to dozens of typosquatting campaigns targeting popular package names.

The axios attack represents a significant escalation in sophistication.

How the Axios Attack Unfolded: Surgical, Pre-Planned, and Ruthless

Axios logs over 83 million weekly downloads. It is the default HTTP client for countless React applications, backend APIs, and developer tools. Attackers knew exactly what they were targeting.

According to analysis by StepSecurity and The Hacker News, the operation was pre-staged 18 hours before the axios releases went live. Here is how it played out:

March 30, 05:57 UTC — Attackers published a clean decoy package called [email protected] to establish publishing history and avoid raising red flags.
March 30, 23:59 UTC — A malicious version, [email protected], went live, containing an obfuscated RAT dropper triggered by a postinstall script.
March 31, 00:21 UTC — [email protected] published using compromised maintainer credentials, injecting [email protected] as a hidden dependency.
March 31, 01:00 UTC — [email protected] followed 39 minutes later, hitting the legacy 0.x user base simultaneously.

The attacker had stolen npm credentials belonging to the primary axios maintainer, changed the account’s email to an anonymous ProtonMail address, and bypassed the project’s GitHub Actions CI/CD pipeline entirely. Every legitimate axios release uses npm’s OIDC Trusted Publisher mechanism — cryptographically tied to a verified workflow. The malicious version had none of that. It was published manually with a stolen long-lived access token.

Once installed, the malware detected the operating system and deployed platform-specific payloads: an AppleScript dropper on macOS saving a RAT binary to /Library/Caches/com.apple.act.mond, a PowerShell script on Windows disguised as the Windows Terminal executable, and a Python script on Linux saved to /tmp/ld.py. All three contacted the same command-and-control server at sfrclak.com:8000.

Then the malware deleted itself and replaced its own package.json with a clean, innocent-looking file — leaving no obvious trace for post-incident inspection.

What to Look For: Signs Your System May Be Compromised

If your project installed [email protected] or [email protected] at any point — even briefly in a CI/CD pipeline — treat it as a compromise until proven otherwise.

Check your installed axios version:

npm list axios 2>/dev/null | grep -E "1.14.1|0.30.4"

Check for the rogue dependency directory:

ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

The presence of the plain-crypto-js directory alone is enough to confirm the dropper ran, even if the package.json inside looks clean.

Check for RAT artifacts on the host system:

macOS: /Library/Caches/com.apple.act.mond
Linux: /tmp/ld.py
Windows: %PROGRAMDATA%wt.exe

Block network traffic to the attacker’s command-and-control domain sfrclak.com and IP 142.11.206.73 at your firewall or DNS layer immediately.

If you find any of these indicators, do not attempt to clean the system in place. Rebuild from a known-good state and rotate every credential the compromised machine had access to — npm tokens, SSH keys, cloud credentials, CI/CD secrets, and anything stored in .env files.

How to Prevent Supply Chain Attacks on Your npm Projects

The axios incident is a reminder that trusting a package name is not enough. Here is what you can do right now to harden your supply chain:

Pin your dependencies. Use exact versions in package-lock.json and commit the lockfile. Avoid loose version ranges like ^ or ~ in production environments where an npm update can silently pull in a new, potentially compromised release.

Run npm install with --ignore-scripts in CI/CD. The entire axios attack depended on npm executing a postinstall script automatically. Blocking script execution during automated builds removes this entire attack vector:

npm ci --ignore-scripts

Enable two-factor authentication and use OIDC Trusted Publishers. The axios maintainer account was taken over with a stolen long-lived token. npm’s OIDC publishing mechanism ties releases cryptographically to a verified GitHub Actions workflow — making this class of attack far harder. If you maintain an npm package, enable this now. Instructions are available at docs.npmjs.com.

Monitor outbound network traffic in CI/CD pipelines. Tools like StepSecurity Harden-Runner establish a baseline of expected network connections for each workflow and flag anomalies. In this attack, the C2 callback to sfrclak.com:8000 was detected within seconds of npm install completing.

Audit your dependency tree regularly. Use npm audit as a baseline, but supplement it with tools that monitor for newly published versions, unusual new dependencies, or packages with no import usage in the codebase. A dependency that appears in package.json but is never actually require()‘d anywhere in the source — as plain-crypto-js was — is a strong red flag.

Review publish metadata, not just package contents. The axios registry metadata made the compromise visible to anyone who looked: no gitHead, no OIDC binding, and an unfamiliar ProtonMail address. Check that new releases of critical dependencies match the expected publishing pattern.

The Takeaway: Trust Is Not a Security Strategy

The axios supply chain attack is among the most sophisticated npm compromises ever documented. The attackers did not write a single malicious line inside axios itself. They worked around it entirely — staging a fake dependency, compromising a maintainer account, and deploying self-deleting malware across three operating systems in under an hour.

Every JavaScript project that ran npm install during a three-hour window was potentially exposed.

The lesson is not to stop using open-source software — that is neither practical nor the point. The lesson is that blind trust in a package name is not a security posture. Verify publish provenance. Lock your dependencies. Block unnecessary scripts in CI. Monitor your network traffic.

The next attack is already being staged. The question is whether your defenses will catch it.

Further reading and sources: