Axios npm compromise: Supply-chain attack distributed cross-platform RAT

Key takeaways

• For a few hours on March 31, 2026, attackers hijacked the maintainer account for the widely-used Axios library on npm and used it to distribute the poisoned versions 1.14.1 and 0.30.4 that installed a remote access trojan (RAT).
• Rapid disclosure followed by prompt action by other project contributors allowed npm support to take down the malicious versions within a few hours.
• The malicious versions added a hidden runtime dependency that installed an advanced RAT on the local machine via a post-install script.
• The Axios HTTP client library is one of the most popular npm packages, with over 100 million weekly downloads, so the potential blast radius was immense.
• The window for active compromise was less than three hours, but anyone building JavaScript applications that could depend on Axios should check for indicators of compromise.
• The incident is just one of a series of supply-chain attacks on npm in recent months and highlights the security risks of highly automated development pipelines.

Axios quick check: Are you affected?

If you maintain or build any JavaScript project that uses Axios, this section is for you. The malicious versions were only live on npm for approximately three hours, but the nature of the attack – a self-deleting payload that replaces its own evidence with clean files – means you cannot rely on a simple inspection of your node_modules directory.

Step 1: Check your lock files for the malicious versions

Search your installed packages and lock file for the two compromised version numbers: axios@1.14.1 and axios@0.30.4.

Step 2: Check for the dummy dependency

The malicious versions added plain-crypto-js as a runtime dependency – a package that has never appeared in any legitimate Axios release and is only used to trigger a post-install script. If the plain-crypto-js directory exists in your node_modules, it means the dropper has likely executed in your system and you should assume compromise, even if the contents now look clean.

Step 3: Check for malware installation artifacts

The dropper installs platform-specific malware. Check for the presence of the following files:

• macOS: /Library/Caches/com.apple.act.mond
• Linux: /tmp/ld.py
• Windows: %PROGRAMDATA%\wt.exe

Step 4: Audit CI/CD Pipelines

Review build logs for any npm install runs in the early hours of March 31, 2026. Any pipeline that pulled either malicious version during this window should be treated as compromised, and all secrets available to that environment should be rotated immediately.

Remediation

If any of the above checks returns positive results, you should assume compromise. The recommended course of action is as follows:

1. Pin to safe versions. Downgrade to axios@1.14.0 or axios@0.30.3 (as applicable). Add overrides and resolutions entries to your package.json to prevent transitive resolution pulling in the malicious versions.
2. Remove the malicious dependency. Delete node_modules/plain-crypto-js and reinstall with npm install --ignore-scripts.
3. If any malware artifacts are found, do not attempt to clean in place. Treat the system as fully compromised. Rebuild from a known-good state or image and rotate all credentials that were accessible on that machine. This includes npm tokens, cloud API keys, SSH private keys, CI/CD secrets, and any values in .env files.
4. Block command & control (C2) traffic. Add sfrclak.com and 142.11.206.73 to your network deny lists as a precaution.

What happened: The Axios npm compromise and response timeline

In the early hours of March 31, 2026, an attacker compromised and hijacked the npm account of jasonsaayman, the primary maintainer of the Axios project. It’s not clear how exactly this was achieved. The attacker then used the hijacked credentials to publish two malicious versions of the library directly to the npm registry to cover the main and legacy branches: axios@1.14.1 around 00:21 UTC and axios@0.30.4 around 01:00 UTC.

While legitimate Axios releases were always published via GitHub Actions using npm’s OIDC Trusted Publisher mechanism, the malicious versions were published manually with a stolen npm access token. This provided a critical forensic signal and one of the clearest indicators that these were not legitimate releases.

The rapid response that followed deserves credit. Community member Ashish Kurmi filed GitHub issue #10604 to alert the ecosystem, and the coordinated effort between Axios contributors, GitHub, and npm support kept the window of exposure as short as possible.

By 03:15 UTC, npm had unpublished both malicious versions and reverted the latest dist-tag to the safe 1.14.0. A security hold was placed on plain-crypto-js shortly after, and by 04:26 UTC npm had replaced it with a security-holder stub. The total exposure window was approximately 2 hours and 53 minutes for axios@1.14.1 and 2 hours and 15 minutes for axios@0.30.4.

Attack steps and components

The attack was methodically prepared ahead of time. Approximately 18 hours before the tampered Axios versions were published, the attacker (operating under the npm account nrwise, registered to nrwise@proton.me) published plain-crypto-js@4.2.0 – a clean, non-malicious package that was essentially a verbatim copy of the legitimate crypto-js library. This was a decoy with the sole purpose of establishing publishing history to avoid triggering security scanner alarms about a brand-new package.

Just before midnight UTC on March 30, the malicious plain-crypto-js@4.2.1 was published. This version was almost identical to 4.2.0, with just three differences: a postinstall hook added to package.json, a new script called setup.js, and a file named package.md containing a clean JSON stub for post-install cleanup.

The injection

The only change the attacker made to Axios itself was adding the malicious plain-crypto-js@4.2.1 as a runtime dependency in package.json. Every other file and dependency is otherwise identical to the prior clean Axios version, and there’s no malicious code anywhere in the Axios source. Crucially, the plain-crypto-js package is never imported or required anywhere in the codebase but exists solely to trigger the postinstall hook during installation.

This phantom dependency pattern, where a package listed in the manifest but never referenced in the code, is a hallmark of modern supply-chain attacks and a high-confidence indicator of tampering.

The malware dropper

