100 Million Downloads. One Compromised Account. Your Machine Is Now a Botnet.

TL;DR

• Affected versions: axios@1.14.1 (published 00:21 UTC) and axios@0.30.4 (published 01:00 UTC) — both removed by ~03:15 UTC on March 31, 2026. Total exposure window: ~3 hours.
• The attacker hijacked the jasonsaayman npm account (primary Axios maintainer) and changed its registered email to ifstap@proton.me.
• A rogue dependency — plain-crypto-js@4.2.1 — was injected into both releases. It ran a postinstall RAT dropper (node setup.js) that contacted C2 server sfrclak.com:8000.
• The dropper used double-layer obfuscation: reversed Base64 with _ → = substitution, then XOR cipher with key OrDeR_7077.
• After execution, the dropper self-erased: deleted setup.js, replaced package.json with a clean decoy, removed the postinstall hook.
• npm audit reports clean after compromise. Detection required network-level monitoring.
• Early attribution links this to TeamPCP — the same group behind the Trivy, KICS, LiteLLM, and Telnyx supply chain attacks in March 2026.
• C2 indicator of compromise: sfrclak.com:8000.

Why This Attack Is Different

Most npm malware is blunt. A bad actor hardcodes a crypto miner, someone notices, the package gets yanked. Unsophisticated. Traceable. Over in days.

This was not that.

The Axios attack is a precision-guided, multi-stage, self-erasing supply chain compromise targeting one of the most trusted packages in the JavaScript ecosystem. Axios is present in roughly 80% of cloud and code environments, per Wiz. And after the dropper ran, your system looked perfectly clean.

⚠️ Warning: Huntress observed 135 endpoints across all operating systems contacting the attacker's C2 server during the exposure window. The first infection landed 89 seconds after axios@1.14.1 was published — consistent with automated CI/CD pipelines using caret ranges (^1.x) without locked dependencies.

The Attack Timeline

The attack was staged across 18 hours — not improvised. Every step was designed to evade automated scanners that flag new, zero-history packages.

💡 Tip: Note the timing — published just after midnight UTC on a Sunday night going into Monday. This maximized the gap before maintainers and the npm security team would be online to respond.

How the Attack Was Structured

The Axios library itself was never touched. Instead, plain-crypto-js@4.2.1 — a rogue dependency — was slipped into both release branches within 39 minutes of each other, covering both modern (1.x) and legacy (0.x) users simultaneously.

Stage 1 — Maintainer Account Hijack

The attacker compromised jasonsaayman — the primary maintainer of the Axios project — and changed the account's registered email to ifstap@proton.me. Both malicious releases appear in the npm registry as published by jasonsaayman, making them indistinguishable from legitimate releases at a glance.

Neither version appears in the project's official GitHub tags. That's the only visible hint something was wrong — and it requires you to know to look for it.

💡 Tip: One reliable supply chain hygiene check: verify that npm releases have a corresponding GitHub release or tag. If a version exists on npm but not on GitHub, treat it as suspicious.

Stage 2 — The Pre-Staged Rogue Dependency

The plain-crypto-js package was a purpose-built attack tool. Version 4.2.0 was published 18 hours before the malicious Axios releases — a clean copy of the legitimate crypto-js library with zero malicious code. Its only job was to give the npm account a brief publishing history so automated scanners wouldn't flag it as a zero-history suspicious package on the next update.

Then 4.2.1 dropped with the payload:

// plain-crypto-js@4.2.1 — package.json (malicious)
{
  "name": "plain-crypto-js",
  "version": "4.2.1",
  "scripts": {
    "postinstall": "node setup.js"
  }
}

The setup.js dropper was 4,209 bytes and used two layers of obfuscation to defeat static analysis:

Stage 3 — The RAT Dropper

Once deobfuscated, setup.js executed a precise sequence — and it was fast. Malware was calling home to the attacker's server within two seconds of npm install, before npm had even finished resolving the full dependency tree.

1. Detect OS (macOS / Windows / Linux)
2. HTTP POST to sfrclak.com:8000
3. Receive OS-specific Stage 2 binary
4. Write binary to disk
5. Execute binary → establish persistent remote access
6. Begin immediate credential exfiltration

What the RAT harvested on first contact:

• User directory and filesystem enumeration
• Running process list
• Environment variables and .env files
• ~/.aws/credentials and cloud token files
• SSH private keys
• CI/CD secrets (npm publish tokens, GitHub deploy keys, Kubernetes configs)

Wiz researchers observed TeamPCP validating stolen credentials within hours using TruffleHog, then conducting reconnaissance across AWS IAM, EC2, Lambda, S3, and Secrets Manager.

