Axios Supply Chain Attack: A Trojan Horse in 80% of Cloud Environments
A sophisticated supply chain attack compromised Axios, the ubiquitous JavaScript HTTP client, injecting a cross-platform remote access trojan (RAT) into versions 1.14.1 and 0.30.4. Exploiting a long-lived npm access token, attackers bypassed modern security measures like OIDC Trusted Publisher and SLSA attestations, highlighting the enduring risk of compromised maintainer credentials and the fragility of software supply chains. The incident impacted an estimated 80% of cloud and code environments, with initial infections detected within 89 seconds of malicious package publication.
The Anatomy of a Precision Strike
This wasn’t a brute-force attack. The attackers demonstrated a chilling level of operational security (OPSEC). Eighteen hours before deploying the malicious Axios versions, they published a clean version of a seemingly innocuous dependency, [email protected], under a separate npm account. This pre-publication activity served to establish a publishing history and evade initial detection by novel-package scanners. The weaponized 4.2.1 version contained a postinstall script – a common, and often overlooked, attack vector – that silently dropped a platform-specific RAT onto the developer’s machine. Crucially, the malicious code didn’t alter the Axios codebase itself; it simply added a dependency that *never gets imported*. This stealthy approach minimized the chances of triggering code analysis alerts.
The attackers exploited a fundamental flaw in npm’s authentication hierarchy. Despite the Axios project implementing robust security measures like OIDC Trusted Publisher, a legacy npm token remained active and, critically, took precedence over the OIDC credentials. When both authentication methods are present, npm defaults to the token. This parallel authentication path allowed the attackers to bypass the entire CI/CD pipeline, publishing the malicious packages directly through the npm CLI. It’s a stark reminder that even the most advanced security controls are only as strong as their weakest link.
The Legacy Token Problem: A Recurring Nightmare
This isn’t an isolated incident. The Shai-Hulud worm in September 2025, which compromised over 500 npm packages, likewise originated from a stolen maintainer credential. Similarly, the PackageGate research in January 2026 uncovered zero-day vulnerabilities in multiple package managers, all stemming from weaknesses in dependency management and credential security. The common thread? Compromised maintainer accounts. As Merritt Baer, CSO at Enkrypt AI and former Deputy CISO at AWS, succinctly put it: “From my experience at AWS, it’s very common for old auth mechanisms to linger. Modern controls obtain deployed, but if legacy tokens or keys aren’t retired, the system quietly favors them.”
The issue isn’t simply about weak passwords. It’s about the persistence of legacy authentication methods and the failure to enforce a principle of least privilege. Many projects, like Axios, have adopted modern security practices, but haven’t fully addressed the risks associated with long-lived tokens. These tokens, while convenient for developers, represent a single point of failure that can undermine the entire security posture.
Technical Deep Dive: The RAT Payload and C2 Infrastructure
The RAT payload deployed by the attackers is a cross-platform executable designed to provide remote access to compromised systems. StepSecurity’s analysis revealed platform-specific payloads pre-built for macOS, Windows, and Linux. On macOS, the RAT resides in /Library/Caches/com.apple.act.mond. Windows systems see it at %PROGRAMDATA%wt.exe, and Linux machines have it at /tmp/ld.py. The malware is designed to erase itself after execution and replace the package.json file with a clean version, hindering forensic investigation. The command-and-control (C2) infrastructure used by the attackers consists of the domains sfrclak.com and the IP address 142.11.206.73. Blocking these domains and IP addresses is a critical first step in mitigating the impact of the attack.
What This Means for Enterprise IT
The Axios compromise underscores the systemic risks inherent in modern software supply chains. Organizations relying on Node.js should immediately assess their exposure and take steps to mitigate the damage. This includes searching lockfiles and CI logs for the compromised Axios versions (1.14.1 and 0.30.4) and pinning to known-good versions (1.14.0 and 0.30.3). If a compromised version is detected, a full rebuild of affected machines from a known-good state is essential, along with a complete rotation of all accessible credentials – npm tokens, cloud keys, SSH keys, and CI/CD secrets.
Beyond immediate remediation, enterprises should adopt a more proactive approach to supply chain security. This includes enforcing npm ci --ignore-scripts in CI/CD pipelines to prevent the execution of malicious postinstall scripts, requiring lockfile-only installs, and rejecting packages missing provenance from projects that previously had it. Organizations should audit their own publishing workflows to ensure that legacy tokens are not coexisting with OIDC credentials.
The Ecosystem Response and Future Mitigation
The npm ecosystem has responded swiftly to the Axios compromise. Socket, Snyk, and Aikido have implemented automated scanning to detect and block the malicious packages. However, the detection-to-removal gap remains a concern, with initial infections detected within 89 seconds of publication, while registry removal took several hours. This highlights the need for faster response times and more robust security controls at the registry level.
According to a statement from a security engineer at a major financial institution (who requested anonymity), “We’ve been advocating for mandatory provenance attestation for years. The fact that a malicious package with no provenance could slip through the cracks demonstrates a fundamental weakness in the current system. Npm needs to enforce this requirement, not just offer it as an opt-in feature.”
The long-term solution lies in a shift towards more secure software supply chain practices. This includes mandatory provenance attestation, multi-party signing, and the elimination of long-lived tokens. Npm has signaled its intention to address these issues, but progress has been slow. Until these changes are implemented, the risk of similar attacks will remain high. The Axios incident serves as a stark warning: the software supply chain is a critical vulnerability, and organizations must take proactive steps to protect themselves.
The Canonical URL
The original reporting on this incident can be found at Axios.
A Table of npm Defenses and Attack Bypasses
| What SOC Leaders Need | npm Defense Shipped | vs. Axios Attack | The Gap |
|---|---|---|---|
| Block stolen tokens from publishing | FIDO 2FA required. Granular tokens, 7-day expiry. Classic tokens deprecated | Bypassed. Legacy token coexisted alongside OIDC. Npm preferred the token | No enforcement removes legacy tokens when OIDC is configured |
| Verify package provenance | OIDC Trusted Publishing via GitHub Actions. SLSA attestations | Bypassed. Malicious versions had no provenance. Published via CLI | No gate rejects packages missing provenance from projects that previously had it |
| Catch malware before install | Socket, Snyk, Aikido automated scanning | Partial. Socket flagged in 6 min. First infections hit at 89 seconds | Detection-to-removal gap. Scanners catch it, registry removal takes hours |
| Block postinstall execution | –ignore-scripts recommended in CI/CD | Not enforced. Npm runs postinstall by default. Pnpm blocks by default; npm does not | postinstall remains primary malware vector in every major npm attack since 2024 |
| Lock dependency versions | Lockfile enforcement via npm ci | Effective only if lockfile committed before compromise. Caret ranges auto-resolved | Caret ranges are npm default. Most projects auto-resolve to latest minor |
