Axios Supply Chain Attack Pushes RAT Malware Through npm Install

An axios supply chain attack briefly turned one of the JavaScript ecosystem’s most trusted packages into a malware delivery vehicle after poisoned npm releases pulled in a malicious dependency designed to execute code during installation.

The incident centered on two Axios versions, axios@1.14.1 and axios@0.30.4, which were published to npm with a new dependency, plain-crypto-js@4.2.1. According to Socket, that package did not appear in Axios’ normal release flow and was published just minutes before the compromised Axios versions went live. Any project using broad version ranges such as ^1.14.0 or ^0.30.0 risked pulling the poisoned release on its next install.

That is what made the attack especially dangerous. Developers did not need to run some sketchy package from an unknown publisher to get hit. They only needed to install or update Axios through npm.

Socket’s analysis says plain-crypto-js@4.2.1 was malicious and used npm’s postinstall hook to launch a multi-stage infection chain. The package reportedly deployed platform-specific payloads for Windows, macOS, and Linux, contacted attacker-controlled infrastructure, and then attempted to cover its tracks by deleting the malicious installer and restoring a clean-looking package file. In other words, this was not a suspicious dependency sitting quietly in a tree. It was malware built to execute, persist, and hide.

The company said the release pattern itself was another major red flag. Axios normally publishes tagged releases through its visible GitHub workflow, but the poisoned versions did not appear in the project’s official tags at the time Socket published its findings. That suggested the malicious release happened outside the project’s normal process, reinforcing fears that a maintainer account or publish path had been compromised.

Socket also reported that Axios maintainers appeared unable to immediately regain control of the account responsible for the malicious publish. In a public GitHub issue referenced by the company, a collaborator reportedly said the attacker’s permissions exceeded their own, making remediation difficult without npm intervention.

Technically, the attack was simple in one place and sophisticated in another. The change to Axios was minimal. The attacker did not need to rewrite large sections of a widely used package. Instead, the poisoned release added one malicious dependency and let npm do the rest. That is a familiar supply chain tactic because a small diff can be easy to miss while still creating a serious compromise path through transitive dependencies.

The malicious plain-crypto-js package appears to have done the heavy lifting. Socket said its scanner found a setup.js dropper executed by postinstall, obfuscated strings hiding the command-and-control infrastructure, platform checks for Windows, macOS, and Linux, and delivery logic for different second-stage payloads. On macOS, researchers captured a second-stage RAT capable of fingerprinting the infected machine, beaconing back to a remote server, executing shell commands, running AppleScript, and deploying additional binaries.

The broader lesson is the one developers keep learning the hard way. The trust problem in open source is no longer just about obviously fake typosquats or abandoned packages. Popular packages with enormous install counts can still become attack channels if a maintainer account, release token, or publish workflow is compromised.

That is why the reaction across the JavaScript community was so immediate. Axios is not some obscure utility package with a few thousand weekly downloads. It is deeply embedded across front-end apps, back-end services, enterprise projects, internal tooling, and automated pipelines. Once a package that common is poisoned, the blast radius is not limited to one team or one ecosystem niche.

For defenders, the response is more serious than simply downgrading and moving on. Any environment that installed the affected Axios versions needs to be treated as potentially compromised, especially if the install happened in CI/CD, build systems, or developer machines with access to secrets. Teams should review lockfiles, CI logs, and dependency trees for axios@1.14.1, axios@0.30.4, and plain-crypto-js@4.2.1, then investigate whether installation occurred before the bad releases were removed.

The axios supply chain attack is the kind of incident that rattles developers because it shows how little friction attackers need when they can hijack trust instead of code. No flashy exploit chain was required. No one had to be tricked into downloading obvious malware from a shady website. A routine npm install was enough.

That is the real story here. Axios was briefly weaponized through npm, and a widely trusted package update became a malware delivery path.