Axios Was Just Compromised

What Happened

‍

Two malicious versions of Axios - one of the most widely used JavaScript HTTP client libraries - were published to npm through a compromised maintainer account. Versions 1.14.1 and 0.30.4 deployed a cross-platform remote access trojan to macOS, Windows, and Linux systems within 15 seconds of installation.

‍

Both major release branches were poisoned within 39 minutes. The payload contacted command-and-control servers and delivered platform-specific malicious code. The attack then erased itself and replaced package.json with a clean version, leaving no traces in node_modules.

‍

Why Traditional Security Controls Failed

‍

This attack would have passed every traditional supply chain security check with flying colors:

‍

• SBOM: The software bill of materials would correctly list Axios as a dependency - it is a legitimate package. An SBOM describes inventory, not behavior. It cannot distinguish between a clean version and a compromised one performing the same function while silently deploying malware.
• SLSA Provenance: The package was published through the legitimate npm publishing pipeline by a valid (compromised) maintainer account. Provenance attestations verify where code came from and how it was built - not what it does after installation.
• Digital Signatures: The package was signed with valid credentials. Signature verification confirms identity and integrity at rest. It says nothing about runtime behavior.

‍

Every one of these controls verifies what a package is. None of them verify what a package does.

‍

The Runtime Enforcement Gap

‍

The Axios compromise is a textbook example of the runtime enforcement gap. The malicious payload performed three categories of unauthorized activity that are invisible to static inventory tools but immediately visible at the kernel level:

‍

• Unauthorized network connections: The payload contacted external C2 servers during npm install - a phase where a legitimate HTTP client library has zero reason to make outbound network connections.
• Unauthorized file operations: The payload wrote platform-specific binaries to disk and then cleaned up after itself, modifying package.json to erase evidence.
• Unauthorized process execution: The payload spawned new processes to execute the downloaded RAT binary - completely outside the expected behavior of a JavaScript library installation.

‍

What Endura Would Have Seen

‍

An Endura Runtime Sensor deployed on the build infrastructure would have captured every stage of this attack as it happened:

‍

During npm install, the sensor would observe the node process spawning unexpected child processes and making outbound network connections to unknown hosts. These events would be captured with full process ancestry and argument context, clearly distinguishing them from legitimate npm registry traffic.

‍

The file writes - downloading a platform-specific binary, writing it to disk, and then modifying package.json - would each be recorded as filesystem events with the offending process chain intact. The subsequent self-erasure would itself be flagged as anomalous: a post-install script modifying its own package metadata is not normal behavior.

‍

A policy as straightforward as "during npm install, no process may make outbound connections to hosts other than the npm registry" would have blocked this attack entirely.

‍

Immediate Actions

‍

If your build infrastructure ran npm install during the window when the compromised Axios versions were available, you should assume full compromise. Credential rotation is necessary but not sufficient - rebuild from scratch.

‍

The Broader Pattern

‍

The Axios attack follows an accelerating pattern of supply chain compromises targeting widely-used packages through maintainer account takeover: ua-parser-js (2021), tj-actions/changed-files (2025), Trivy (2026), and now Axios.

‍

Each attack confirms the same lesson: static security controls that verify identity, provenance, and inventory are necessary but fundamentally insufficient. The only way to detect and prevent runtime attacks is to monitor and enforce at runtime - at the kernel level, where malicious behavior cannot hide.

‍

Learn how Endura Security's eBPF-based platform provides runtime enforcement across your CI/CD pipelines and production workloads. Request a demo to see how kernel-level policy enforcement blocks credential theft, unauthorized network connections, and anomalous process execution, even when the compromised component is a package you trust.