Axios npm Supply Chain Attack: Cross-Platform RAT Delivery via Compromised Maintainer Credentials

On March 31, 2026, automated malware detection systems flagged a live supply chain compromise targeting Axios, the JavaScript ecosystem's most widely adopted HTTP client library with approximately 83 million weekly downloads on npm. The attack injected a cross-platform remote access trojan (RAT) dropper through a malicious transitive dependency, plain-crypto-js@4.2.1, into two newly published Axios versions.

This analysis breaks down the compromise, the full attack lifecycle, affected components, and the incident response actions security teams must take immediately.

Nature of the Compromise: Credential Takeover and npm Registry Abuse

This is not a code vulnerability in the Axios source, no CVE applies here, and no flaw in Axios's logic was exploited. Instead, the attack targets a systemic weakness in the npm package ecosystem: the trust boundary between a package maintainer's credentials and the registry's publish pipeline.

The attacker compromised the npm account of jasonsaayman, the primary Axios maintainer, likely by obtaining a long-lived classic npm access token.

Once the attacker possessed this token, they had unrestricted npm publish capability for any package under that account, entirely bypassing the project's GitHub Actions CI/CD pipeline, branch protections, code review gates, and tagged release workflows.

The attacker further solidified control by changing the registered email address on the jasonsaayman npm account to a Proton Mail address (ifstap@proton.me) under their control. This is a textbook credential takeover maneuver: it locks the legitimate maintainer out of account recovery flows while giving the attacker full ownership over future verification and 2FA reset paths.

The critical takeaway for security architects is that the npm registry treats a valid token as the sole authentication boundary for publishing.

If that token is compromised, no amount of upstream CI/CD hardening, signed commits, branch protection rules, required reviews, can prevent a malicious publish.

Attack Lifecycle: From Dependency Staging to Self-Destructing RAT Deployment

The attack was executed with operational discipline across a precise 19-hour timeline. Each phase was designed to minimize detection windows and maximize infection spread before automated scanners could react.

Figure 1. Axios npm Supply Chain Attack full Cycle Explained

Phase 1 — Dependency Staging (T-18 hours)

On March 30, 2026, at 05:57 UTC, the attacker published a clean version of the package plain-crypto-js@4.2.0 to the npm registry under the account nrwise (email: nrwise@proton.me).

Eighteen hours later, at 23:59 UTC, the attacker published plain-crypto-js@4.2.1, injecting the actual malicious payload into the postinstall hook defined in its package.json.

The staging gap was deliberate:

• it ensured the package name was already indexed and cached across npm mirrors and CDN layers before the weaponized version replaced it.

Phase 2 — Axios Dependency Injection (T+0)

The sole modification to Axios in both compromised versions (1.14.1 and 0.30.4) was a single line added to package.json under the dependencies field:

This is the critical detail visible in the attack flow diagram: Axios's legitimate dependency tree (follow-redirects, form-data, proxy-from-env) was augmented with one additional entry.

No application logic, no source files, no test suites were modified. The change was intentionally minimal to evade diff-based review tooling and automated code scanning that flags logic changes.

When any downstream consumer ran npm install and resolved axios@1.14.1 or axios@0.30.4, npm's dependency resolution engine automatically fetched and installed plain-crypto-js@4.2.1 as a transitive dependency.

Phase 3 — Dropper Execution and OS-Specific RAT Delivery

Upon installation, plain-crypto-js@4.2.1's postinstall hook triggered node setup.js, an obfuscated Node.js dropper script.

The dropper performed runtime OS detection and branched into one of three platform-specific attack paths, each contacting the same command-and-control server at sfrclak[.]com:8000:

macOS path

The dropper executed an AppleScript payload that fetched a compiled trojan binary from the C2 server, saved it to /Library/Caches/com.apple.act.mond (mimicking an Apple system daemon naming convention), set executable permissions, and launched it in the background via /bin/zsh. The AppleScript file was deleted immediately after execution.

Windows path

