Need help?
Get answers fast, or talk to us on live chat.
Start Live Chat
Infrastructure
Apr 06, 2026
On March 31, 2026, one of the most widely used JavaScript libraries – Axios – became the target of a highly sophisticated supply chain attack. It really exposed a fundamental weakness in modern development infrastructure that a lot of teams still overlook.
With over 100 million weekly downloads, Axios sits deep inside frontend applications, backend services, CI/CD pipelines, and all kinds of internal automation systems. It’s so common that even a short compromise can create a surprisingly large blast radius. In this case, attackers took over a maintainer account and turned ordinary npm install commands into a silent way to push malware across thousands of environments.
What makes this attack stand out is that they didn’t exploit any traditional vulnerability in the code. Instead they used the trusted parts of the npm ecosystem itself – dependency resolution and those automatic install-time scripts – and turned normal behavior into a real attack surface.
This isnt just some package problem anymore. It’s a bigger systemic risk for how we build and run infrastructure today.
What Happened
The attackers got control of the npm account that belonged to Axios’s lead maintainer. They simply changed the email address to one they controlled on ProtonMail. That move locked out the real owner and gave the attacker full rights to publish new versions.
From there they released two malicious versions:
axios@1.14.1
Aimed at developers keeping up with modern 1.x releases
axios@0.30.4
Targeting older systems still running on 0.x versions
Both versions quietly pulled in a phantom dependency called
plain-crypto-js@4.2.1
This package was never actually used or called by Axios code at all. Its only job was to serve as a delivery vehicle for the malicious payload through npm’s lifecycle hooks.
To make it less suspicious the attackers first published a clean version plain-crypto-js@4.2.0 about 18 hours earlier. That trick helped the bad update blend in with regular package activity and slip past the basic checks that automated scanners usually run.
The malicious versions only stayed live for roughly 2 to 3 hours. But in that short window any system running npm install – on a developer laptop, inside a CI/CD pipeline, or during an automated deployment – could have quietly installed and triggered the payload.
From Install to Compromise (How the Attack Actually Worked)
The whole attack depended on npm doing what it normally does: running lifecycle scripts automatically when you install a package.
As soon as the malicious dependency landed, its package.json fired a postinstall hook. That hook ran a dropper script called setup.js without any user interaction needed.
The dropper went through these steps:
⚠️ Execution Flow (What Actually Happened Behind the Scenes)
1
System fingerprinting began by identifying the operating system —
Windows, macOS, or Linux
Windows, macOS, or Linux
↓
2
Established connection to a remote command-and-control server
↓
3
Pulled the correct second-stage payload tailored for the detected platform
↓
4
Executed silently in the background — completely detached from the npm process
Capabilities of the RAT
The second-stage payload turned out to be a full Remote Access Trojan. It could do things like:
Credential harvesting including SSH private keys, cloud credentials from AWS GCP and Azure, plus npm and GitHub tokens.
System reconnaissance such as hostname, user details, OS version, installed applications and running processes.
File system access for directory enumeration, finding sensitive files and quietly exfiltrating them.
Remote execution so it could run arbitrary commands or drop additional payloads.
And persistence that let it keep running in the background even after the original install finished.
Anti-Forensics Techniques
To stay hidden the malware cleaned up after itself pretty effectively. It deleted its own installation scripts once the job was done, replaced the package.json with a clean version, mimicked normal package metadata, and made sure to suppress any errors so the npm install would finish without showing problems.
Because of these tricks npm audit didnt flag anything, npm list looked perfectly clean, and users saw no visible errors. The only real signs were at the filesystem level or in network traffic – stuff most people don’t check during a regular install.
Why This Is an Infrastructure Problem (Not Just npm)
This attack makes one thing very clear: every time you run a dependency installation you’re allowing code to execute inside your infrastructure without really thinking twice about it.
⚠️ High-Risk Environments Affected
CI/CD Pipelines
Built for speed and automation, not strict validation.
Automatically runs npm install in high-trust environments with access to
deployment credentials, cloud APIs, and internal services.
Weak network egress controls allow malicious activity, while continued pipeline execution
gives malware time to establish itself.
Automatically runs npm install in high-trust environments with access to
deployment credentials, cloud APIs, and internal services.
Weak network egress controls allow malicious activity, while continued pipeline execution
gives malware time to establish itself.
Developer Workstations
Rich in sensitive data like SSH keys, API tokens, and repository access.
A compromise here enables lateral movement, allowing attackers to spread deeper
into internal systems and production environments.
A compromise here enables lateral movement, allowing attackers to spread deeper
into internal systems and production environments.
Build & Automation Systems
Designed to trust dependencies by default.
Operate in ephemeral environments, reuse cached layers, and allow unrestricted
outbound network access.
This creates ideal conditions for malware execution and data exfiltration.
Operate in ephemeral environments, reuse cached layers, and allow unrestricted
outbound network access.
This creates ideal conditions for malware execution and data exfiltration.
The Real Risk: Silent Credential Exfiltration
Once it ran the attack could pull sensitive assets such as AWS IAM keys, GCP service accounts, Azure tokens, .env files, API keys, OAuth tokens, SSH private keys, database connection strings and CI/CD secrets that get injected at runtime. It basically turned a simple dependency install into a full infrastructure breach and it often did so without setting off any obvious alerts.
Critical Weaknesses Exposed
The dangerous part is that this attack did not rely on a bug. It used behavior that was intentionally built into the system – and that’s exactly why its so risky.
🚨 Key Security Failures & Attack Enablers
OIDC Trusted Publishing Is Not Enough
Axios had already started using modern OIDC secure publishing tied to CI/CD workflows.
However, the attacker bypassed it using a stolen long-lived npm token.The issue is that OIDC does not disable legacy authentication.
Classic tokens remain valid unless revoked, and npm still allows fallback to weaker methods.
Adding a secure path does not eliminate the insecure one.
However, the attacker bypassed it using a stolen long-lived npm token.The issue is that OIDC does not disable legacy authentication.
Classic tokens remain valid unless revoked, and npm still allows fallback to weaker methods.
Adding a secure path does not eliminate the insecure one.
Caret (^) Versioning Enables Silent Compromise
A simple version rule like “axios”: “^1.14.0” automatically pulls newer patch versions
without approval during installs.This allows malicious updates to spread silently across pipelines, developer machines,
and automated builds. Even a short exposure window can lead to widespread impact.
without approval during installs.This allows malicious updates to spread silently across pipelines, developer machines,
and automated builds. Even a short exposure window can lead to widespread impact.
postinstall Scripts Are an Unrestricted Execution Surface
npm lifecycle hooks allow automatic code execution during installation.
There is no sandbox, no permission system, and no user confirmation — it runs with full privileges.
Even unused dependencies can execute code, making this a
critical attack vector.
Anti-Forensics Break Standard Tooling
The malware hid its tracks by modifying scripts, replacing package.json, and spoofing metadata.
As a result, tools like npm audit and npm list showed no issues,
and manual checks appeared normal.
Detection required deeper methods like filesystem inspection, network monitoring, and behavioral analysis.
CI/CD and Developer Environments Are High-Value Targets
The attack exploited modern infrastructure patterns — automated installs, high-privilege environments,
open network access, and runtime secret injection.These conditions make build systems ideal for credential theft and lateral movement.
open network access, and runtime secret injection.These conditions make build systems ideal for credential theft and lateral movement.
Incomplete Secure Publishing Models
Even with OIDC-based publishing, legacy authentication methods like long-lived tokens remain active.
This creates a dangerous gap: a secure path exists, but the
insecure fallback is still enabled.
How Netrouting Approaches This Risk
At Netrouting we treat infrastructure security as a multi-layered responsibility that goes well beyond traditional perimeter defenses.
Supply chain attacks like this one show that threats can come from inside trusted internal processes not only from outside hackers.
We help organizations lower this risk by isolating build environments from production, adding strict network segmentation and egress filtering, supporting zero-trust architectures, enabling runtime monitoring for unusual behavior and reducing where credentials are exposed across layers. That way even if a dependency gets compromised its impact on the rest of the environment stays limited.
Remediation Guidance: Immediate Actions If Exposed
If any system ran
Terminal Command
npm install
Installs all dependencies listed in package.json
during that exposure window you should treat it as fully compromised. It’s better not to try cleaning it up in place – just rebuild everything from a known-good baseline.
Long-Term Infrastructure Mitigation
🛡️ Recommended Security Practices
Deterministic Installs
Use npm ci instead of regular npm install.
It enforces exact dependency versions and prevents unexpected updates from sneaking in.
It enforces exact dependency versions and prevents unexpected updates from sneaking in.
Disable Lifecycle Scripts
Run npm install –ignore-scripts, especially in CI and sensitive environments.
This blocks automatic code execution and reduces the attack surface.
This blocks automatic code execution and reduces the attack surface.
Restrict Network Egress
Allow outbound connections only to required domains.
Block everything else and monitor DNS and HTTP traffic from build systems.
Block everything else and monitor DNS and HTTP traffic from build systems.
Zero-Trust CI/CD Design
Use short-lived credentials, enforce least-privilege access,
and isolate different pipeline stages to limit potential blast radius.
and isolate different pipeline stages to limit potential blast radius.
Runtime Monitoring
Focus on behavioral monitoring rather than just static code analysis.
Track process execution, network activity, and filesystem changes.
Track process execution, network activity, and filesystem changes.
Static scanning alone is no longer sufficient against modern supply chain threats.
Key Takeaways for Infrastructure Teams
Dependency installation is really an execution event now.
CI/CD pipelines have become high-value attack targets.
Trust-based ecosystems bring systemic risks.
Detection needs to shift from just looking at code to watching runtime behavior.
Isolation and control often work better than trying to prevent everything upfront.
Conclusion
The Axios supply chain attack shows a clear shift in how modern infrastructure gets compromised.
It didn’t need fancy vulnerabilities or exploits. Instead it took advantage of trust, automation and the default behaviors baked into the ecosystem.
For infrastructure teams the main takeaway is simple: security has to move beyond just protecting the code. We need to focus on controlling the environments where that code actually runs.
In a world where every npm install can potentially execute arbitrary code, real resilience depends on better visibility, strong isolation and tight control over the whole software supply chain.
