Axios npm Supply Chain Attack: Maintainer Account Hijacked, RAT Deployed to Millions

TL;DR

If your organization installed axios@1.14.1 or axios@0.30.4, treat every machine that ran npm install during the attack window as compromised. The RAT self-destructs after execution, so post-infection inspection of node_modules will not reveal it. Check for platform-specific artifacts and rotate all credentials immediately.

What Is Axios?

Axios is the most widely used HTTP client library in the JavaScript ecosystem, with over 100 million weekly downloads on npm. It is a foundational dependency for web applications, Node.js backends, serverless functions, and mobile apps built with React Native.

Its ubiquity makes it a uniquely high-value target. Axios is present in roughly 80% of cloud and code environments, according to Wiz's analysis. A single compromised version can cascade across thousands of organizations within minutes, especially given how aggressively CI/CD pipelines resolve and install dependencies.

The Attack: What Happened

Preparation (March 30)

The attacker laid the groundwork the day before the main attack:

• 23:41 UTC: Published plain-crypto-js@4.2.0, a clean placeholder package on npm, designed to establish a brief registry history and avoid suspicion
• 23:59 UTC: Published plain-crypto-js@4.2.1, the version containing the actual malicious payload with a postinstall hook

The Compromise (March 31)

The attacker gained access to the npm account of jasonsaayman, the primary maintainer of axios. The account's registered email was changed from jasonsaayman@gmail.com to ifstap@proton.me, an attacker-controlled ProtonMail address. Using a stolen npm access token, the attacker published two malicious versions:

• 00:21 UTC: axios@1.14.1 published
• 01:00 UTC: axios@0.30.4 published

Both versions targeted the current 1.x and legacy 0.x release branches simultaneously, maximizing the number of affected projects.

Detection and Removal

• 00:05 UTC: Socket's automated scanner flagged plain-crypto-js@4.2.1 within six minutes of publication
• 03:15 UTC: axios@1.14.1 removed from npm (approximately 2 hours 54 minutes live)
• 03:15 UTC: axios@0.30.4 removed (approximately 2 hours 15 minutes live)
• 04:26 UTC: plain-crypto-js@4.2.1 replaced with a security placeholder

A Critical Red Flag: No GitHub Activity

Legitimate axios releases are published through GitHub Actions using npm's OIDC Trusted Publisher mechanism. The malicious versions were published manually via a stolen access token, with no corresponding GitHub commits, pull requests, or release tags. This discrepancy was a key forensic indicator of the compromise.

How the Attack Worked

The Malicious Dependency

Rather than modifying the axios source code directly (which would have been more visible in code reviews), the attacker injected plain-crypto-js@^4.2.1 as a new runtime dependency in package.json. This package was never imported anywhere in axios source code. Its sole purpose was executing a postinstall hook that deployed the RAT.

The RAT Dropper

The dropper payload (setup.js) used multiple layers of obfuscation to evade static analysis: XOR ciphering, string array encoding, Base64 with custom substitution, and runtime-only decoding. It detected the target operating system and deployed platform-specific payloads.

Platform-Specific Payloads

macOS: Downloaded a binary disguised as an Apple cache daemon to /Library/Caches/com.apple.act.mond. The naming mimicked legitimate Apple system processes to blend in with normal system activity.

Windows: Executed a three-stage attack: located PowerShell, copied it to %PROGRAMDATA%\wt.exe to evade EDR detection, then ran a hidden PowerShell RAT with -ExecutionPolicy Bypass and -WindowStyle Hidden.

Linux: Downloaded a Python RAT script to /tmp/ld.py and ran it in the background with nohup.

Command and Control

All payloads communicated with a C2 server at sfrclak[.]com:8000 (IP: 142.11.206.73), using different POST body identifiers per platform: packages.npm.org/product0 (macOS), packages.npm.org/product1 (Windows), packages.npm.org/product2 (Linux).

Anti-Forensics

After execution, the dropper cleaned up all evidence:

1. Deleted the malicious setup.js
2. Removed the poisoned package.json
3. Renamed a clean package.md to package.json

This left the node_modules/plain-crypto-js directory looking like a normal, harmless package.

Impact and Blast Radius

By the Numbers

Even within a 2-3 hour window, the exposure was significant:

• Axios receives 100+ million weekly downloads
• Present in ~80% of cloud and code environments
• Wiz observed execution in 3% of affected environments
• Both major version branches (0.x and 1.x) were targeted simultaneously

Downstream Contamination

The attack did not just affect direct axios installations. Packages published during the attack window that resolved axios as a dependency shipped with the compromised version locked in their dependency trees. Examples include onstarjs2@2.16.2 and proxmox-sdk@0.0.10-99a0, as identified by Koi.ai.

Community Response

The response revealed additional concerning details. When community members filed GitHub issue #10604 to report the compromise, earlier reports were being deleted shortly after creation, suggesting the attacker may have retained some access to the GitHub account as well. Maintainer DigitalBrainJS later merged a PR adding a deprecate.yml workflow to allow manual deprecation of compromised versions.

