In March 2026, attackers gained access to the npm maintainer account for Axios and published two poisoned versions: 1.14.1 and 0.30.4. Axios is one of the most widely depended-upon HTTP client libraries in the JavaScript ecosystem, used in frontend applications, backend services, and build tooling across millions of projects. The poisoned versions included a phantom dependency that deployed a fully functional cross-platform remote access trojan targeting macOS, Windows, and Linux. After execution, the RAT erased evidence of its own installation from the node_modules directory.
Elastic Security Labs analyzed the payload and published findings under the campaign name "One RAT to Rule Them All." The name is apt. Axios is so foundational that compromising it is less like attacking a package and more like attacking the build toolchain of the JavaScript ecosystem itself.
The Phantom Dependency Technique
The malicious versions did not obviously rewrite Axios's existing code. Instead, they added a phantom dependency: an innocuous-looking package name that resolved to an attacker-controlled registry endpoint. When npm install pulled the poisoned Axios version, it also pulled the phantom dependency, which contained the actual RAT payload. This separation serves two purposes. It keeps the diff of the Axios package itself small and hard to detect on casual review. It also allows the attacker to update the payload independently without republishing Axios.
Dependency auditing tools that check for known-vulnerable package versions would not catch this attack. The Axios version numbers themselves were not in any vulnerability database. The phantom dependency was not a known-bad package. Standard npm audit returned clean results.
RAT Capabilities and Anti-Forensics
The deployed RAT supported all three major operating systems via platform-specific payloads selected at install time based on the process.platform value. Core capabilities documented by Elastic:
- Persistent reverse shell with C2 beacon over HTTPS
- File system enumeration and exfiltration
- Credential harvesting from browser stores and keychain (macOS), DPAPI (Windows), and libsecret (Linux)
- Process injection on Windows via reflective DLL loading
- Self-erasure: removal of the phantom dependency directory from
node_modulespost-execution, leaving no package artifacts
The self-erasure step is significant. Post-incident forensics on a development machine or CI/CD runner would show a clean node_modules tree. The poisoned dependency would be gone. Without process-level telemetry capturing what ran during the install phase, the compromise would be invisible.
Systemic Implications for the JavaScript Ecosystem
Axios has over 50 billion total npm downloads. It is a transitive dependency in a massive fraction of JavaScript projects, meaning many teams would not even know they were pulling it. The attack did not require developers to explicitly choose a vulnerable version. Any project that resolved to the poisoned versions during the attack window, including through transitive dependency resolution, was exposed.
The JavaScript ecosystem's security model relies heavily on maintainer account integrity. When that breaks, there is no cryptographic signing requirement, no mandatory code review, and no publication delay to allow automated scanning before packages become available. The npm security team responded quickly after detection, but the window for initial distribution was sufficient for broad impact.
Pin all production dependencies to exact versions via a committed lockfile. Enable process-level telemetry on CI/CD runners to capture what executes during install phases. Use a private registry proxy with allow-list controls rather than pulling directly from the public npm registry. Consider Sigstore-based package signing where available.