Axios npm Package Compromised: Supply Chain Attack via Phantom Dependency Drops Cross-Platform RAT

Executive Summary

On March 30–31, 2026 (UTC), attackers compromised the npm account of Axios’ lead maintainer and published two poisoned releases: axios@1.14.1 and axios@0.30.4. Rather than modifying Axios’ source code directly, the attackers injected a phantom dependency — plain-crypto-js@4.2.1 — that was listed in package.json but never imported by Axios. This dependency’s postinstall script silently dropped a cross-platform Remote Access Trojan (RAT) targeting Windows, macOS, and Linux. The RAT harvested cloud credentials, database passwords, and API tokens from infected systems. The malicious releases were live for approximately 2–3 hours before being removed. Axios is one of the most widely used packages on npm with over 100 million weekly downloads — any project that pulled these versions during the exposure window should be considered compromised.

Technical Analysis

How the Account Was Compromised

According to supply chain security firm StepSecurity, the attacker first changed the registered email address on the npm account jasonsaayman (Axios’ lead maintainer, Jason Saayman) to ifstap@proton.me, locking out the legitimate owner. The attacker then used npm CLI credentials to manually publish the poisoned releases, bypassing the project’s standard GitHub Actions CI/CD pipeline and OpenID Connect (OIDC) trusted publishing.

This is a critical detail: the malicious releases were not built by Axios’ automated pipeline. They were published directly from the attacker’s machine using the hijacked npm credentials, meaning code review, CI checks, and OIDC attestation were all circumvented.

The Phantom Dependency Technique

The attack’s sophistication lies in what wasn’t changed. The Axios source files in the poisoned releases were identical to the legitimate versions. The only modification was the addition of plain-crypto-js@4.2.1 to the dependencies field in package.json.

This package was never import-ed or require()-d anywhere in Axios code — it existed solely to trigger npm’s dependency resolution. When any developer ran npm install (or yarn, pnpm, bun), the package manager resolved plain-crypto-js@4.2.1, downloaded it, and executed its postinstall script (setup.js).

The postinstall script was the actual payload dropper, installing a cross-platform RAT onto the developer’s machine. Because the malicious code never appeared in Axios’ repository or compiled artifacts, static analysis of the Axios source would not have detected the compromise.

Attack Chain

Phase Action Detail
Account Takeover npm account hijack Attacker changed jasonsaayman registered email to ifstap@proton.me, locking out the maintainer
Bypass CI/CD Manual publish via npm CLI Bypassed GitHub Actions pipeline and OIDC trusted publishing
Payload Injection Phantom dependency added plain-crypto-js@4.2.1 added to package.json dependencies
Execution postinstall script runs setup.js executes automatically during npm install
RAT Installation Cross-platform RAT deployed RAT installed with OS-appropriate persistence (scheduled tasks, launch agents, registry entries)
Credential Theft Exfiltration RAT harvested cloud access keys, database passwords, API tokens
C2 Communication Callback to attacker infrastructure Infected endpoints contacted command-and-control servers

Affected Versions

Version Status Safe Alternative
axios@1.14.1 COMPROMISED — removed from npm Revert to axios@1.14.0
axios@0.30.4 COMPROMISED — removed from npm Revert to axios@0.30.3

Exposure Window

The malicious releases were published overnight (March 30–31 UTC) and removed within approximately 2–3 hours. However, given Axios’ 100+ million weekly download volume, the number of projects that pulled these versions during that window is potentially significant. DarkReading reported that the attack may be linked to North Korean threat actors, though attribution has not been confirmed.

Impact Assessment

Who Is Affected

Any project or environment that installed axios@1.14.1 or axios@0.30.4 during the exposure window is potentially compromised. This includes:

  • Developer workstations that ran npm install with an unpinned Axios dependency
  • CI/CD pipelines that rebuilt during the window and pulled the latest version
  • Docker images built from npm install during the exposure period
  • Production deployments that use npm ci with an updated lockfile

Severity

The combination of Axios’ ubiquity (100M+ weekly downloads), the RAT’s credential-harvesting capabilities, and the cross-platform targeting makes this one of the most significant npm supply chain compromises to date. The harvested credentials could enable:

  • Lateral movement into cloud infrastructure (AWS, GCP, Azure)
  • Database access and data exfiltration
  • API abuse using stolen tokens
  • Compromise of downstream services and customers