The axios team's own assessment was alarming: the attacker's permissions exceeded those of the maintainers themselves, pointing to fundamental gaps in the publishing workflow.

Indicators of Compromise (IOCs)

Package-Level Checks

1# Check if affected versions are in your lockfile
2grep -E "axios@1\.14\.1|axios@0\.30\.4" package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null
3
4# Check installed versions
5npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"
6
7# Check for the malicious dependency
8ls node_modules/plain-crypto-js 2>/dev/null && echo "POTENTIALLY AFFECTED"

System-Level Artifacts

Network IOCs

Why This Matters for Startups and SMBs

JavaScript Is Everywhere

Unlike attacks targeting niche packages, axios is a foundational dependency. If your company has a web application, a Node.js API, or any JavaScript-based tooling, there is a significant chance axios is somewhere in your dependency tree, possibly multiple times at different versions.

Small Teams, Big Attack Surface

Startups and SMBs often lack dedicated security teams to monitor for supply chain threats in real time. A 2-3 hour attack window is more than enough for an automated CI/CD pipeline to pull in a compromised dependency. Many organizations would not even notice until days or weeks later, if at all.

Developer Machines Are the Real Target

The RAT was not targeting production servers directly. It was targeting the machines running npm install, which are typically developer laptops and CI/CD runners. These machines hold SSH keys, cloud credentials, API tokens, and access to source code repositories. A single compromised developer machine can be the entry point for a full organizational breach.

Transitive Dependencies Hide the Risk

You do not need to use axios directly to be affected. If any package in your dependency tree depends on axios with a flexible version range (like ^1.14.0), the compromised version could have been resolved automatically during the attack window.

What Compliance Frameworks Say About Supply Chain Security

Supply chain attacks like this one are exactly why compliance frameworks mandate controls around vendor risk management, change management, and secure development.

SOC 2

SOC 2 addresses supply chain security through several Trust Services Criteria:

• CC6.1 (Logical and Physical Access Controls): Organizations must implement controls over systems and software they deploy, including third-party libraries and open-source dependencies
• CC7.1 (System Operations): Requires monitoring for anomalous behavior in build and deployment pipelines
• CC8.1 (Change Management): Mandates that changes to system components, including dependency updates, are authorized, tested, and approved before deployment
• CC3.2 (Risk Assessment): Organizations must identify and assess risks from third-party dependencies as part of their ongoing risk assessment process

ISO 27001

ISO 27001 (2022 revision) includes controls directly relevant to this type of attack:

• A.8.19 (Installation of Software on Operational Systems): Requires procedures for controlling software installation, including package managers
• A.8.25 (Secure Development Life Cycle): Mandates security throughout the development process, including dependency management and integrity verification
• A.5.21 (Managing Information Security in the ICT Supply Chain): Explicitly addresses risks from the technology supply chain, requiring organizations to manage and monitor supplier relationships
• A.8.8 (Management of Technical Vulnerabilities): Requires timely identification and remediation of vulnerabilities in third-party components

Both frameworks recognize that your security posture is only as strong as your weakest dependency. The controls below are not just good practice, they are compliance obligations.

How to Protect Your Organization

Immediate Actions (If You Were Affected)

1. Check if you installed affected versions:

   Bash Copy

   1# Check lockfiles
   2grep -E "axios@1\.14\.1|axios@0\.30\.4" package-lock.json yarn.lock 2>/dev/null
   3
   4# Check installed packages
   5npm list axios 2>/dev/null | grep -E "1\.14\.1|0\.30\.4"

2. Scan for RAT artifacts:

   Bash Copy

   1# macOS
   2ls -la /Library/Caches/com.apple.act.mond 2>/dev/null
   3
   4# Linux
   5ls -la /tmp/ld.py 2>/dev/null
   6
   7# Windows (PowerShell)
   8# Test-Path "$env:PROGRAMDATA\wt.exe"

3. Rotate all credentials on any machine that ran npm install during the attack window:

   • npm tokens
   • SSH keys
   • AWS access keys and secrets
   • Cloud provider credentials (GCP, Azure)
   • CI/CD secrets and pipeline tokens
   • .env file contents
   • Database connection strings

4. Audit CI/CD logs for any pipeline runs between 00:21 UTC and 03:15 UTC on March 31, 2026 that installed axios

5. If RAT artifacts are found, treat the machine as fully compromised and rebuild from a known-good state

Preventive Measures for All Teams

Pin Dependencies and Use Lockfiles

Never allow floating version ranges (^ or ~) to resolve automatically in production or CI/CD:

1# Always commit your lockfile
2git add package-lock.json
3
4# Use npm ci instead of npm install in CI/CD
5# This installs exactly what's in the lockfile
6npm ci
7
8# Consider using --ignore-scripts to prevent postinstall hooks
9npm ci --ignore-scripts

