CareersInCloud
How the Axios npm Supply Chain Attack Slipped Past Everyone's Defenses
supply-chain-securitynpmjavascriptcybersecuritynorth-koreamalwaredevopsopen-source

How the Axios npm Supply Chain Attack Slipped Past Everyone's Defenses

By Shiva4 Apr 2026CloudSutra

On March 31, 2026, millions of JavaScript developers unknowingly became targets of one of the most carefully engineered software supply chain attacks ever executed against the npm ecosystem. The victim? Axios — the HTTP client library that sits quietly inside roughly 80% of cloud and web projects worldwide, with over 100 million weekly downloads.

The attacker did not break Axios's code. They broke trust itself.

What Is a Supply Chain Attack?

Before diving in, it's worth understanding the category of threat. A supply chain attack doesn't exploit your code — it exploits the tools and libraries your code depends on. Instead of attacking you directly, an adversary poisons a trusted upstream package. When you install or update that package, the malware arrives silently, with full legitimacy.

This is exactly what happened here.

How the Attack Was Staged — 18 Hours of Preparation

The attackers were not reckless. They were methodical.

Step 1 — A clean decoy package. On March 30, 2026 at 05:57 UTC, an npm account named nrwise published a package called [email protected]. It was perfectly harmless. No malware, no hooks. Its only job was to exist — to build up a publishing history on npm so that automated scanners would not flag it as a suspicious new package.

Step 2 — The payload drops. Eighteen hours later, at 23:59 UTC, [email protected] was quietly pushed to npm. This time, the package contained a malicious postinstall script — code that runs automatically the moment you run npm install, before you ever open your editor.

Step 3 — The maintainer account is compromised. The attacker had already gained control of the npm account belonging to jasonsaayman, the lead Axios maintainer. The account's registered email was silently changed to [email protected] — an anonymous ProtonMail address — giving the attacker full publishing rights.

Step 4 — Both release branches poisoned in 39 minutes. Using that access, the attacker published [email protected] and [email protected] within a 39-minute window, targeting both the 1.x (current) and 0.x (legacy) branches simultaneously. The only actual change to Axios's package.json? A single new dependency: plain-crypto-js@^4.2.1.

Axios's own source code was untouched. Nothing in the library's logic changed. But any project with a dependency range like ^1.14.0 — which allows npm to auto-upgrade to compatible newer versions — would silently pull the compromised release on its next npm install.

Why the Security Stack Failed

Axios was not a poorly secured project. It had adopted the defenses the security community recommends:

  • OIDC Trusted Publishers — cryptographically tying npm releases to GitHub Actions workflows
  • SLSA provenance attestations — verifiable build provenance
  • Automated CI/CD pipelines — no manual publish steps

Yet none of it mattered.

The critical gap: the project's workflow still passed a classic long-lived NPM_TOKEN as an environment variable alongside the OIDC credentials. When both are present, npm quietly defaults to the token. The attacker used that token — they never had to defeat OIDC at all. GitHub never saw the release. It doesn't appear in the repository's tag history. The attack bypassed the entire GitHub Actions pipeline by publishing directly from the npm CLI.

This is the lesson security teams cannot afford to ignore: modern supply chain defenses only protect the path they control. A single fallback credential outside that path is enough to undo everything.

The Malware: One RAT, Three Platforms

Once installed, [email protected]'s postinstall script executed within two seconds — before npm had even finished resolving the dependency graph.

The script contacted a command-and-control server at sfrclak[.]com:8000 and downloaded a platform-specific second-stage payload:

| Platform | Language | Artifact path | |----------|----------|---------------| | Windows | PowerShell | %PROGRAMDATA%\wt.exe | | macOS | C++ (Mach-O binary) | /Library/Caches/com.apple.act.mond | | Linux | Python | /tmp/ld.py |

All three were implementations of the same Remote Access Trojan — sharing an identical C2 protocol, command set, and beacon cadence. The RAT checks in every 60 seconds and supports:

  • Remote shell execution
  • Binary injection
  • Directory browsing and file exfiltration
  • Process listing and system reconnaissance

