Axios Maintainer Confirms Social Engineering Attack Behind npm Compromise

5 min read Original article ↗

Sidebar CTA Background

Secure your dependencies with us

Socket proactively blocks malicious open source packages in your code.

Install

On March 31, two malicious versions of Axios were briefly published to npm, introducing a dependency that installed a remote access trojan across macOS, Windows, and Linux.

We covered the initial attack and its scope earlier, as well as a deeper technical analysis of its hidden blast radius and how dependency resolution expanded its impact exponentially.

Now, the project’s lead maintainer has shared additional details about how the compromise occurred.

In a comment on GitHub, Axios maintainer Jason Saayman explained that the attack was the result of a targeted social engineering campaign.

He reported that the attacker posed as a legitimate, well-known company interested in collaboration, ultimately gaining access to the maintainer’s machine. From there, he believes they were able to hijack active sessions and take control of both npm and GitHub access.

At that point, the attacker effectively had the same permissions as the maintainer. Nothing in the publishing pipeline would have prevented a malicious release, including protections like 2FA or OIDC-based publishing, because the attacker was operating with the maintainer’s own access. With control of his environment, they could publish as if they were the legitimate maintainer.

In response to questions, Saayman said the attacker had “enough access to hijack from my browser… lifting sessions or cookies.”

In a follow-up comment on the post-mortem, Saayman described how the attack was carried out, outlining a coordinated social engineering campaign involving cloned company identities, a convincing Slack workspace, staged meetings, and ultimately a malicious install that provided remote access.

The Burden on Solo Maintainers as Supply Chain Targets#

Saayman described the compromise candidly, noting that he “fell victim to what seems to be a pretty well known… social engineering attack.”

He emphasized that the attacker’s access would likely have been “complete irrespective of what was setup,” given the level of control they gained over his machine.

Following the incident, he wiped all devices, reset all credentials, and began adopting additional security measures, including hardware security keys and improved publishing workflows.

The Axios compromise echoes, in a different form, the kind of long-game approach seen in incidents like the xz utils backdoor, where attackers invested time in establishing credibility before exploiting that position.

This is where the security of the ecosystem relies on the personal security of individual maintainers, many of whom are working alone, maintaining widely used infrastructure with limited support.

"It is sad to me that zero trust can be put in people as my only objective is to create useful things with code but it seems like the world is strongly against that with someone trying to steal / exploit something at every corner," Saayman commented on GitHub. "My countries philosophy is 'Ubuntu' - 'I am because we are' or 'humanity towards others.' I hope that more can embrace that in the future."

It’s hard to overstate how widely used Axios is across the JavaScript ecosystem. It sits deep inside build systems, CLIs, infrastructure tooling, and production applications, often several layers down, pulled in transitively and out of sight. For many teams, it’s not something they chose. It’s simply there, quietly powering requests across the stack. And like many projects of that scale, it is maintained by a small number of individuals.

Many engineers at Socket maintain open source projects themselves, and we are intimately familiar with the realities of that work. The expectations are the same, whether you capture corporate funding or continue maintaining a critical piece of infrastructure on your own time.

Maintainers are expected to:

  • manage releases
  • review contributions
  • respond to issues
  • handle security
  • and defend against increasingly sophisticated attacks

These expectations usually co-exist without dedicated security resources or institutional support. That pressure accumulates over time, often invisibly, and it does not just affect the software.

In a recent essay titled "Open source gave me everything until I had nothing left to give," the creator of Python’s widely used Requests library described the personal cost of maintaining critical infrastructure at scale: from constant expectations and blurred boundaries to the way identity becomes entangled with the project itself.

“The same intensity that produced Requests produced the conditions for the worst experiences of my life," Kenneth Reitz said.

"The engine was the same. It just had two outputs: beautiful software and shattered minds."

This is the environment these projects operate in: high expectations, constant demand, and little separation between the work and the person doing it.

This attack did not exploit a flaw in Axios itself. It exploited the ecosystem's trust, the maintainer's access, and the human layer of the software supply chain.

Open source maintainers are high-value targets. Supporting them requires more than better tooling or stricter controls. It requires treating maintainers as critical infrastructure themselves, with the time, boundaries, and support systems needed to sustain that role.

We have witnessed this pattern in security for years. When access to a widely used package is enough to reach the supply chain, attackers will go after the maintainer to get it.

This is another instance of that kind of exploitation, and a stark reminder of the human cost of maintaining critical infrastructure.