Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform Remote Access Trojan

Threat Intelligence Bulletin — This article is provided for informational purposes only. It summarizes publicly reported details of a confirmed security incident. Z Cyber does not make recommendations, provide remediation guidance, or accept liability for actions taken based on this information. Organizations should consult their own security teams and legal counsel for incident-specific response.

Why Z Cyber Is Tracking This

If your organization builds software, deploys internal tools, or runs any web-facing application built on a JavaScript stack, there is a reasonable chance axios is somewhere in your dependency tree. You may not have installed it directly. One of your vendors did. One of your internal teams did. It's in your CI/CD pipeline, your developer laptops, and your staging environments.

That's what makes this incident worth understanding. This wasn't a niche package that only affects a narrow set of developers. Axios sits in the plumbing of modern web infrastructure. When a package at that scale gets compromised, even for a few hours, the blast radius touches organizations that had no idea they were exposed.

We're publishing this as part of our Threat Intelligence series because supply chain attacks are increasingly relevant to the risk conversations happening at the board and CISO level. If your organization operates under NIST CSF, SOC 2, or any framework with a supply chain risk management component, incidents like this one are exactly the kind of real-world scenario those controls are designed to address.

What Happened

On March 30, 2026, researchers at StepSecurity identified that two poisoned versions of the axios HTTP client library had been published to the npm package registry: axios@1.14.1 and axios@0.30.4.

Axios is not a small library. It processes over 100 million weekly downloads on npm and is embedded across frontend applications, backend services, and enterprise tooling worldwide. OX Security estimates the library is present in roughly 80% of cloud and code environments.

The poisoned versions were built from a compromised maintainer account and carried a hidden dependency — plain-crypto-js@4.2.1 — that had no function in the axios codebase. Its only purpose was to run a postinstall script that dropped a cross-platform remote access trojan (RAT) onto any machine that ran npm install. Both versions were pulled from the registry within approximately three hours.

Timeline of Events

The following timeline is reconstructed from npm registry metadata and analysis published by StepSecurity, Snyk, and Socket.

Timestamp (UTC)	Event
March 30, 05:57	plain-crypto-js@4.2.0 published — clean decoy version to establish registry history
March 30, 23:59	plain-crypto-js@4.2.1 published — malicious payload with postinstall hook added
March 31, 00:21	axios@1.14.1 published via compromised maintainer account
March 31, 01:00	axios@0.30.4 published via same compromised account (39 minutes later)
March 31, ~03:15	npm unpublishes both malicious axios versions
March 31, 03:25	npm initiates security hold on plain-crypto-js
March 31, 04:26	npm publishes security-holder stub, formally replacing the malicious package

How the Attack Was Executed

Multiple security firms have published independent analyses of this incident. The technical details below are synthesized from reports by StepSecurity, Aikido Security, and Snyk.

Step 1: Maintainer Account Takeover

The attacker gained control of a lead axios maintainer's npm account (jasonsaayman) and changed the registered email to an attacker-controlled address. With that access, they published releases across both the 1.x and legacy 0.x branches within a 39-minute window — ensuring coverage across the broadest possible install base.

One forensic detail that stood out to researchers: every legitimate axios 1.x release carries npm's OIDC Trusted Publisher metadata, which cryptographically ties the publish event to a GitHub Actions workflow. The malicious release had none of that attestation. It was published manually using a stolen token, completely outside the project's normal release process.

Step 2: Staging a Lookalike Package

Eighteen hours before the axios releases, the attacker published a new package called plain-crypto-js from a separate throwaway account. It was designed to pass casual inspection: the description, repository URL, and author name were all copied from the legitimate crypto-js library. A clean version (4.2.0) went up first to build a short publishing history, making the account look less suspicious to automated scanners.

Then version 4.2.1 landed with one addition: a postinstall script hook pointing to an obfuscated dropper file.

Step 3: Injecting the Dependency

The compromised axios releases listed plain-crypto-js@^4.2.1 as a runtime dependency. That single line in package.json was the entire modification. Every other file across all 86 source files was byte-for-byte identical to the clean prior release. And the package was never actually imported or called anywhere in the axios code — it existed only to trigger the postinstall hook when a developer ran npm install.

What the Payload Did

The postinstall script (setup.js) used a two-layer obfuscation scheme — an XOR cipher combined with base64 encoding — to hide its real behavior from static analysis. Once decoded, the logic was straightforward: detect the operating system, download a platform-specific second-stage payload from a command-and-control server, execute it, then clean up the evidence.

Platform	Technique	Payload Location
macOS	AppleScript dropper executed via osascript; binary disguised as Apple system cache daemon	/Library/Caches/com.apple.act.mond
Windows	VBScript launches hidden PowerShell; persistent copy of powershell.exe disguised as wt.exe	%PROGRAMDATA%\wt.exe (persistent)
Linux	Direct curl to fetch Python RAT script; executed via nohup in background	/tmp/ld.py

