The Axios npm supply chain attack: What every developer needs to know

On March 31, 2026, one of the JavaScript ecosystem's most trusted packages became a weapon. Axios, the HTTP client used by virtually every Node.js and frontend project, with over 100 million weekly npm downloads, was compromised in a supply chain attack attributed to North Korean state-sponsored actors. Malicious versions silently installed a cross-platform remote access trojan on every machine that ran npm install during a roughly two-to-three-hour window.

If you write JavaScript in any capacity, this one deserves your attention.

What happened

Here's the timeline, pieced together from disclosures by Microsoft, Google, SANS, and several security vendors:

March 29, account takeover. The attacker compromised the npm account of jasonsaayman, the lead Axios maintainer. The account's registered email was changed to an attacker-controlled ProtonMail address (ifstap@proton.me). The likely vector was a stolen long-lived npm classic access token, not a compromised password or session hijack.

March 30, ~06:00 UTC, pre-staging. About 18 hours before the main attack, the attacker published a clean, innocent-looking package called plain-crypto-js@4.2.1 under a separate npm account (nrwise). This "decoy" package contained no malicious code at first. It existed purely to establish a presence on the registry and avoid suspicion when it later appeared as a dependency.

March 31, 00:21 UTC, payload deployment. Using the hijacked maintainer account, the attacker published axios@1.14.1 (targeting the latest tag) with plain-crypto-js@4.2.1 silently added as a runtime dependency. At 01:00 UTC, axios@0.30.4 followed on the legacy tag, covering both current and legacy users.

March 31, ~03:15 UTC, takedown. npm removed the malicious versions from the registry after community reports. The window of exposure was approximately two to three hours.

What the malware did

When a developer or CI/CD pipeline ran npm install and pulled one of the poisoned Axios versions, the plain-crypto-js dependency executed a postinstall script that:

1. Fingerprinted the host OS (Windows, macOS, or Linux).
2. Contacted a command-and-control server (sfrclak[.]com) to retrieve a platform-specific second-stage payload.
3. Deployed a full remote access trojan (RAT) capable of credential theft, reconnaissance, and persistent access.
4. Cleaned up after itself. The malware attempted to remove installation artifacts and replace its own package.json with a clean version to evade forensic detection.

Credential theft happened within seconds of installation. If the RAT executed on your machine, the attacker potentially had access to everything that machine could reach: cloud keys, SSH credentials, environment variables, browser sessions, and more.

Who did this, and why it matters

Both Microsoft and Google attributed this attack to North Korean state-sponsored threat actors (Microsoft calls them "Sapphire Sleet"; Google uses the designation "UNC1069"). These are financially motivated groups with a track record of targeting the software supply chain.

This wasn't a smash-and-grab. The 18-hour pre-staging phase, the dual-tag targeting strategy, and the self-destructing payload all point to careful operational planning. SANS researchers noted that this attack may be connected to the "TeamPCP" campaign, which compromised four other open-source projects (including the Trivy vulnerability scanner and the LiteLLM AI proxy library) in the two weeks prior.

The implication is clear: open-source supply chains are an active target for nation-state actors, and the attacks are getting more sophisticated.

Am I affected?

You're in the clear if:

• You were using axios@1.14.0 or axios@0.30.3 (or any older version) and your lockfile was committed and respected by your install process.
• You did not run npm install between approximately 00:21 and 03:15 UTC on March 31, 2026.

You may be compromised if:

• Your package-lock.json or yarn.lock references axios@1.14.1, axios@0.30.4, or plain-crypto-js@4.2.1.
• Your CI/CD pipeline ran a fresh install during the exposure window.
• You use automated dependency update tools (Dependabot, Renovate) that may have picked up the new version.

How to check quickly:

  
# Search your lockfiles
grep -r "1.14.1\|0.30.4\|plain-crypto-js" package-lock.json yarn.lock pnpm-lock.yaml

