axios npm Compromise: The Ultimate Supply Chain Scaries

The axios npm supply chain compromise in March came to light as many security incidents do: a post on X in the middle of a Monday night. 

“Need someone from npmjs security team to dm me NOW,” tweeted Elastic’s tech lead Joe Desimone.

The urgency of the message was warranted. As it turned out, a major supply chain compromise had hit the axios npm package, one of the most widely used JavaScript libraries (think 100 million weekly downloads). 

The two compromised versions ([email protected] and [email protected]) were removed within three hours, but this window was still enough to impact many organizations that were dependent on the package (Huntress alone observed at least 135 endpoints across all operating systems contacting the attacker's command-and-control infrastructure during the exposure window). Attackers were able to deliver malware to macOS, Windows, and Linux systems through the malicious dependency that had been injected into the backdoored axios releases. 

In the hours that followed, security researchers – including Huntress’ own John Hammond – unraveled the widespread attack in the best way they knew how – tracking indicators of compromise (IoCs) across incidents, creating detections, and piecing together attackers’ tradecraft to figure out how victim organizations had been impacted. 

Two weeks later, at Huntress’ April Tradecraft Tuesday on April 14, Hammond (senior principal security researcher) was joined by three others who played their own parts in piecing together this massive attack, and the broader risks tied to supply chain security threats overall: Ben Read, director of strategic intelligence with Wiz, Charlie Eriksen, security researcher with Aikido Security, and Logan MacLaren, staff offensive security engineer with Huntress. 

A quick TL;DR into the incident

So what happened? In case you didn’t see the news headlines the entire week of March 30, here’s a quick breakdown. 

Let’s start with the very basics: npm (short for Node Package Manager) is a software component library for the JavaScript ecosystem. At the most basic level, npm is the tool that lets developers “borrow” pre-written code for their applications. 

This is all well and good for developers who don’t want to write their apps from the ground up, but over time it has created a massive ecosystem of packages depending on even more packages - sometimes even five or six layers deep. This sets the stage for a very dangerous “blast radius” if someone is able to upload a malicious package, which is then pushed to these other downstream dependencies.

Figure 1: A Huntress Rapid Response blog broke down a timeline of the attack 

That’s exactly what happened when a threat actor gained access to the jasonsaayman npm account (the primary maintainer of the axios library). From there, attackers manually published the two backdoored releases.  For the countless packages, developer workstations, and CI/CD pipelines that depended on axios and ran npm install during this three-hour timeframe, it meant that the malicious payload was executed. Automatically. 

Various researchers have pointed to links in the attack to DPRK infrastructure, with Google attributing the incident specifically to UNC1069, a financially motivated North Korean threat actor active since at least 2018. The malicious payload in the attack was a RAT with cross-platform payload capabilities, which allowed for system reconnaissance, credential harvesting, and remote command execution. This in itself was notable, as historically npm supply chain attacks frequently led to cryptocurrency mining malware.

Hunting season for the bad guys

Supply chain compromises in the open source ecosystem are not new by any means, but we’ve seen an inflection point over the past year involving several massive attacks specifically hitting npm accounts. On top of all this, LLMs are making attacks more seamless by enabling threat actors to more easily mix and match their techniques. 

Some examples have stood out in particular: 

• In September 2025, Josh Junon (a developer known as “qix”)  was targeted by a phishing email that hit his npm account, which in turn led to the compromise of 18 very popular npm packages. In that case, the piece of code shipped out to the packages was targeting crypto transactions on various blockchains. 
• Also in September 2025, a self-replicating worm called Shai-Hulud tore through the npm ecosystem. The malware’s credential harvesting capabilities raised eyebrows, because this then meant that attackers could potentially use the stolen credentials to infect further packages.
• In March 2026, TeamPCP compromised Aqua Security’s popular open-source Trivy vulnerability scanner, which then led to several downstream attacks (and later spreading to the npm ecosystem with a worm that used stolen publish tokens). 

Shai-Hulud in particular used techniques that can only be described as “chaotic evil.” The malware first checked for GitHub tokens in victim environments, and then would use that token to upload whatever secrets they found on the machine on GitHub – unencrypted. 

As Aikido Security’s Eriksen said, if you’re a threat actor using this tactic, “you want to see the world burn.”

The trust problem 

At the end of the day, open source security challenges come down to trust. Attackers rely on trust by using social engineering techniques to target maintainers before compromising their accounts. This is the new normal – and it was on full display during the axios npm attack:

• axios maintainer Jason Saayman said in a post-mortem report that the actors behind the incident approached him pretending to be the founder of a company
• They then sent an invite to a fake Slack workspace, which was appropriately branded, and included realistic channels, team members and posts. 
• They then invited Saayman to a scheduled Microsoft Teams call, which had “what seemed to be a group of people that were involved.” 
• While on the call, the threat actor said something on Saayman’s system was out of date and prompted him to install an item to fix the issue – a ploy which Huntress researchers have seen in other social engineering attacks. Unbeknownst to Saayman, the install led to the RAT.

Figure 2: axios maintainer Jason Saayman talked about the attacker’s social engineering tactics

But even beyond initial access, the entire open source ecosystem is built on a foundation of trust. Developers often assume that because a package is popular or widely used, it has been thoroughly vetted. Many developers pull down packages based on name and utility without verifying the identity of the maintainer or the integrity of the code.

To break this cycle, there are a few critical steps that maintainers, developers, and end users can take that might help mitigate against a future open source supply chain attack:

• Rather than automatically pulling the latest version of a dependency, developers should "pin" their dependencies to specific, verified versions and use a private repository or "quarantine" area to vet new versions before they are used in production.
• Developers should set time of “age-based” restrictions for new package versions, so that the industry can evaluate and respond to the versions first. 
• Make sure all dependencies (from systems to accounts) are as trustworthy as the high-privilege object they’re accessing (this is also known as the Clean Source Principle). Know what’s in your software.

Like what you just read? Join us every month for Tradecraft Tuesday, our live webinar where we expose hacker techniques and talk nerdy with live demos. Snag your spot now!