All three variants phoned home to the same C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73). Notably, each platform's outbound request included a different POST body formatted to look like npm registry traffic — packages.npm.org/product0 through product2 — likely as a SIEM evasion technique designed to blend in with legitimate package manager activity in network logs.

Evidence Destruction

This is the part that makes the incident particularly difficult to investigate after the fact. Once the payload launched, the dropper deleted itself, removed the malicious package.json, and swapped in a pre-staged clean manifest that reported version 4.2.0 instead of 4.2.1. A developer or incident responder inspecting node_modules after installation would see a completely normal-looking package with no visible trace of the attack.

The entire dropper was also wrapped in a silent try/catch. If the C2 server was unreachable, the script failed silently and npm install completed with exit code 0. No errors, no warnings, nothing in the terminal output.

Detection and Response

The compromise was caught early through automated monitoring. StepSecurity's Harden-Runner agent — which is deployed across more than 12,000 public GitHub repositories — flagged unexpected outbound network connections to the C2 domain during routine CI runs in several open-source projects. One of those projects was Backstage, a widely used developer portal framework. (The Backstage team confirmed the malicious install was sandboxed and did not impact their project.)

The response was coordinated and fast. GitHub suspended the compromised maintainer account. npm pulled both poisoned axios versions and placed a security hold on plain-crypto-js. The open-source community organized real-time triage in GitHub Issue #10604. From initial detection to full remediation, the malicious packages were available for roughly three hours.

Three hours is not a long time. But for a package with 100 million weekly downloads and presence in an estimated 80% of cloud environments, three hours is enough.

Published Indicators of Compromise

The following IOCs have been published by multiple security research organizations:

Malicious npm Packages

• axios@1.14.1 — shasum: 2553649f232204966871cea80a5d0d6adc700caa
• axios@0.30.4 — shasum: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• plain-crypto-js@4.2.1 — shasum: 07d889e2dadce6f3910dcbc253317d28ca61c766

Network Indicators

• C2 Domain: sfrclak[.]com
• C2 IP: 142.11.206.73
• C2 URL: http://sfrclak[.]com:8000/6202033

File System Indicators

• macOS: /Library/Caches/com.apple.act.mond
• Windows (persistent): %PROGRAMDATA%\wt.exe
• Windows (temp): %TEMP%\6202033.vbs, %TEMP%\6202033.ps1
• Linux: /tmp/ld.py

Safe Version Reference

• axios@1.14.0 — shasum: 7c29f4cf2ea91ef05018d5aa5399bf23ed3120eb
• axios@0.30.3

What This Signals About the Threat Landscape

Supply chain compromises against open-source package registries are not new. But the operational maturity of this particular attack is worth noting. Account hijacking, pre-staged decoy packages with manufactured publishing history, multi-platform payloads, and self-destructing evidence — this is not a script kiddie dropping a cryptominer into a typosquatted package. This is planned, patient, and precise.

Several independent research teams — including Snyk, Socket, and Aikido Security — have published independent analyses arriving at the same conclusion: the absence of cryptocurrency miners, ransomware, or any financially motivated payload points toward espionage or advanced persistent threat (APT) activity.

Why This Matters for Security Programs

If you're a CISO, a security program owner, or a board member receiving cybersecurity briefings, this incident illustrates something that governance frameworks have been warning about for years: your software supply chain is an attack surface, and the risk doesn't live in your own code.

Under NIST CSF 2.0, supply chain risk management falls squarely within the Govern and Identify functions. SOC 2 addresses it through vendor management and change management criteria. CMMC Level 2 has explicit requirements around controlled unclassified information flowing through software dependencies. The frameworks already account for this kind of threat. The question is whether your organization's controls are operationalized to the point where an incident like this one would actually be caught, contained, and reported through your existing processes.

That's not a question we're answering here. But it's the right question to be asking internally.

---

References

1. StepSecurity. “axios Compromised on npm — Malicious Versions Drop Remote Access Trojan.” March 30, 2026. stepsecurity.io
2. The Hacker News. “Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account.” March 2026. thehackernews.com
3. Snyk. “Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform RAT.” March 2026. snyk.io
4. Socket. “Supply Chain Attack on Axios Pulls Malicious Dependency.” March 2026. socket.dev
5. OX Security. “Axios Compromised by Malicious NPM Dependency.” March 2026. ox.security
6. Aikido Security. “axios compromised on npm: maintainer account hijacked, RAT deployed.” March 2026. aikido.dev
7. Help Net Security. “Axios npm packages backdoored in supply chain attack.” March 31, 2026. helpnetsecurity.com
8. iTnews. “Supply chain attack hits 300 million-download Axios npm package.” March 2026. itnews.com.au
9. GitHub. “axios@1.14.1 and axios@0.30.4 are compromised — Issue #10604.” github.com/axios/axios

This article is provided for informational and educational purposes only. Z Cyber reports on publicly available threat intelligence and does not provide legal, remediation, or incident response advice through these bulletins. Organizations should conduct their own analysis and consult qualified professionals for incident-specific guidance.