Axios npm Backdoor: How 70 Million Weekly Downloads Got a North Korean RAT

#The afternoon npm ate itself

I was in the middle of a client Slack thread when my phone lit up. Three different security contacts pinging at once. "Axios is compromised." "All versions?" "Latest tag is poisoned, at least two versions."

March 31, 2026. 09:13 UTC. A compromised npm maintainer account shipped two malicious versions of Axios. The HTTP client that ships in basically every modern JavaScript project. 70 million downloads a week. Before the packages were caught and yanked, anyone who ran npm install in that window pulled the backdoor.

This post is what we know about the attack, what the WAVESHAPER RAT does on an infected host, and the supply chain hardening every engineering team should have in place before this happens again. Because it will.

#What happened

At 09:13 UTC on March 31, 2026, a compromised npm maintainer account published two new versions of Axios. axios@1.14.1 was tagged latest. axios@0.30.4 was tagged legacy, targeting projects still on the 0.x branch.

Axios has approximately 70 million weekly downloads. In the two to three hours before the backdoor was caught and removed, an unknown but large number of npm install and yarn add commands pulled the compromised packages. Any developer, CI/CD pipeline, or production deploy that ran during that window is now a potential WAVESHAPER RAT infection.

The attribution is firm: Google Mandiant, Huntress, SANS ISC, and Elastic Security Labs all independently link the activity to UNC1069, a financially motivated North Korean threat actor active since at least 2018. The same group was recently tied to the axios-unrelated crypto theft campaigns that have drained hundreds of millions from DeFi protocols over the last two years.

This post covers how the attack worked, the WAVESHAPER backdoor's technical profile, how Axios responded, and. Most importantly. The concrete supply chain hardening every engineering team should have in place before the next one.

#The attack chain

#Step 1: Social engineering the maintainer

Jason Saayman (GitHub: jasonsaayman) is the Axios project's lead maintainer. He's one of the most prolific open-source contributors in the JS ecosystem. Fairly public profile, known employer, active on Twitter.

In the weeks before the attack, Saayman was targeted by an elaborate phishing campaign. Per his post-mortem published April 2, 2026, the attackers impersonated a security researcher reaching out about a "critical vulnerability report" in Axios and requesting a coordinated disclosure call. The spear-phishing emails:

• Came from a domain that appeared to be a legitimate security-research firm (typosquatted)
• Included plausible technical details about the Axios codebase
• Referenced prior Axios bug reports to build credibility
• Escalated to a Zoom-like video call link that prompted for npm credential re-authentication on a spoofed page

Saayman entered his npm credentials and TOTP code on the spoofed page. The attackers immediately harvested the session. His npm account had 2FA enabled. But the TOTP was submitted and consumed within the same window by the attacker's automated backend. A classic adversary-in-the-middle (AiTM) kit.

With valid npm session cookies, the attackers had publish rights on axios, as well as on several adjacent packages in Saayman's account.

#Step 2: Trojanized publishing

The attacker didn't modify the main Axios source tree. They published two "release" versions that claimed to fix minor issues, with the usual changelog entries crafted to look innocuous. The malicious content was carried not in the HTTP-client code itself but in a postinstall script attached to the npm package.

A postinstall script runs automatically on every npm install of the package, executing whatever JavaScript is specified. This is standard npm behavior. Lots of legitimate packages use postinstall for native-addon compilation or initial setup. It's also the single most-abused supply chain vector in the npm ecosystem.

The compromised versions declared a dependency on a package named plain-crypto-js@4.2.1. A trojanized fork of crypto-js that the same attacker had published earlier the same week. On install, the postinstall hook would fetch, decrypt, and execute the embedded WAVESHAPER stage-one loader.

The two targeted Axios versions. 1.14.1 (current) and 0.30.4 (legacy). Were chosen deliberately:

• 1.14.1 targeted the newest production installations (the ones most likely to have high-value API keys, cloud credentials, crypto wallets in dev environments).
• 0.30.4 targeted the large long-tail of legacy apps that pin ^0.x.x ranges. Often internal enterprise apps that haven't been updated in years and run in privileged environments with weak monitoring.

#Step 3: WAVESHAPER.V2 cross-platform RAT

Once the postinstall hook executed, the malware staged a cross-platform backdoor now tracked as WAVESHAPER.V2. Capabilities per the Huntress, Elastic, and Mandiant analyses:

