Axios Just Got Compromised on npm. If You Run Node.js Anywhere, Read This Now.

Here’s the short version: axios, the JavaScript HTTP client with over 100 million weekly npm downloads, was compromised this morning. Versions 1.14.1 and 0.30.4 contain a hidden dependency that drops a remote access trojan on every major operating system. If you or any of your clients installed either version, you need to rotate credentials today. Not tomorrow. Today.

What Actually Happened

On March 30, an attacker compromised the npm account of axios’s primary maintainer (“jasonsaayman”) and used it to publish two poisoned versions of the package. The attack didn’t modify axios’s source code at all. Instead, it injected a fake dependency called plain-crypto-js@4.2.1 that runs a postinstall script the moment you run npm install.

That script is a cross-platform RAT dropper. It detects your OS, pulls a second-stage payload from a command-and-control server, executes it, then deletes itself and rewrites its own package.json with a clean version. If you check your node_modules folder after the fact, everything looks normal.

The timeline, according to StepSecurity:

  • March 30, 05:57 UTC — Clean plain-crypto-js@4.2.0 published to npm (staging the legitimate-looking package history)
  • March 30, 23:59 UTC — Malicious plain-crypto-js@4.2.1 published with the payload
  • March 31, 00:21 UTC — Poisoned axios@1.14.1 published via compromised maintainer account
  • March 31, 01:00 UTC — Poisoned axios@0.30.4 published via the same account

Both release branches hit within 39 minutes of each other. The malicious dependency was staged 18 hours in advance. Three separate payloads pre-built for macOS, Windows, and Linux. This wasn’t opportunistic. This was planned.

How the Payload Works

The RAT dropper branches based on OS:

  • macOS: Runs an AppleScript payload that fetches a trojan binary, saves it to /Library/Caches/, makes it executable, and launches it via /bin/zsh. Deletes the AppleScript after.
  • Windows: Copies PowerShell to %PROGRAMDATA%\wt.exe (disguising it as Windows Terminal), writes a VBScript to the temp directory, and executes it.
  • Linux: Similar fetch-and-execute pattern targeting the user’s home directory.

All three paths phone home to sfrclak.com:8000 within two seconds of npm install — before npm even finishes resolving the rest of your dependencies.

Why MSPs Should Care

You might be thinking: “We don’t write JavaScript.” But your tools do. PSA platforms, RMM dashboards, client portals, ticketing systems, internal automation scripts — if any of those run on Node.js (and many do), they likely have axios somewhere in the dependency tree. It’s one of the most widely used packages in the entire JavaScript ecosystem.

This is the same pattern we’ve been warning about with your MSP tooling: the tools you trust are the tools attackers target. The xz utils backdoor was a wake-up call. This is the alarm going off again, louder.

If you manage client environments that run any Node.js applications — and in 2026, that’s most of them — you need to audit right now.

What to Do Before You Leave Today

1. Check if you’re affected. Run npm ls axios in every Node.js project across your environment and your clients’ environments. Look for versions 1.14.1 or 0.30.4.

2. Downgrade immediately. Safe versions are 1.14.0 and 0.30.3. Pin them in your package-lock.json.

3. Rotate secrets. If either poisoned version was installed — even briefly — treat every credential, API key, and token accessible from that machine as compromised. The RAT had full system access.

4. Scan for IOCs. Look for outbound connections to sfrclak.com in your network logs. Check for unexpected files in /Library/Caches/ (macOS), %PROGRAMDATA%\wt.exe (Windows), or suspicious binaries in Linux home directories.

5. Lock down your dependency pipeline. If you’re still running npm install in production without a lockfile or integrity checks, today’s the day to fix that. Use npm ci instead of npm install for deployments. Enable npm’s provenance attestations where available.

6. Talk to your clients. If you manage development teams or SaaS infrastructure, this is a proactive outreach moment. The security advisory conversation builds trust. Waiting for them to find out from Twitter does the opposite.

The Bigger Picture

npm’s security model still relies heavily on individual maintainer account security. One compromised password or stolen access token, and an attacker can push malicious code to millions of machines within minutes. The Snyk analysis calls this a “now-familiar pattern” — compromise a maintainer, publish a poisoned version, rely on the ecosystem’s implicit trust.

That’s the real problem. Not this specific attack. The architecture that makes it possible.

For MSPs, the takeaway is concrete: your software supply chain is an attack surface, and it belongs on the same risk register as phishing and ransomware. If you’re not auditing dependencies as part of your security practice, you’re leaving a door open that attackers are clearly willing to walk through.

Both malicious versions have been pulled from npm. The maintainer’s account has been secured. But if those versions touched any machine in your environment, the damage may already be done. Act accordingly.