Attack on Axios Developer Tool Threatens Widespread Compromises

Security researchers at multiple firms are sounding the alarm over a supply chain attack targeting Axios — one of the most downloaded JavaScript packages on the npm registry — that could translate into thousands of downstream compromises across developer environments, CI/CD pipelines, and production applications worldwide.

The attack, confirmed by researchers at StepSecurity, Checkmarx, and several other security vendors, involves two malicious versions of the Axios HTTP client library (v1.14.1 and v0.30.4) published via a compromised npm account. Both versions silently install a fake dependency that delivers a cross-platform Remote Access Trojan (RAT).

Scale of the Threat

Axios is not a niche library. It is one of the foundational pieces of the modern JavaScript ecosystem:

• 100 million+ weekly downloads on npm
• Used by React, Vue, Angular, and virtually every major JavaScript framework
• A transitive dependency in tens of thousands of other npm packages
• Embedded in CI/CD pipelines across enterprises running Node.js services
• Commonly present in serverless functions, backend APIs, and frontend build tooling

This scale means the malicious versions were likely downloaded by a significant number of developers and automated build systems before the attack was detected and the packages were taken down.

"The blast radius here is potentially enormous," one researcher noted. "Axios is infrastructure. When infrastructure gets poisoned, the blast radius isn't just the projects that directly installed it — it includes everything those projects touch."

What Multiple Firms Are Warning About

The coordinated response from security vendors reflects the severity of the incident:

The convergence of multiple independent researchers detecting the same threat in a short window suggests the attack had already achieved meaningful penetration before the community response was coordinated.

The Attack Mechanism

The compromise followed a pattern seen increasingly in npm supply chain attacks:

Step 1 — Account takeover: An attacker obtained credentials for an Axios npm publisher account. The exact method — whether credential stuffing, phishing, or token theft — has not been publicly confirmed, but npm account compromises typically involve stolen tokens from developer machines, .npmrc files checked into repositories, or credentials reused from other breached services.

Step 2 — Malicious version publication: Using the compromised account, the attacker published axios@1.14.1 and axios@0.30.4. These versions appeared functionally identical to legitimate releases — they contained the actual Axios HTTP library code — but added a single malicious entry to the dependencies section of package.json.

Step 3 — Dependency-carried payload: The malicious dependency, plain-crypto-js@4.2.1, is not a legitimate cryptography library. It is a purpose-built malware delivery package containing the cross-platform RAT payload. When npm resolves dependencies and installs Axios, it automatically installs plain-crypto-js alongside it.

Step 4 — Execution: On require() or import of Axios (which happens automatically in any Node.js application that uses it), the RAT payload activates and begins exfiltrating environment variables, credentials, and file system data back to attacker-controlled infrastructure.

Why This Is Different from a Typical Vulnerability

A standard npm vulnerability — a dependency with a known CVE — can typically be managed by updating to a patched version. Supply chain attacks like this one are categorically different:

The malicious code runs with full developer or CI/CD privileges. Unlike a remote web vulnerability that an attacker must find and exploit, supply chain malware runs automatically, in trusted contexts, with access to:

• All environment variables (including AWS_ACCESS_KEY_ID, GITHUB_TOKEN, cloud credentials)
• SSH keys and certificates stored in ~/.ssh
• .env files containing database connection strings and API secrets
• Source code and intellectual property
• CI/CD pipeline configurations that may contain deployment keys

In a CI/CD context, a compromised runner that installed the malicious Axios can potentially:

• Inject backdoors into build artifacts before they reach production
• Exfiltrate code signing certificates
• Pivot from the CI/CD environment to cloud infrastructure using stolen credentials

Am I Affected?

Run the following to determine if your environment installed the malicious versions:

# Check your installed Axios version
npm list axios
 
# Deep check of the full dependency tree
npm ls axios --all 2>/dev/null | grep "1.14.1\|0.30.4"
 
# Check if plain-crypto-js was installed
ls node_modules | grep plain-crypto-js
 
# Check package-lock.json for the malicious versions
grep -A2 '"axios"' package-lock.json | grep '"1.14.1\|0.30.4"'

If any of these return a positive result, treat the environment as fully compromised and begin incident response immediately.

Immediate Response Actions

Remove Malicious Versions

# Upgrade to the latest safe version
npm install axios@latest
 
# Or pin to the last known-clean version
npm install axios@1.14.0
 
# Wipe node_modules and reinstall cleanly
rm -rf node_modules package-lock.json && npm install

Rotate All Secrets — Do Not Skip This Step

If the malicious versions were installed at any point:

# Rotate npm tokens
npm token revoke <token>
 
# GitHub: revoke PATs
# Settings → Developer settings → Personal access tokens → Revoke all
 
# AWS: deactivate and delete affected IAM keys
aws iam delete-access-key --access-key-id <key-id>
aws iam create-access-key  # Create new key
 
# GCP: revoke service account keys
gcloud iam service-accounts keys delete <key-id> \
  --iam-account=<sa>@<project>.iam.gserviceaccount.com

Secret rotation is non-negotiable. Any credentials accessible in the compromised environment — whether loaded via environment variables, read from files, or present in memory — should be considered compromised.

Review CI/CD Pipeline Logs

# Search pipeline logs for the malicious package name
grep -i "plain-crypto-js" ci-build.log
 
# Check for unexpected outbound network connections during the build phase
# Review firewall/proxy logs for connections to unknown IPs during npm install

The Growing npm Supply Chain Problem

This attack is part of a clear trend: npm has become a high-value target for supply chain adversaries. The combination of high download volumes, automatic dependency resolution, and the prevalence of npm in CI/CD pipelines makes it an extraordinarily effective delivery channel for malware.

The common thread across all these incidents: attackers are targeting developer tooling specifically because it operates in privileged contexts with broad access to secrets, infrastructure, and production deployment pipelines.

Preventive Measures

Use npm ci in CI/CD — Always

# Always use npm ci (clean install) in CI, never npm install
npm ci  # Installs exactly what's in package-lock.json, no unexpected resolution

Enable Two-Factor Authentication on npm Accounts

npm now requires 2FA for publishing packages above a threshold of weekly downloads, but developers publishing to widely-used packages should enable 2FA unconditionally.

Adopt Supply Chain Monitoring

Tools like Socket.dev, Snyk, and Semgrep Supply Chain monitor npm packages for behavioral signals (suspicious network calls, new executable code, new dependencies added in a version) and can flag malicious versions before they reach production.

Verify Package Provenance

npm 9+ supports package provenance attestation, which links a package version to its source repository and build workflow:

npm install axios --audit  # Check provenance if available

Conclusion

The Axios supply chain attack is a high-severity incident that underscores the systemic risk of trusting the npm ecosystem without verification. With 100 million weekly downloads, even a brief window of malicious version availability can translate into thousands of compromised developer environments. The security industry's rapid coordinated response limited the damage window, but affected organizations need to act decisively: remove malicious versions, rotate all secrets, and audit CI/CD logs for signs of exfiltration.

This incident should serve as a forcing function for security teams to implement supply chain monitoring, enforce npm ci in all build pipelines, and establish incident response playbooks for package compromise scenarios.

Source: CyberScoop — March 31, 2026