• Target platforms: Windows (amd64 + arm64), macOS (Intel + Apple Silicon), Linux (amd64, arm64, arm32)
• Persistence: platform-specific mechanisms. Windows registry Run keys or scheduled tasks, macOS LaunchAgent, Linux systemd user units or ~/.bashrc hooks
• Command-and-control: HTTPS polling against a rotating set of domains hosted behind Cloudflare + legitimate CDN-fronted infrastructure to avoid easy IP-blocklisting
• Core capabilities:

- File read/write, directory listing

- Remote shell execution

- Credential harvesting from browser profiles (Chrome, Firefox, Brave, Edge), system keychains, .ssh, .aws, .npmrc, .git-credentials

- Crypto wallet scanning (browser extension wallets + local keystore files)

- Source code exfiltration (targeted by extensions: .ts, .js, .sol, .py, .go, .rs)

- Environment variable dumping

- Docker socket enumeration (if accessible)

- Kubeconfig exfiltration

- Screenshot capture every 10 minutes

- Keylogging (loadable stage-two module)

• Evasion: runs with same privileges as the user that triggered npm install. Hides in legit node_modules subpaths. Obfuscated with multiple layers of packer (two layers of JS obfuscation + native binary fetched from remote).

The target profile is the JavaScript developer's machine: a workstation or CI runner with credentials to cloud accounts, production databases, git repos. And crypto wallets. For a North Korean operation whose primary mandate is hard-currency generation, this is almost an optimal compromise target.

#Detection and response

• T+0:00 (March 31, 09:13 UTC): Compromised versions published to npm.
• T+0:34: First automated detection by Socket's npm-monitoring system flagged the unusual maintainer behavior (new postinstall script in a package that historically didn't have one).
• T+0:49: Internal GitHub Security Advisory team cross-referenced the new dependency plain-crypto-js@4.2.1 against their malicious package database. Match.
• T+1:12: npm team contacted. They began the removal process.
• T+2:47: Malicious versions unpublished from npm.
• T+3:00+: npm install axios downloads revert to the safe prior version.

Net exposure window: approximately 2 hours 47 minutes.

During that window, best estimates from GitHub, Socket, and SANS put the compromised-install count in the hundreds of thousands. Possibly millions if CI/CD pipelines with cache-busted builds pulled the new version rapidly.

Axios's response was swift and transparent:

• Saayman published a detailed post-mortem within 24 hours
• Axios's 2FA enforcement on all maintainers was upgraded to WebAuthn / FIDO2 hardware keys (disabling TOTP, which was phishable)
• The plain-crypto-js and related malicious dependency packages were reported
• Indicators of compromise published to Socket, npm, Snyk, and GitHub Advisory DB

#What to do if you were exposed

#If you ran npm install or yarn add between March 31 09:13 UTC and 12:00 UTC:

Immediate:

1. Check your installed axios version in every project that was installed or CI-built during the window:

npm list axios
   find. -path "*/node_modules/axios/package.json" -exec grep -l '"version"' {} \\;

If you see 1.14.1 or 0.30.4, you were exposed.

1. Delete the infected node_modules directory and reinstall:

rm -rf node_modules package-lock.json
   npm install

1. Check for the dropper dependency:

grep -r "plain-crypto-js". --include=package*.json

If found anywhere in your tree, you installed the malicious variant.

Secondary:

1. Scan your development machine for WAVESHAPER persistence artifacts (Huntress and Mandiant published IOCs covering registry keys, LaunchAgents, systemd unit names. And file hashes). Use Microsoft Defender, Malwarebytes, or the vendor IOC lists directly.

1. Rotate every credential that was on the affected machine during and after the install window:

- Cloud provider API keys (AWS, GCP, Azure)

- SSH private keys (~/.ssh/id_rsa, id_ed25519, etc.)

- GitHub personal access tokens

- npm tokens

- Any .env values

- Browser-stored passwords (force logout, reset master password on your password manager)

- Crypto wallet seed phrases. Assume compromised. Move funds to newly-generated wallets

1. Rotate production credentials that were touched by any CI/CD pipeline that ran npm install during the window.

1. Review logs for outbound traffic to the WAVESHAPER C2 domain list. Persistent connections or DNS lookups to the published domains are compromise confirmation.

#If you don't know whether you were exposed:

Run the IOC scanning steps regardless. The base rate of false positives is low and the blast radius of a WAVESHAPER infection is catastrophic.

#Supply chain hardening. What should be in place

This wasn't the first supply chain attack on npm. It won't be the last. The industry has known the risks since event-stream (2018), ua-parser-js (2021), node-ipc (2022), the rash of 2023 malicious packages, SolarWinds (2020. Non-npm but same category), the XZ Utils backdoor (CVE-2024-3094), and many others. The pattern: trusted maintainer account compromised → malicious package published → blast radius scales with download counts.