Disable Lifecycle Scripts by Default

The axios attack relied on npm's postinstall hook. You can disable these globally:

1# Disable lifecycle scripts globally
2npm config set ignore-scripts true
3
4# Or per-project in .npmrc
5echo "ignore-scripts=true" >> .npmrc
6
7# Then explicitly run scripts only for trusted packages
8npm rebuild <trusted-package>

Enable MFA for npm Publishing

If you maintain npm packages, enforce multi-factor authentication on your account. The axios compromise exploited a stolen access token, likely from a session without MFA:

1# Enable 2FA on your npm account
2npm profile enable-2fa auth-and-writes

Use npm's Trusted Publishing (OIDC)

Move away from long-lived npm tokens. Use GitHub Actions with npm's OIDC Trusted Publisher, which ties publishing to specific GitHub repositories and workflows:

1# .github/workflows/publish.yml
2permissions:
3  id-token: write
4steps:
5  - uses: actions/setup-node@v4
6    with:
7      registry-url: 'https://registry.npmjs.org'
8  - run: npm publish --provenance
9    env:
10      NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Scan Dependencies in CI/CD

Integrate dependency scanning into every pull request and deployment:

1# npm's built-in audit
2npm audit
3
4# Socket.dev for deeper analysis
5npx socket-security/cli report
6
7# Snyk for vulnerability scanning
8npx snyk test

Monitor for Anomalous Network Activity

Configure network monitoring to detect unexpected outbound connections from developer machines and CI/CD runners. The C2 domain sfrclak[.]com and IP 142.11.206.73 should be added to blocklists immediately.

Use Package Overrides to Enforce Safe Versions

Add overrides in your package.json to prevent transitive dependencies from pulling in compromised versions:

1{
2  "overrides": {
3    "axios": "1.14.0"
4  }
5}

For Yarn:

1{
2  "resolutions": {
3    "axios": "1.14.0"
4  }
5}

Security Checklist

Within 24 Hours

• Check all environments for axios@1.14.1 or axios@0.30.4
• Scan for RAT artifacts on developer machines and CI/CD runners
• Rotate credentials on any affected machines
• Block C2 indicators (sfrclak[.]com, 142.11.206.73) at the network level
• Audit CI/CD pipeline logs for the attack window

Within 72 Hours

• Pin axios to a safe version (1.14.0 or 0.30.3) across all projects
• Add package overrides to prevent transitive resolution of compromised versions
• Add dependency scanning to CI/CD pipelines
• Review all npm access tokens and revoke any that are unnecessary
• Enable MFA on all npm accounts that publish packages

Ongoing

• Use npm ci instead of npm install in all CI/CD pipelines
• Commit and review lockfiles in every repository
• Consider disabling lifecycle scripts by default (.npmrc with ignore-scripts=true)
• Adopt npm's Trusted Publishing (OIDC) for all packages you maintain
• Include supply chain security in your incident response procedures
• Monitor security advisories for critical dependencies via GitHub Dependabot or Snyk

Conclusion

The axios supply chain attack is a wake-up call for the JavaScript ecosystem. With 100+ million weekly downloads, axios is not a niche tool. It is infrastructure. The attack succeeded because a single maintainer account, secured with a long-lived token rather than OIDC-bound publishing, provided enough access to push malicious code to millions of machines within minutes.

This follows a pattern we have been tracking closely: the Nx npm compromise, the LiteLLM PyPI attack, and the Trivy GitHub Actions breach. Attackers are systematically targeting the tools developers trust most, because compromising one popular package is more efficient than attacking thousands of organizations individually.

The defenses are not complicated: pin your dependencies, commit your lockfiles, use npm ci, disable lifecycle scripts, enforce MFA, and move to OIDC-based publishing. But these controls must be implemented consistently, not as afterthoughts.

For organizations pursuing SOC 2 or ISO 27001 certification, supply chain security is not optional. These frameworks explicitly require controls around third-party software, change management, and vulnerability management. The practices outlined above are not just recommendations, they are compliance obligations.

If you need help implementing supply chain security controls as part of your compliance program, get in touch with Bastion. We help startups and SMBs build security programs that address real threats, not just check boxes.

Sources:

• Aikido: axios compromised on npm: maintainer account hijacked, RAT deployed
• Koi.ai: Axios Compromised: A Supply Chain Attack on npm's Most Popular HTTP Client
• Socket.dev: Supply Chain Attack on Axios Pulls Malicious Dependency
• Wiz: Axios NPM Distribution Compromised in Supply Chain Attack
• Snyk: Axios npm Package Compromised: Supply Chain Attack Delivers Cross-Platform RAT
• The Hacker News: Axios Supply Chain Attack Pushes Cross-Platform RAT via Compromised npm Account
• GitHub Issue #10604: axios@1.14.1 and axios@0.30.4 are compromised