The Axios Supply Chain Cascade
A coordinated supply chain attack delivered a cross-platform RAT via the most widely used JavaScript HTTP client, compromising developer workstations and CI/CD pipelines within minutes.
01 Executive Summary
On March 30, 2026, Elastic Security Labs detected a supply chain compromise targeting the
axios npm package through automated supply-chain monitoring. The attacker had compromised a
maintainer account and, between March 30–31, staged and published backdoored releases that
delivered a cross-platform Remote Access Trojan (RAT). With over 100 million weekly downloads across
both targeted release branches, the blast radius was significant. Elastic filed a GitHub Security
Advisory on March 31, 2026 at 01:50 AM UTC, coordinating disclosure with the maintainers and npm
registry.
The Incident in Brief
On March 30, 2026, the attacker staged a malicious package (plain-crypto-js) on npm to
build registry history. Then, between March 31 00:21 and 01:00 UTC, the compromised
jasonsaayman npm maintainer account was used to publish two backdoored releases:
[email protected] (tagged latest) and [email protected] (tagged
legacy). These versions introduced [email protected] as a phantom
dependency — a purpose-built package whose sole function was to execute a postinstall script
that silently downloads and runs platform-specific RAT implants (designated WAVESHAPER.V2 by Google
Threat Intelligence). The maintainer confirmed in GitHub Issue #10604 that access was gained via a
social engineering attack where a group masqueraded as open-source collaborators. Elastic Security
Labs detected the compromise through automated monitoring and filed a GitHub Security Advisory at
01:50 UTC. The malicious packages were removed approximately three hours after publication, but any
system that ran npm install during the window and resolved to either compromised
version may have been fully compromised.
02 Anatomy of the Attack
The attack was pre-staged across roughly 18 hours, with the malicious dependency seeded on npm before the axios releases to avoid "brand-new package" alarms. Elastic Security Labs detected the compromise on March 30 through automated monitoring — before the backdoored axios versions were even published. Both release branches were then hit within a 39-minute window on March 31, maximizing exposure across projects using either the current or legacy axios API.
03 Blast Radius & Impact
Despite the relatively short exposure window (~3 hours), the impact was significant due to Axios's
position as a foundational dependency. The compromised versions were tagged as latest and
legacy, meaning fresh npm install commands across both release branches resolved
to malicious code automatically.
The attack was timed to publish just after midnight UTC on a Sunday night, maximizing the gap before maintainers and npm security could respond.
Attack Kill Chain
How the payload propagated from npm install to RAT execution
Platform-Specific RAT Delivery
WAVESHAPER.V2 deployed native implants per OS
04 Remediation Protocol
Any system that installed
[email protected] or [email protected] during the exposure window should be treated
as fully compromised.
🔍 Step 1: Audit Dependencies Immediately
Search your
package-lock.json, yarn.lock, or
pnpm-lock.yaml for the compromised versions. Also check for the presence of
plain-crypto-js in your node_modules. Note: the malware
self-cleans its traces from the installed package manifest, so absence of evidence in
node_modules does not mean you were not affected.
# Check if compromised versions are installed
npm ls axios
# Downgrade to known safe versions
npm install [email protected] --save-exact
# OR for legacy branch:
npm install [email protected] --save-exact
# Remove the malicious dependency
rm -rf node_modules/plain-crypto-js
# Clean npm cache
npm cache clean --forceAlso block egress traffic to the
C2 domain: sfrclak[.]com (port 8000).
05 Systemic Implications
The Axios compromise is among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package. It exposes structural weaknesses in how the JavaScript ecosystem handles trust, dependency resolution, and maintainer account security.
The "Phantom Dependency" Pattern
Rather than embedding malicious code directly in axios, the attackers introduced a seemingly
innocuous new dependency (plain-crypto-js) that was never imported anywhere in the
axios source. Its sole purpose was to exploit npm's postinstall lifecycle hook.
This pattern is particularly dangerous because auditing the axios source code itself reveals
nothing — the malice lives entirely in the dependency graph. The malware also self-cleans
after execution, leaving no traces in the installed package manifest.
OIDC Was Configured. It Didn't Matter.
The axios project had adopted modern security practices. Legitimate 1.x releases (including
[email protected]) were published via GitHub Actions OIDC with SLSA provenance
attestations. But the CI pipeline also passed a legacy NPM_TOKEN as an environment
variable alongside the OIDC credentials. When both are present, npm silently defaults to the
token. The attacker never needed to defeat OIDC — they walked around it using the stolen
token to publish directly via CLI.
The maintainer confirmed in GitHub Issue #10604 that the compromise originated from a social engineering attack where a group masqueraded as open-source collaborators. Once the attacker had full access to the maintainer's machine, no per-account controls could have stopped publication.
The forensic lesson is clear: the absence of SLSA provenance on [email protected]
— when every prior 1.x release carried it — was the single most reliable detection
signal. Any tooling that enforced provenance verification would have blocked this attack at
install time.
Automated Dependency Resolution Amplifies Risk
Because the compromised versions were tagged as both latest and legacy, every
fresh npm install during the window automatically resolved to the backdoored
release. Automated dependency bots (Dependabot, Renovate), CI/CD pipelines, and AI-assisted
development tools that pull latest versions would have amplified propagation, potentially
introducing the RAT into codebases before any human review could intervene. Strict version
pinning (--save-exact) and lockfile-based installs (npm ci) remain
essential defenses.
Redefining Trust in Open Source Infrastructure
This incident reinforces that "Infrastructure Assurance" must evolve beyond static analysis and lockfile audits. Organizations need runtime monitoring of package installation behavior, egress filtering during build processes, mandatory SLSA provenance verification, and the ability to rapidly detect when a trusted package begins making unexpected network connections. The npm ecosystem's reliance on postinstall hooks as an execution vector remains a systemic vulnerability.