The dropper located the PowerShell binary, copied it to %PROGRAMDATA%\wt.exe (disguised as the Windows Terminal application), wrote a Visual Basic Script to the temp directory, and executed it. The VBScript contacted the C2 server to retrieve a PowerShell-based RAT script, executed it in memory, and deleted the downloaded artifacts.

Linux path

The dropper used Node.js's execSync to fetch a Python-based RAT script from the C2, saved it to /tmp/ld.py, and launched it in the background using nohup for process persistence beyond the terminal session.

Each platform sent a distinct POST body identifier to the C2 endpoint (/product0 for macOS, /product1 for Windows, /product2 for Linux), enabling the server to deliver platform-appropriate second-stage payloads from a single unified endpoint.

Phase 4 — Forensic Self-Destruction

After the RAT payload was deployed, the dropper executed three cleanup operations to erase evidence of the infection chain:

• it deleted the setup.js postinstall script from the installed package directory,
• removed the package.json that referenced the postinstall hook, and
• renamed a bundled file package.md, a pre-staged clean manifest without the postinstall reference, to package.json.

After this swap, a post-incident inspection of node_modules/plain-crypto-js/ would show a clean, innocuous-looking package with no trace of the dropper mechanism.

The second-stage macOS RAT, a compiled C++ binary, fingerprinted the infected system and beaconed to the C2 server every 60 seconds to retrieve commands. Its capabilities included executing shell commands, enumerating the filesystem, running additional payloads, and self-terminating on command.

Affected Versions and Packages for Axios npm Supply Chain Attack

Safe versions to pin: axios@1.14.0 (1.x branch) and axios@0.30.3 (0.x branch). The compromised versions and plain-crypto-js have been removed from the npm registry.

Immediate Incident Response Actions for the Axios npm Supply Chain Attack

Step 1: Detect exposure

Audit lockfiles (package-lock.json, yarn.lock, pnpm-lock.yaml) across all repositories and CI/CD build artifacts for references to axios@1.14.1, axios@0.30.4, or plain-crypto-js.

Run npm ls plain-crypto-js in every project to check transitive resolution.

2. Check for RAT artifacts on build hosts and developer machines

Look for /Library/Caches/com.apple.act.mond on macOS, %PROGRAMDATA%\wt.exe on Windows, and /tmp/ld.py on Linux. The presence of any of these files indicates active compromise.

3. Downgrade and pin

Roll back to axios@1.14.0 or axios@0.30.3. Remove plain-crypto-js from node_modules. Regenerate lockfiles from a clean state.

4. Rotate all secrets

If any compromised version was installed in any environment (development, staging, CI/CD, production) treat it as a full compromise. Rotate npm tokens, API keys, cloud provider credentials, database passwords, and any secrets accessible from the infected host.

5. Block C2 egress

Add sfrclak[.]com to DNS blocklists and egress firewall deny rules across all network segments.

6. Audit CI/CD pipeline runs

Review build logs for any pipeline execution that resolved the affected versions. Container images built during the compromise window should be rebuilt from clean dependencies.

7. Harden npm token hygiene

Migrate from classic npm tokens to granular access tokens with IP allowlisting, expiration enforcement, and CIDR-scoped publish permissions. Enable npm's publish provenance feature to cryptographically link published packages to their source repository and build workflow.

This incident underscores a structural reality of modern software supply chains: a single compromised credential can weaponize an entire dependency graph affecting millions of downstream applications, with no modification to the target library's source code required.

How Picus Helps Simulate Axios Supply Chain Attacks?

We strongly recommend simulating npm supply chain attacks like the Axios compromise to evaluate how effectively your security controls detect malicious dependency injection, postinstall script abuse, and cross-platform RAT delivery.

With the Picus Security Validation Platform, you can safely emulate credential-compromise-driven attacks, transitive dependency poisoning, and C2-based payload execution across development and CI/CD environments. You can also validate your defenses against similar malware and supply chain threats within minutes with a 14-day free trial of the Picus Platform.

Picus Threat Library includes the following threats for npm supply chain attacks like the Axios.

Start simulating emerging threats today and get actionable mitigation insights with a  14-day free trial  of the Picus Security Validation Platform.