After deploying, the dropper deleted itself and replaced its own package.json with a clean version, erasing forensic evidence of the postinstall trigger from node_modules.

What was at risk? Any secret accessible to the process that ran npm install — environment variables, cloud API keys (AWS_SECRET_ACCESS_KEY, Google Cloud tokens, Azure credentials), SSH private keys, CI/CD pipeline secrets, .env files. Everything.

Attribution: Sapphire Sleet and North Korea

Two separate research teams independently traced the infrastructure.

Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state-sponsored threat actor known for financially motivated operations targeting cryptocurrency and software supply chains.

Elastic Security Labs noted that the macOS binary exhibits significant technical overlap with WAVESHAPER — a C++ backdoor previously documented by Mandiant and attributed to the North Korean group UNC1069.

The level of operational sophistication — pre-staged clean packages, dual-branch targeting, platform-native RAT implementations, anti-forensic cleanup — is consistent with a well-resourced nation-state operation, not an opportunistic attacker.

Timeline of Events

Mar 30 — 05:57 UTC  [email protected] published (clean, decoy)
Mar 30 — 23:59 UTC  [email protected] published (malicious payload)
Mar 31 — 00:21 UTC  [email protected] published (compromised)
Mar 31 — 01:00 UTC  [email protected] published (compromised)
Mar 31 — 01:50 UTC  Elastic Security Labs files GitHub Security Advisory
Mar 31 — 03:29 UTC  Both malicious axios versions removed from npm

Socket's automated detection flagged the malicious [email protected] just six minutes after it was published. Despite that, the window was wide enough to impact any CI/CD pipeline or developer machine that ran npm install during those hours.

Are You Affected? How to Check

Check for the malicious versions:

npm list axios

If the output shows [email protected] or [email protected], your environment was exposed.

Check for RAT artifacts:

# macOS
ls /Library/Caches/com.apple.act.mond

# Linux
ls /tmp/ld.py

# Windows (PowerShell)
Test-Path "$env:PROGRAMDATA\wt.exe"

Check for C2 traffic in your network logs: Look for outbound connections to sfrclak[.]com on port 8000, or beaconing HTTP POST requests at roughly 60-second intervals.

What to Do Right Now

If you ran npm install during the attack window:

  1. Assume full compromise — the RAT was live and capable of executing follow-on payloads.
  2. Rotate every secret immediately: npm tokens, AWS access keys, SSH private keys, cloud credentials, GitHub secrets, anything stored in .env files.
  3. Isolate the affected machine from your network before investigating further.
  4. Downgrade Axios to a safe version: [email protected] or [email protected].
  5. Block C2 infrastructure: sfrclak[.]com and IP 142.11.206[.]73.

Preventative hardening for the future:

  • Pin your lockfile. Commit package-lock.json and use npm ci instead of npm install in CI/CD. This prevents any version from being resolved that isn't explicitly pinned.
  • Use --ignore-scripts in automated build environments to block postinstall hooks from running during CI.
  • Audit your npm tokens. Remove any long-lived classic tokens and replace them with OIDC-only authentication. Do not allow fallback.
  • Restrict automated dependency bots. Pause or throttle Dependabot and Renovate for critical packages until you have a review process in place.
  • Monitor for anomalous outbound connections from Node.js processes, especially during npm install — legitimate packages should never be calling out to the internet on install.

The Bigger Picture

This is the third significant npm supply chain compromise in seven months. Each one exploited a single stolen maintainer credential. The pattern is clear: attackers have identified the npm registry's trust model as a high-value, repeatable attack surface.

The Axios attack is notable not because the defenders failed — Axios had done nearly everything right. It's notable because it demonstrated that even a well-secured project can be undone by a single long-lived credential existing alongside modern controls.

The JavaScript ecosystem's security posture depends not just on what each project does, but on the registry's ability to detect and respond to credential compromise in near real-time. Until that bar is significantly raised, the question for any organization relying heavily on npm is not if something like this will happen again — it's which package, and when.

Indicators of Compromise (IOCs):

CloudSutraBack to all articles