# Check node_modules directly
ls node_modules/plain-crypto-js 2>/dev/null && echo "AFFECTED" || echo "clean"
  

Hashes for detection:

• axios@1.14.1: 2553649f2322049666871cea80a5d0d6adc700ca
• axios@0.30.4: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1: 07d889e2dadce6f3910dcbc253317d28ca61c766

What to do if you're affected

Do not attempt in-place remediation. If the RAT executed, the machine must be treated as fully compromised.

1. Isolate the machine from your network immediately.
2. Re-image or restore from a verified clean backup taken before March 30.
3. Rotate all credentials that were accessible from the compromised machine. This includes cloud provider keys (AWS, GCP, Azure), SSH keys, API tokens, database passwords, npm tokens, GitHub tokens, and anything in your environment variables or credential stores.
4. Audit access logs in your cloud environments and code repositories for unauthorized actions during and after the exposure window.
5. Block the C2 domain sfrclak[.]com at your network edge.
6. File an incident report with your security/compliance team. Credential exposure may trigger notification obligations under GDPR, CCPA, or other regulations.

If you caught it before the RAT executed (lockfile saved you, scripts were suppressed):

  
# Downgrade to the last clean version, skipping postinstall scripts
npm install axios@1.14.0 --ignore-scripts

# Remove the malicious dependency if present
rm -rf node_modules/plain-crypto-js
  

Pin the safe version in your package.json:

  
"overrides": {
  "axios": "1.14.0"
}
  

Broader lessons: Hardening your supply chain

This attack succeeded because of a chain of common, fixable weaknesses. Here's what to take away:

1. Commit your lockfiles and enforce them

If your lockfile pins axios@1.14.0, a fresh npm install won't upgrade you to 1.14.1 unless someone explicitly updates it. Lockfiles are your first line of defense against supply chain attacks.

Use npm ci (not npm install) in CI/CD pipelines. It installs exactly what's in the lockfile and fails if there's a mismatch.

2. Disable lifecycle scripts for untrusted packages

The RAT was delivered via a postinstall script. You can suppress these globally:

  
npm install --ignore-scripts
  

Or selectively allow scripts only for trusted packages using tools like @pnpm/allow-scripts or npm's built-in ignore-scripts configuration.

3. Require npm publish provenance

npm now supports the --provenance flag, which ties a published package to a specific source commit and CI/CD workflow using OIDC-based attestation. If a new version of a major package suddenly appears without provenance, that should be a red flag.

4. Throttle automated dependency updates

Tools like Dependabot and Renovate are enormously useful, but they can also auto-PR a malicious version into your codebase. Configure them to:

• Ignore patch/minor updates for critical packages unless manually approved.
• Wait a "cooling off" period (24 to 72 hours) before proposing updates.

5. Monitor for unexpected new dependencies

The real Axios package has three dependencies: follow-redirects, form-data, and proxy-from-env. The sudden appearance of plain-crypto-js was the tell. Tools like Socket, Snyk, and npm audit can flag unexpected new transitive dependencies.

6. Treat npm tokens like production secrets

The attacker likely obtained a long-lived classic npm access token. Use granular, short-lived tokens for publishing. Enable 2FA on your npm account. Audit and rotate tokens regularly.

The bigger picture

The Axios compromise is the latest in an accelerating pattern: nation-state actors are systematically targeting the open-source packages that underpin modern software. The asymmetry is staggering. One compromised maintainer account can push malware to millions of downstream consumers within minutes.

The JavaScript ecosystem is especially vulnerable because of its deep, sprawling dependency trees and the power of npm lifecycle scripts. But this isn't a JavaScript-only problem. PyPI, RubyGems, and other registries face the same structural risks.

As a community, we need to treat package management with the same rigor we apply to production infrastructure. That means lockfiles, provenance checks, script restrictions, and a healthy skepticism toward automatic updates. The tools exist. The question is whether we use them before the next incident, or after.

Stay safe out there.