Axios Maintainer Confirms The npm Compromise Was via a Targeted Social Engineering Attack

Two malicious versions of the popular JavaScript HTTP library Axios were briefly published to the npm registry on March 31, 2026.

Each version carried a hidden dependency that installed a remote access trojan (RAT) across macOS, Windows, and Linux systems. The attack did not exploit a flaw in the Axios code itself.

Instead, it targeted something far harder to defend — the trust placed in the hands of the developer who maintains it. What followed exposed just how fragile the human layer of the open source supply chain can truly be.

The attacker executed a carefully planned social engineering campaign against Axios lead maintainer Jason Saayman. They posed as a representative of a legitimate, well-known company and made contact under the pretense of a business collaboration.

To build believability, the attacker created a cloned company identity, set up a convincing Slack workspace, and arranged several staged meetings.

Once Saayman’s trust was earned, the attacker convinced him to install something on his machine that gave them full remote access.

From there, they lifted active browser sessions and stole cookies, quietly hijacking his npm and GitHub credentials without setting off any security alarms.

Researchers at Socket.dev identified the malicious packages shortly after they went live on npm and conducted a thorough analysis of the attack’s full scope.

They found that the damage extended well beyond direct Axios users. Because of how npm handles transitive dependencies, thousands of downstream packages that silently pull in Axios were also exposed.

The reach of the attack was significantly wider than it first appeared, making it one of the more understated but broadly damaging supply chain incidents in recent memory. 

What made this especially difficult to prevent was that even strong security controls — including two-factor authentication and OIDC-based publishing — would not have stopped it.

The attacker was working directly from within Saayman’s compromised machine, using his own active sessions. From npm’s perspective, every action looked completely legitimate.

Saayman later confirmed that the attacker’s access would have been “complete irrespective of what was setup,” because no publishing pipeline is built to detect a legitimate maintainer acting maliciously from their own device.

Axios is one of the most downloaded packages in the entire JavaScript ecosystem, quietly powering HTTP requests across production apps, build systems, CLI tools, and infrastructure layers.

Most teams never made a conscious choice to use it — it arrived through other dependencies, layers deep. Yet this globally critical project is maintained by a very small number of individuals, operating without institutional security resources or any dedicated support. That difficult reality became impossible to ignore.

When the Maintainer Becomes the Target

After the incident, Saayman moved quickly. He wiped all his devices, reset every credential, and began adopting hardware security keys alongside improved publishing workflows.

In a public GitHub comment, he acknowledged falling victim to “a pretty well known social engineering attack” and was candid about how thoroughly the attacker had taken over his environment. 

His response reflected both the weight of what happened and a genuine commitment to rebuilding more securely.

This attack mirrors a pattern seen before — most notably in the xz utils backdoor — where attackers invest real time in building credibility before making their move.

It is a long-game approach that purely technical controls cannot stop, because the entry point is the person, not the software. When reaching a maintainer means reaching the entire dependency tree below them, attackers will always treat that access as worth any effort.

Organizations using Axios should audit their dependency trees for the compromised versions 1.8.2 and 1.8.3 and update immediately. Developers should also use dependency scanning to catch unexpected version changes.

Open source maintainers — especially those managing widely used packages — should adopt hardware security keys, limit session exposure, and treat their own machines as high-value infrastructure targets.

Follow us on Google News, LinkedIn, and X to Get More Instant Updates, Set CSN as a Preferred Source in Google.