Malware installation takes place when a developer runs npm install and npm resolves the dependency tree, installs plain-crypto-js@4.2.1, and automatically executes its postinstall script: node setup.js.

The setup.js script is a single minified file that uses a two-layer obfuscation scheme. All sensitive strings, including the module names, OS identifiers, shell commands, the command and control URL, and file paths, are stored as encoded values in an array and only decoded at runtime through XOR and base64 operations. Security researchers at StepSecurity fully decoded the string table to reveal the complete attack chain.

The dropper detects the host operating system and branches into one of three platform-specific attack paths:

• macOS: Writes a temporary script file and executes it to download a compiled binary from the C2 server at sfrclak.com:8000. Saves the file to the legitimate-looking path /Library/Caches/com.apple.act.mond and launches it in the background.
• Windows: Writes a VBScript to the temp directory and uses a local copy of PowerShell stored at %PROGRAMDATA%\wt.exe to execute it in a hidden window. The VBScript fetches a PowerShell payload from the C2 server, executes it in a hidden window, and self-deletes.
• Linux and UNIX platforms: Uses curl to download a Python RAT script to /tmp/ld.py and executes it in the background.

Each platform sends a distinct POST body to the same C2 endpoint, with values designed to look like legitimate npm registry traffic in network logs (packages.npm.org/product0, product1, product2).

Self-cleanup and anti-forensics

After launching the platform payload, the dropper performs three cleanup operations: it deletes itself (setup.js), deletes the malicious package.json, and renames the pre-staged package.md to package.json. This clean stub reports version 4.2.0 to mislead incident responders who might be scanning for the known-malicious version number.

The entire function is wrapped in a try/catch block that silently swallows all errors. If the C2 is unreachable, if the user lacks permissions, or if anything else fails, npm install still completes successfully with exit code 0. The developer never sees any indication that anything went wrong.

What the RAT actually does

Analysis from Wiz, SafeDep, and OpenSourceMalware suggests that the payloads across all three platforms function as lightweight but capable remote access trojans. They beacon to the C2 server every 60 seconds, transmitting system inventory and awaiting commands. Supported capabilities may include remote shell execution, arbitrary binary injection, directory and file enumeration, process listing, and system reconnaissance.

Notably, researchers have observed no cryptocurrency mining or ransomware components in the payloads. The focus on system reconnaissance, credential harvesting, and capability for lateral movement has led some analysts to characterize this as intelligence-gathering activity rather than financially motivated cybercrime.

The potential blast radius

The speed with which this attack was detected and contained is commendable, but a sober look at the numbers shows just how thin the margin was.

Axios is, by any measure, one of the most depended-on packages in the entire JavaScript ecosystem. Download counts vary by source – npm shows approximately 83 million weekly downloads at the time of writing, while some sources report figures of 100 or even 300 million – but the precise number matters less than the order of magnitude. Wiz researchers noted that Axios is present in roughly 80% of cloud and code environments they monitor. Even within the narrow three-hour window, Wiz observed malicious execution in 3% of affected environments. At this scale, even single-digit percentages translate to very large numbers of potentially compromised systems.

Had the attacker moved more quietly, the window could have been much wider. The fact that the malicious versions lacked OIDC attestation and had no corresponding GitHub tags is what enabled fast detection. A more careful attacker might have obtained GitHub access as well, or found ways to make the publish metadata look legitimate. The ecosystem was fortunate that the forensic signals were this clear.

Another week, another supply-chain attack

The Axios compromise does not exist in isolation but lands in the middle of what has become one of the most active periods for npm supply-chain attacks on record.

In September 2025, the Shai-Hulud worm campaign infected over 500 npm packages through compromised maintainer accounts and phishing attacks, prompting a CISA advisory. A second wave in November 2025, dubbed Shai-Hulud 2.0, expanded the scope to over 600 compromised packages and introduced a destructive “dead man’s switch” mechanism. 

Just days before the Axios attack, the TeamPCP group weaponized version tags of Aqua Security’s Trivy scanner in a cascading supply chain attack that also hit Checkmarx’s VS Code extensions, LiteLLM, and Telnyx on PyPI. A further CanisterWorm campaign originating from those TeamPCP compromises spread to over 60 npm packages. The list goes on.

The common thread running through all these incidents is the exploitation of trust: in maintainer accounts, in automated pipelines, or in the dependency resolution process itself. The npm ecosystem’s fundamental operating model that made it so popular, where a single npm install can silently fetch, install, and execute arbitrary code from hundreds of transitive dependencies, is a structural security weakness that attackers have learned to weaponize.

Final thoughts: Supply-chain security in a time of AI-accelerated  development

Based on what we know so far, the Axios story seems to be one of “Phew, another close call” – but there is an extra dimension of supply-chain risk that deserves a thought here. With the rise of AI-assisted development and autonomous coding agents, it only takes one successful attack to compromise potentially millions of machines.

Modern software development workflows increasingly involve AI tools that generate, modify, and install dependencies on behalf of human developers. Some of these tools might run in semi-autonomous or fully autonomous modes, adding packages to projects, updating dependencies, and executing build steps without explicit human review of each dependency install. 

The dependency-heavy nature of JavaScript development has always meant that any npm install was a leap of faith across dozens or hundreds of packages. Until now, the implicit assumption has been that a human developer is at least nominally aware of what is being pulled in. As that assumption fades and ever more of the install-build-deploy pipeline is handed over to autonomous agents, the attack surface for supply-chain compromises like the Axios incident expands dramatically – as does the potential fallout.