Axios npm Package Compromised: Supply Chain Attack…

Key Takeaways

Two malicious Axios versions (1.14.1 and 0.30.4) were published to npm on March 31, 2026, via a compromised maintainer account
The attack injected a hidden dependency (plain-crypto-js) that deployed a cross-platform RAT targeting macOS, Windows, and Linux
The malicious versions were live for approximately 3 hours before being removed
Lockfile enforcement and postinstall script auditing would have prevented this attack
Any system that ran npm install during the window should assume full compromise

What Happened

On March 31, 2026, attackers published two malicious versions of Axios — one of the most widely used JavaScript HTTP client libraries with over 300 million weekly downloads — to the npm registry. The compromised versions, 1.14.1 and 0.30.4, contained a hidden malicious dependency called plain-crypto-js@4.2.1 that automatically deployed a Remote Access Trojan (RAT) on any machine that ran npm install during the attack window.

This was not a typosquatting attack or a rogue dependency. The attacker gained direct publishing access to the official Axios package by compromising the npm account of maintainer @jasonsaayman. Both the npm and GitHub accounts were taken over, with the attacker even changing the account email to a Proton Mail address and deleting GitHub issues that reported the compromise.

How the Attack Worked

The attack was methodical and well-staged, unfolding over approximately 24 hours:

Stage 1: Pre-Staging the Malicious Dependency

On March 30, the attacker-controlled npm account nrwise published a "clean" version of plain-crypto-js (v4.2.0) to establish a brief history on the registry. Eighteen hours later, the weaponized version 4.2.1 was published containing the actual payload.

Stage 2: Publishing Compromised Axios Versions

Using the hijacked maintainer credentials, the attacker published axios@1.14.1 at 00:21 UTC and axios@0.30.4 at 01:00 UTC. Unlike legitimate Axios releases which are published via GitHub Actions with OIDC provenance signing, these were published directly via the npm CLI — producing no provenance attestation. This discrepancy is a critical detection signal.

Stage 3: The Dropper

When npm resolved the dependency tree and installed plain-crypto-js@4.2.1, a postinstall hook automatically executed setup.js. This dropper used double-layer obfuscation — reversed Base64 encoding with padding substitution, followed by XOR encryption with the key OrDeR_7077 and constant 333 — to evade static analysis.

Once deobfuscated, the script detected the host operating system and contacted the C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73) to download a platform-specific second-stage payload.

Stage 4: Anti-Forensic Self-Deletion

After execution, the malware erased its own tracks: deleting setup.js, removing the package.json containing the postinstall hook, and replacing it with a clean version. Post-incident inspection of node_modules/plain-crypto-js would show no obvious signs of the postinstall script.

Platform-Specific RAT Payloads

The second-stage payloads were purpose-built for each major operating system:

macOS

An AppleScript downloaded a binary to /Library/Caches/com.apple.act.mond, deliberately spoofing an Apple background daemon name. The RAT generated a unique victim ID, fingerprinted the system (hostname, username, macOS version, CPU architecture), and beaconed to the C2 every 60 seconds. It accepted commands for binary injection with ad-hoc code signing to bypass Gatekeeper, arbitrary shell command execution, filesystem enumeration, and self-termination.

Windows

A VBScript downloader copied the PowerShell binary to %PROGRAMDATA%\wt.exe (masquerading as Windows Terminal) and executed a hidden PowerShell RAT with execution policy bypass. Persistence was achieved through a registry Run key named "MicrosoftUpdate."

Linux

A Python RAT was downloaded to /tmp/ld.py and launched as an orphaned background process via nohup python3, detaching from the terminal session.

Who Was at Risk

The three-hour publication window (00:21 to 03:29 UTC on March 31) is the key constraint. The highest risk groups were:

CI/CD pipelines that don't pin dependency versions and run npm install on a schedule — especially those running overnight or early morning UTC
Developers who ran npm install or npm update during the window and pulled the affected versions
Projects depending on secondary compromised packages like @qqbrowser/openclaw-qbot or @shadanai/openclaw, which also shipped the malicious plain-crypto-js

If your lockfile was committed before the malicious versions were published and your install did not update it, you were not affected. Lockfiles are your first line of defense.

Indicators of Compromise (IOCs)

If you believe a machine ran npm install during the affected window, check for these indicators:

macOS: /Library/Caches/com.apple.act.mond binary
Windows: %PROGRAMDATA%\wt.exe (PowerShell masquerading as Windows Terminal)
Linux: /tmp/ld.py Python script
Network: Outbound connections to sfrclak[.]com or 142.11.206.73:8000

Immediate Remediation Steps

If You Are Not Affected (Precautionary)

Pin Axios to a known safe version — any version other than 1.14.1 or 0.30.4 is clean
Commit your lockfile and ensure CI uses npm ci (not npm install) to enforce lockfile integrity
Add plain-crypto-js to a blocklist in your package manager or security tooling
Consider enabling --ignore-scripts for npm installs in CI environments

If You Are Affected (Assume Breach)

Contain immediately: Isolate any systems that ran npm install during the affected window
Rotate all secrets: Treat every credential on the affected machine as compromised — API keys, SSH keys, cloud credentials, npm tokens, GitHub tokens. Revoke and reissue; do not rotate in place
Review for lateral movement: Check logs for outbound connections to sfrclak[.]com or 142.11.206.73
Rebuild environments: Do not attempt to clean compromised systems. Rebuild from a known-clean snapshot or base image
Audit CI pipelines: Review build logs for the March 31, 2026 UTC window

Lessons for Supply Chain Security

This incident follows a growing pattern of maintainer account compromise attacks against high-profile npm packages. What makes the Axios attack significant is the combination of massive blast radius (300M+ weekly downloads), operational sophistication (pre-staged dependencies, double obfuscation, anti-forensic cleanup), and cross-platform targeting.

Key defensive controls that would have caught or prevented this attack:

Lockfile enforcement: Using npm ci instead of npm install in CI/CD
Postinstall script auditing: Monitoring and restricting lifecycle script execution
Provenance verification: Checking that packages are published via trusted CI/CD pipelines with OIDC attestation
Runtime monitoring: Detecting unexpected process spawns or outbound network connections from build environments
Dependency scanning: Continuous monitoring with tools like Snyk, Socket, or Semgrep Supply Chain

Organizations that depend on open source at scale should treat supply chain security as a critical infrastructure concern — not an afterthought. The window between compromise and detection is shrinking thanks to automated scanning, but three hours is still more than enough time for a well-crafted attack to cause significant damage.

How FYEO Can Help

At FYEO, our security audit services include comprehensive dependency analysis and supply chain risk assessment. Our team can help you implement robust defenses against supply chain attacks, including automated dependency scanning, lockfile integrity enforcement, and continuous monitoring of your software supply chain. Contact us to learn how we can strengthen your organization's security posture.

Axios npm Package Compromised: Supply Chain Attack Deploys Cross-Platform RAT