Detection & Response

How to Detect Compromise

Indicator How to Check
Lockfile contains phantom dependency Search package-lock.json or pnpm-lock.yaml for plain-crypto-js
Postinstall script execution Check npm install logs for postinstall entries referencing plain-crypto-js
RAT persistence artifacts Look for unexpected scheduled tasks, launch agents, or registry run keys created around March 30–31
Unusual outbound connections Monitor for HTTPS connections to unfamiliar domains from Node.js processes or from the RAT binary
Credential file access Check process logs for access to ~/.aws/credentials, .env files, or cloud provider metadata endpoints

Incident Response Steps

  1. Check your lockfiles — search for plain-crypto-js in any package-lock.json, yarn.lock, or pnpm-lock.yaml. If present, the environment is compromised.
  2. Isolate affected systems — disconnect compromised hosts from the network to stop C2 communication.
  3. Revert Axios — pin to axios@1.14.0 or axios@0.30.3 and run a clean install.
  4. Rotate ALL credentials — treat every secret accessible from the compromised environment as stolen: cloud access keys, database passwords, API tokens, SSH keys, npm tokens.
  5. Rebuild from clean state — recreate containers, VMs, and CI/CD environments from known-good base images. Do not attempt to “clean” an infected system.
  6. Audit npm account security — verify account ownership, enable 2FA, review recent publish activity, and check registered email addresses.
  7. Monitor for post-compromise activity — watch for unauthorized access using the stolen credentials in cloud provider audit logs (CloudTrail, GCP Audit Logs, Azure Activity Log).

Mitigation & Remediation

Priority Action Details
Critical Revert to safe Axios versions Pin axios@1.14.0 or axios@0.30.3 in package.json and regenerate lockfiles
Critical Rotate all exposed credentials Cloud keys, database passwords, API tokens, npm tokens, SSH keys
Critical Rebuild compromised environments Clean reinstall from known-good images; do not trust “cleaned” systems
High Audit npm accounts Enable 2FA, verify registered emails, review publish history
High Disable postinstall scripts Run npm config set ignore-scripts true in CI/CD pipelines, or use --ignore-scripts flag
High Pin dependency versions Use exact versions in package.json (no ^ or ~ prefixes) and commit lockfiles
Medium Deploy lockfile integrity monitoring Use tools like Socket, Snyk, or npm audit signatures to detect unsigned or tampered packages
Medium Monitor outbound connections Alert on unexpected HTTPS connections from build environments or developer workstations

Lessons for Supply Chain Security

This incident highlights several systemic risks in the npm ecosystem:

  1. Single maintainer accounts are single points of failure — Axios, with 100M+ weekly downloads, was publishable from a single compromised npm account.
  2. postinstall scripts are a persistent attack vector — npm’s default behavior of executing arbitrary code during installation remains the primary mechanism for supply chain attacks.
  3. Phantom dependencies bypass code review — because the malicious code was never in the Axios repository, code review and static analysis of Axios itself would not have caught this.
  4. OIDC trusted publishing is only effective if enforced exclusively — the project had OIDC publishing configured, but npm CLI publishing was still permitted, allowing the attacker to bypass it entirely.

Timeline

Date Event
March 30–31, 2026 (UTC) Attacker publishes axios@1.14.1 and axios@0.30.4 with phantom dependency
March 31, 2026 Community detects compromise; malicious versions removed from npm
March 31, 2026 StepSecurity, DarkReading, Trend Micro, SANS, and Huntress publish analysis

Sources & References

  1. DarkReading. Axios NPM Package Compromised in Precision Attack. Link
  2. Trend Micro. Axios NPM Package Compromised: Supply Chain Attack. Link
  3. SANS Blog. Axios NPM Supply Chain Compromise. Link
  4. Medium (RealSec). Axios NPM Package Compromised in Supply Chain Attack. Link
  5. WP Security Alerts. Hackers Compromise Axios NPM Package. Link

Sources

  1. Axios NPM Package Compromised in Precision Attack
  2. Axios NPM Package Compromised: Supply Chain Attack Hits ...
  3. Axios NPM Supply Chain Compromise: Malicious Packages Deliver ...
  4. AxiosNPMPackageCompromisedin Supply Chain Attack | Medium
  5. AxiosnpmPackageHacked: Cross-Platform... - WPSecurityAlerts