⚠️ Warning: Three separate Stage 2 binaries — for macOS, Windows, and Linux — were pre-built and waiting on the C2 server before the Axios releases even went live.

Stage 4 — The Cleanup (Why npm audit Sees Nothing)

After establishing remote access, the dropper erased its own footprints:

Run npm audit after this. You get a clean result. The RAT is already running.

Detection required network-level monitoring: StepSecurity's Harden-Runner flagged anomalous outbound connections to sfrclak.com:8000 in CI runs — a domain that had never appeared in any prior workflow run. Sophos customer telemetry caught the same C2 callback at approximately 00:45 UTC on March 31, within 24 minutes of the first malicious version going live.

The TeamPCP Connection

This was not a one-off opportunistic attack. Early attribution from SANS and Wiz researchers links the Axios compromise to TeamPCP — a threat actor group systematically targeting open-source DevTool supply chains to harvest cloud credentials at scale.

Between March 19 and March 27, 2026 alone, TeamPCP compromised four major open-source projects:

Each campaign used the same playbook: compromise a maintainer account, inject a malicious dependency, harvest credentials, validate them within hours, then move laterally through cloud infrastructure.

⚠️ Warning: Two secondary packages were also observed shipping plain-crypto-js@4.2.1: @qqbrowser/openclaw-qbot@0.0.130 and @shadanai/openclaw. Exposure through these does not depend on the March 31 UTC window.

Am I Compromised? Check This Now

Step 1 — Check for the affected Axios versions:

# Check your package.json
cat package.json | grep '"axios"'
 
# Check the resolved version in lockfile
cat package-lock.json | grep -A2 '"node_modules/axios"'

Danger versions: axios@1.14.1 and axios@0.30.4.

Step 2 — Check for the rogue dependency:

ls node_modules | grep plain-crypto

Step 3 — Hunt for C2 traffic in your build logs:

# Indicator of Compromise — look for outbound connections to:
sfrclak.com:8000

Step 4 — If evidence of compromise exists, rotate immediately:

# Credentials to treat as fully compromised:
# - AWS IAM access keys and secret keys
# - OpenAI / LLM API keys
# - GitHub personal access tokens and deploy keys
# - npm publish tokens
# - Database passwords exposed via environment variables
# - SSH private keys on the affected machine

Full incident response guide: Step Security Advisory CVE tracking: GHSA-fw8c-xr5c-95f9 and MAL-2026-2306 Snyk ID: SNYK-JS-PLAINCRYPTOJS-15850652

⚠️ Warning: Even if you don't find the RAT binary — remember, it self-deletes. If your install ran between 00:21 and 03:15 UTC on March 31, 2026 and resolved to either affected version, rotate credentials anyway.

Were You Protected? The Lockfile Question

Your exposure depended entirely on how you manage dependencies:

Production Checklist: Harden Your npm Supply Chain

1. Enable 2FA on all npm accounts with publish rights — use hardware keys, not TOTP alone.
2. Use scoped CI publish tokens — never personal access tokens. Scope to specific package names.
3. Commit and enforce your lockfile — use npm ci in CI pipelines, not npm install.
4. Cross-reference npm releases with GitHub tags — a version on npm without a corresponding GitHub tag is a red flag.
5. Use --ignore-scripts in sensitive CI environments to block postinstall hooks from running.
6. Monitor outbound network connections from build servers — C2 callbacks are your earliest warning signal.
7. Enable Snyk or Socket.dev scanning — both flagged plain-crypto-js@4.2.1 within the exposure window.
8. Rotate secrets on a schedule — treat credentials as ephemeral, not permanent.

# Safer CI install — blocks postinstall scripts entirely
npm ci --ignore-scripts

⚠️ Warning: --ignore-scripts will break packages that legitimately require build steps (native addons, etc.). Audit your dependency list before enabling this globally.

Conclusion

I've been building Node.js applications long enough to remember when postinstall scripts felt like a convenience feature, not an attack surface. This attack reframes that entirely.

What makes Axios uniquely dangerous as a target is its ubiquity — present in 80% of cloud environments, embedded transitively in WordPress modules, Datadog packages, and virtually every JavaScript-adjacent toolchain. The attacker didn't need to be inside for long. Three hours was enough. And with 89 seconds from publish to first infection, there was no manual response fast enough to stop it.

The TeamPCP pattern — compromising DevTool packages to harvest cloud credentials at scale — is going to be the dominant supply chain threat model for the next few years. The tools we use to build software are more valuable targets than the software itself.

Pin your lockfiles. Use npm ci. Monitor your build server's egress. Cross-reference npm releases against GitHub tags.

One npm install really can turn your pipeline into a credential harvester. We have 135 confirmed Huntress-monitored endpoints worth of receipts now.