If you're building software, these are the non-negotiable controls for 2026:

#1. Pin versions exactly. No caret, no tilde

// BAD. Will pull backdoored versions automatically
"axios": "^1.13.0"

// GOOD. Locked to a specific version
"axios": "1.13.2"

Combined with package-lock.json committed to your repo, this ensures npm install always produces an identical tree. CI/CD runs get reproducible builds. The attack window on fresh pulls collapses to zero.

#2. Use npm audit signatures (or Socket, Snyk, or Dependabot)

npm audit signatures

This checks every dependency's cryptographic signature against npm's registry. If a package was modified after publish, or if a package was published without proper signing, it flags. Enforce in CI.

#3. Enable provenance-based verification

Since late 2023, npm supports package provenance (Sigstore-signed build attestations). Verify that dependencies you consume are built by the same pipeline each time:

npm install --provenance

Once enabled across the ecosystem, supply chain attacks via npm publish become immediately detectable as provenance mismatches.

#4. Use a dependency firewall / private registry

Tools like Verdaccio, Artifactory, Socket, Snyk Registry, or Cloudsmith let you:

• Proxy npm installs through a registry that enforces custom policies
• Delay new dependency versions by a cooling-off period (24-72 hours) so the community catches malicious releases before you pull them
• Block known-malicious packages at the registry layer
• Enforce signature verification
• Generate SBOM (Software Bill of Materials) automatically

If you're building production software at a company, a dependency firewall is no longer optional.

#5. Separate CI/CD credentials from developer machines

The WAVESHAPER RAT's most dangerous output wasn't the harvested SSH keys on developer machines. It was the credentials harvested from CI/CD runners that had full deploy authority to production. Your CI/CD should:

• Run in ephemeral containers (no state between runs)
• Use OIDC-based short-lived credentials to cloud providers instead of long-lived API keys
• Not have access to production databases or secrets beyond what the specific job needs
• Keep a strict allowlist of packages. Anything new requires approval

#6. Maintainer 2FA must be hardware-key (WebAuthn / FIDO2), not TOTP

TOTP is phishable. WebAuthn isn't. Any open-source project you rely on that still allows TOTP-only 2FA for maintainers is one AiTM away from being the next Axios.

If you maintain a popular package: enforce WebAuthn. If you depend on one: check whether the maintainer has it enabled. If they don't, consider that a vendor risk.

#7. Monitor outbound traffic

Your developer machines and CI runners should have egress monitoring. Any anomalous connections out of node_modules, any DNS queries to unusual domains, any outbound HTTPS to newly-registered hosts. These are compromise indicators. Tools like Snowflake, Datadog Cloud Security, or lightweight egress policy via a proxy catch WAVESHAPER-class backdoors within their first outbound call.

#8. SBOM in every deploy

Generate a Software Bill of Materials for every production build. When a supply chain attack is disclosed, you want to be able to answer "did my deploys between X and Y include the compromised package?" in minutes, not days. Standards: SPDX, CycloneDX. Tools: Syft, CycloneDX CLI, GitHub's dependency submission API.

#What this means for Valtik clients

If your engineering team's threat model hasn't explicitly covered supply chain compromise in the last six months, you're behind the industry. The controls above are the current standard for any B2B SaaS, fintech, healthtech, or crypto firm.

Valtik's application security engagements include supply chain review: dependency inventory, SBOM generation, CI/CD credential handling review, dependency firewall design. And incident-response playbooks specific to the npm install blast radius. If your company runs Node.js, your supply chain is probably already over-exposed. We've found exploitable gaps on every engagement we've run in the last two years.

The next Axios-scale compromise isn't a question of if. It's a question of how fast you can detect and contain it when your developers wake up to "npm install is now mining crypto" on their workstations.

#Sources

1. Axios Supply Chain Attack. The Hacker News
2. Mitigating the Axios npm Supply Chain Compromise. Microsoft Security Blog
3. Inside the Axios Supply Chain Compromise. Elastic Security Labs
4. North Korea-Nexus Threat Actor Compromises Axios. Google Cloud / Mandiant
5. Supply Chain Compromise of axios npm Package. Huntress
6. Axios NPM Supply Chain Compromise. SANS
7. Axios npm Packages Backdoored. Help Net Security
8. 36 Malicious npm Packages. The Hacker News
9. npm Package Provenance Documentation
10. Socket npm Security