Today, March 31, 2026 we discovered a sophisticated attack in software supply chain against popular JavaScript library Axios. The following is information on how software is being developed through the software development infrastructure today.
Since Axios has over 100 million weekly downloads, it is deeply embedded in thousands of frontend applications, thousands of backend services, in many CI/CD pipelines, and in many other internal automation tools. Thus a short lived compromise has huge impact. In the reported case a maintainer account had been compromised. In the following days malware had been spread to thousands of environments by being installed by normal npm install commands.
This attack isn't actually a vulnerability in code. It's an attack using trusted pieces of the npm ecosystem, the way that packages depend on other packages, and the scripts that are run at install time, to create an attack surface out of what appears to be safe code.
What initially started out as a problem with a package has evolved into a larger problem with more systemic risks to the general infrastructure, design and operation of our services.
Blog contents
What Happened
The attackers took control of the npm account of the lead maintainer of Axios. Changing the email address of the account to a ProtonMail email address that they controlled was sufficient to lock the real maintainer out of his own account. The attackers then were able to publish new versions of Axios.
From there they released two malicious versions:
Both versions quietly pulled in a phantom dependency called
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.
They pre-published a clean version, plain-crypto-js@4.2.0, about 18 hours prior to the malicious update. The legitimate update to plain-crypto-js@4.2.0 then looked like a normal update of another package, and will likely not trigger any further suspicion from automated scanners, which would require a human to review the update in more detail.
The malicious versions were up for about 2 to 3 hours before they were taken down. In that time any system running an npm install (whether on a developer's laptop, in a CI/CD pipeline or as part of an automated deployment) would have potentially installed the payload and even run it as part of the install process.
From Install to Compromise (How the Attack Actually Worked)
The attack relies on the expected behavior of npm when it comes to packages with lifecycle scripts. These are run when you install a package.
A malicious dependency in an application's package.json has a postinstall hook. The dropper script setup.js for the malicious dependency is started after all dependencies for the application have been installed.
The dropper went through these steps:
Capabilities of the RAT
The second-stage payload is a full Remote Access Trojan (RAT) with the following functionality among others.
We have detected credential harvesting of SSH private keys as well as cloud credentials to services such as AWS, GCP and Azure. Additionally, credentials for npm as well as GitHub tokens have been harvested.
Reconnaissance on the system that the account was created on i.e. (hostname, user details, OS version, applications installed etc.) also a list of the processes running on the system.
Utilize the file system to gather information about directories and files pertaining to the incident. Utilize the file system to move incident related sensitive data from the compromised host quietly without alerting others to the activity.
The malware can be used to remotely control a compromised host as well as upload other malware on that compromised host.
And persistence to continue running in the background after the original install had completed.
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.
Code obfuscation in this supply chain attack prevented a security audit via npm audit from detecting this issue. In standard npm list output the compromise was not visible. Although no errors were reported by users during the install process the only evidence of a compromise would have been visible in the file system or network traffic. Users typically wouldn't check for such evidence during a normal installation process.
Why This Is an Infrastructure Problem (Not Just npm)
This attack occurs every time you run a dependency install allowing code to run in your infrastructure without you knowing how it was put there.
The Real Risk: Silent Credential Exfiltration
Following the launch of the attack, the threat actor would then proceed to extract out sensitive assets from the compromised environment. These include: AWS IAM keys, GCP service accounts, Azure AD tokens,.env files containing API keys for applications, OAuth tokens, SSH private keys, database connection strings, and other secrets that are injected at runtime by CI/CD tools. Importantly, the attack would typically not alert whilst this installation of dependencies is taking place and would result in a full infrastructure breach.
Critical Weaknesses Exposed
This type of attack is hard to prevent from a security point of view because it is not based on a bug of the software, but on the behavior of the software that it has been programmed for.
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.
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.
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
Netrouting secures a large part of the infrastructure. This is done on a multi-layered basis, beyond the simple security of the server room and network perimeter.
Even a supply chain attack on internal trusted processes is as big a threat to an organization as the external hacker threats that have been so prominent in recent media.
To mitigate these risks for our customers, the build environment for the software compilation is 100 % separate from the production environment. We also strictly control the egress traffic and support zero trust architectures. As for the runtime environments, we monitor for unusual behavior. The number of places where credentials are disclosed across all layers is also kept to a minimum. So even if a dependency is compromised, the rest of the environment is not significantly affected.
Remediation Guidance: Immediate Actions If Exposed
If any system ran
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
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.
In addition to the analysis of the code, the detection also has to analyze the runtime behavior of these code parts.
After the problems have occurred it is often more effective to isolate and control them than it is to try to prevent problems from occurring in the first place.
Conclusion
The Axios supply chain attack is yet another example of the innovative ways to compromise modern infrastructure.
None of these required any new vulnerabilities or exploits. They all relied on the trust, automation, default behavior and assumptions that are deeply embedded into the entire ecosystem.
A further point for the infrastructure teams. Code security is no longer simply about securing the code. It's also about securing the environments through which that code will run.
To be resilient in a world where every npm install could potentially run arbitrary code, the only way is to have visibility into the software you are running, isolate it from other components in your software stack, and have complete control of your software supply chain.
