Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account

A supply chain attack targeting the widely used Axios JavaScript HTTP client library has been discovered after researchers identified two malicious versions published to the npm registry through a compromised developer account. Versions 1.14.1 and 0.30.4 of Axios were found to inject a fake dependency — plain-crypto-js@4.2.1 — that delivers a cross-platform Remote Access Trojan (RAT) to any developer or CI/CD environment that installed the compromised packages.

Axios is one of the most downloaded packages on npm, used in millions of JavaScript and Node.js projects worldwide for HTTP request handling. The scale of Axios's adoption makes this a high-impact supply chain attack.

Attack Chain

The attack followed a well-understood supply chain compromise pattern:

1. Account takeover — An attacker gained access to an Axios npm account (exact method not yet disclosed)
2. Malicious version publication — Two new package versions were published: axios@1.14.1 and axios@0.30.4
3. Fake dependency injection — Both malicious versions declare plain-crypto-js@4.2.1 as a dependency
4. Malware delivery — plain-crypto-js@4.2.1 is not a legitimate crypto library; it contains the cross-platform RAT payload
5. Execution — Any project that runs npm install axios (or has these versions pinned) installs the RAT alongside the legitimate Axios functionality

The malicious packages were discovered by security researchers at StepSecurity, who identified the anomalous dependency and traced it to account compromise.

Why Axios Is a High-Value Target

Axios is a promise-based HTTP client that abstracts browser XMLHttpRequest and Node.js http module calls into a unified API. It consistently ranks among the top 5 most downloaded packages on npm:

• Used in React, Vue, Angular, and vanilla JavaScript frontend projects
• Used in Node.js backend services for external API calls
• Integrated into thousands of npm packages as a transitive dependency
• Part of the default toolchain for many popular frameworks and boilerplates
• Installed automatically in CI/CD pipelines during build processes

Compromising Axios means any project that runs npm install in the presence of a lockfile pinned to the malicious versions will automatically deliver the RAT to the build environment — potentially with access to secrets, tokens, and credentials stored in CI/CD systems.

The Cross-Platform RAT Payload

While full technical analysis of the RAT is ongoing, cross-platform RATs delivered through npm supply chain attacks typically provide attackers with:

• Remote shell access to the infected developer machine or CI/CD runner
• Environment variable exfiltration — capturing AWS_ACCESS_KEY_ID, GITHUB_TOKEN, NPM_TOKEN, and other sensitive values
• File system access — reading ~/.ssh, .env files, credential stores, and source code
• Keylogging capability — capturing credentials typed during development sessions
• Persistence mechanisms — installing startup entries or cron jobs for sustained access

In CI/CD contexts, the consequences are particularly severe: attackers with access to build runners can:

• Inject malicious code into build artifacts before deployment
• Exfiltrate code signing certificates and deployment keys
• Pivot from CI/CD infrastructure to production cloud environments

Immediate Response Steps

1. Check Your Axios Version

# Check current installed axios version
npm list axios
 
# Check package-lock.json for pinned version
cat package-lock.json | grep '"axios"' | head -10
 
# Check if malicious versions are present anywhere in the dependency tree
npm ls axios --all 2>/dev/null | grep "1.14.1\|0.30.4"

2. Upgrade to Safe Version Immediately

# Upgrade to the latest safe version of axios
npm install axios@latest
 
# Or pin to a known-safe version (1.14.0 or 0.30.3)
npm install axios@1.14.0
 
# Regenerate package-lock.json after upgrade
npm install

3. Audit for Malicious Dependency

# Check if plain-crypto-js was installed in your node_modules
ls node_modules | grep plain-crypto-js
 
# Check npm audit for any flagged issues
npm audit
 
# Clean install after removing malicious versions
rm -rf node_modules package-lock.json
npm install

4. Treat Affected Environments as Compromised

If axios@1.14.1 or axios@0.30.4 were installed in any environment, assume compromise and initiate incident response:

# Immediately rotate ALL secrets accessible in the affected environment
# This includes:
#   - npm tokens (NPM_TOKEN)
#   - GitHub/GitLab tokens (GITHUB_TOKEN, CI_JOB_TOKEN)
#   - Cloud credentials (AWS, GCP, Azure keys)
#   - Database connection strings
#   - Any API keys present in environment variables or .env files
 
# Revoke npm token
npm token revoke <token>
 
# GitHub — revoke personal access tokens
# Settings → Developer settings → Personal access tokens → Revoke
 
# AWS — deactivate and delete affected IAM access keys
aws iam delete-access-key --access-key-id <key-id>

5. Review CI/CD Logs

If the malicious package was installed in a CI/CD pipeline:

# Review pipeline logs for anomalous outbound connections
# Look for unexpected network calls during npm install phase
grep -i "plain-crypto-js\|1.14.1\|0.30.4" ci-logs.txt
 
# Check for outbound connections to unknown IPs during build
# Review firewall/proxy logs during the affected build window

npm Supply Chain Attack Context

This attack follows a disturbing 2025-2026 trend of npm supply chain compromises targeting high-value, widely-used packages:

The common thread: attackers target developer tooling because it has privileged access to secrets, infrastructure, and production code pipelines.

Preventive Measures for npm Security

Lock File Integrity

Always commit package-lock.json and use npm ci (not npm install) in CI/CD pipelines. npm ci performs a clean install from the lockfile, preventing unexpected version resolution.

# In CI/CD, always use:
npm ci
 
# Not:
npm install  # This can update to unexpected versions

Enable npm Provenance and Audit

# Enable npm audit in CI/CD pipelines
npm audit --audit-level=high
 
# Use package provenance verification (npm 9+)
npm install --audit

Dependency Pinning

Consider using tools like Renovate or Dependabot with strict pinning policies to control when and which versions of dependencies are updated.

Allowlist-Based Dependency Scanning

Tools like Socket.dev, Snyk, and Semgrep Supply Chain can flag suspicious new package versions before they reach production.

Conclusion

The Axios npm supply chain attack is a reminder that even the most trusted, widely-used packages can be weaponized through account compromise. Developers and security teams must treat npm packages as a significant attack surface, implement automated supply chain monitoring, and have clear incident response playbooks for when trusted dependencies are found to be compromised. If you have axios@1.14.1 or axios@0.30.4 in any environment, treat that environment as compromised and rotate all secrets immediately.

Source: The Hacker News — March 31, 2026