The Axios Supply Chain Attack: What Every Engineering Team Needs to Know

On March 31, 2026, two malicious versions of Axios — the most popular JavaScript HTTP client library with over 300 million weekly downloads — were published to npm. For approximately three hours, anyone who ran npm install axios received a backdoored package that deployed a cross-platform Remote Access Trojan (RAT) targeting macOS, Windows, and Linux systems simultaneously.

The attacker compromised the npm account of Axios's primary maintainer @jasonsaayman, changed the account email to an attacker-controlled Proton Mail address, and published directly via npm CLI — completely bypassing the normal GitHub Actions CI/CD publishing workflow. The malicious versions do not appear in the project's official GitHub tags. They were published manually, outside the project's legitimate infrastructure.

This wasn't a theoretical vulnerability. This was active, weaponized malware delivery through one of the most trusted packages in the JavaScript ecosystem.

---

Timeline of the Attack

---

What the Malicious Code Did

The attack was sophisticated and multi-staged. Here's the technical breakdown:

Stage 1: Dependency Injection

Rather than modifying Axios source code directly, the attacker added a single malicious dependency to package.json: plain-crypto-js@^4.2.1 — a package never imported anywhere in Axios source code. A binary comparison between legitimate and malicious Axios versions revealed exactly one file changed: package.json.

The plain-crypto-js package was purpose-built for this attack. Version 4.2.0 (clean) was published 18 hours prior to establish a brief registry history and avoid suspicion. The attacker published across two major version lines (1.x and 0.x) to maximize the number of projects that would automatically pull the compromised release via caret ranges (^1.14.0 or ^0.30.0).

Stage 2: Postinstall Dropper Execution

When developers ran npm install axios@1.14.1, npm resolved plain-crypto-js@4.2.1 and automatically executed its postinstall hook: node setup.js. The dropper used a double-obfuscation strategy:

This obscured malicious strings including module names, C2 URLs, and system commands. The deobfuscated script detected the host OS via os.platform() and contacted the C2 server to download platform-specific second-stage payloads.

Stage 3: Platform-Specific RAT Deployment

The C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73) delivered tailored payloads for each operating system:

The macOS RAT supported four commands: peinject (downloads Base64-encoded binaries, performs ad-hoc code signing via codesign --force --deep --sign to bypass Gatekeeper), runscript (executes shell commands via /bin/sh or AppleScript via osascript), rundir (enumerates filesystem metadata from /Applications, ~/Library, ~/Application Support), and kill (terminates RAT process).

Stage 4: Anti-Forensic Self-Destruction

After launching payloads, the dropper performed three cleanup steps:

1. Deleted setup.js (the malicious postinstall script)
2. Deleted the malicious package.json containing the postinstall hook
3. Renamed a pre-staged package.md (containing clean v4.2.0 metadata) to package.json

Result: After cleanup, node_modules/plain-crypto-js/ appeared to be a normal copy of crypto-js with no trace of malicious code. The version mismatch intentionally caused npm list to report 4.2.0 instead of the actual malicious 4.2.1.

---

Why This Matters for Engineering Teams

Axios is foundational infrastructure for JavaScript applications. It is the de facto standard for:

• HTTP requests — the default client in millions of Node.js backends, React frontends, and full-stack applications
• API communication — handling authentication headers, tokens, and credential passing between services
• CI/CD pipelines — running automatically on every npm install across build environments worldwide
• Cloud environments — present in approximately 80% of cloud and code environments

This means Axios installations typically have access to every secret, token, and credential in the build or runtime environment. A compromised Axios package exposes:

• Cloud provider API keys (AWS, GCP, Azure)
• npm tokens and GitHub tokens
• SSH keys and service account credentials
• Environment variables containing database passwords and secrets

The blast radius of this single package compromise is enormous precisely because Axios is embedded at every layer of the JavaScript ecosystem.

---

Axios's History of Security Issues

The March 2026 supply chain attack was the most severe incident, but Axios has had a pattern of security vulnerabilities over the past three years:

The pattern reveals a consistent theme: insufficient validation on parameters that control request routing and configuration merging — exactly the type of vulnerability class that requires deep security testing to catch.

---

How Nebula Detects These Vulnerability Classes

At Breachline, we built Nebula specifically to find the types of vulnerabilities that existed in Axios long before the supply chain attack — and the types of post-compromise indicators that follow one.

Supply Chain Analysis

Nebula's supply_chain_scan capability analyzes dependency trees for:

• Known vulnerable versions — cross-referencing against CVE databases and advisory feeds in real-time
• Phantom dependency detection — identifying packages in manifests that are never imported in source code (exactly the pattern used in this attack)
• Typosquatting detection — identifying packages with names similar to legitimate dependencies (like plain-crypto-js mimicking crypto-js)
• Version pinning audit — flagging unpinned dependencies vulnerable to substitution attacks via caret or tilde ranges

SSRF Detection

The Axios SSRF vulnerabilities (CVE-2024-39338, CVE-2025-27152) allowed attackers to make server-side requests to arbitrary domains through URL manipulation. When Nebula encounters an API endpoint that accepts URL parameters, it systematically tests:

• Internal network access (http://127.0.0.1, http://169.254.169.254)
• Cloud metadata endpoints (AWS IMDSv1/v2, GCP, Azure)
• Protocol smuggling (file://, gopher://)
• DNS rebinding scenarios

In our recent benchmark testing, Nebula successfully identified and exploited SSRF vulnerabilities across 3 different challenge scenarios — including SSRF via request routing and SSRF via URL parameter manipulation.

Authentication & Token Leakage

The XSRF token leak (CVE-2023-45857) and prototype pollution (CVE-2026-25639) represent broken security controls in HTTP client configuration. Nebula tests for:

• Token and credential exposure in cross-origin requests
• Configuration injection via prototype pollution vectors
• Authentication bypass via header manipulation
• Sensitive data leakage in error responses and logs

---

Protecting Your Infrastructure

Immediate Actions (If You Use Axios)

If your organization ran npm install between March 31 00:21 UTC and 03:29 UTC:

1. Treat the system as fully compromised — removing the package alone is not sufficient due to the anti-forensic self-deletion
2. Rotate all credentials — API keys, SSH keys, cloud credentials, npm tokens, GitHub tokens, database passwords
3. Check for persistence — look for /Library/Caches/com.apple.act.mond (macOS), %PROGRAMDATA%\wt.exe (Windows), /tmp/ld.py (Linux)
4. Audit CI/CD pipelines — review March 31 UTC build logs to identify which pipelines installed affected versions
5. Monitor for C2 traffic — watch for outbound connections to sfrclak[.]com and 142.11.206.73:8000

Long-Term Recommendations

---

The Bigger Picture

The Axios incident illustrates a fundamental challenge in software supply chain security: the packages we trust implicitly are themselves attack surfaces.

Axios had 4 known CVEs in the three years prior — SSRF, prototype pollution, token leakage. Each of these was a window of opportunity for attackers. The March 2026 supply chain attack simply demonstrated what happens when the ecosystem's implicit trust model is exploited at scale.

The organizations that weathered this incident best were those running:

• Pinned dependencies with committed lockfiles
• npm ci --ignore-scripts in CI/CD environments
• Continuous security testing that would have caught the SSRF and configuration vulnerabilities before they became entrypoints

The question isn't whether your software supply chain will be targeted. It's whether you'll detect it in 6 minutes — or 6 months.

---

Breachline Nebula provides continuous, autonomous security testing for web applications and AI infrastructure. Learn more at breachline.io.

Source: Snyk Security Research — Axios npm Package Compromised in Supply Chain Attack