Axios npm Supply Chain Attack: How a Fake Meeting Compromised 100 Million Downloads

Axios, the JavaScript library with over 100 million weekly downloads, was compromised on March 31st. For roughly three hours, every fresh install of those two versions silently dropped a remote access trojan on the machine that ran it. Windows, macOS, and Linux, all targeted. The installation completed normally, nothing flagged the change, and the backdoor was already running by the time the command finished. 😏

Axios is a JavaScript HTTP client that developers use to send web requests from their applications. It ships inside frontend frameworks, backend services, mobile apps, and CI/CD pipelines, and if a company runs Node.js anywhere in their stack, Axios is almost certainly somewhere in that dependency tree. That is what made this attack so significant.

What happened did not start with a code vulnerability. The attackers went after the lead maintainer of the project directly, reaching out weeks before the attack under the guise of a company founder. They had built a complete fake identity around a real, legitimate company: cloned branding, a Slack workspace with what looked like active channels, fake team members sharing the real company’s LinkedIn posts, and fake profiles for other open-source maintainers to make the whole thing look credible. The entire setup had been tailored specifically to one person, and it worked well enough that a Microsoft Teams meeting was scheduled.

During the call, a prompt appeared saying something needed to be updated to continue. This is a technique known as ClickFix, where a fake error or update message is used to get someone to willingly run something malicious themselves. No exploit needed, no forced execution. The target just clicks, installs, and hands over full access without realizing it. The maintainer installed what he believed was a missing software component, which turned out to be a remote access trojan (RAT) that gave the attackers complete control over his machine. Two-factor authentication was enabled, but that does not help once a RAT is running, because software-based 2FA is just another application on the system at that point. The attackers used his account to change his npm email to a Proton Mail address they controlled, then grabbed the long-lived access token sitting alongside his OIDC credentials and waited for the right moment.

The preparation had actually started 18 hours before the attack itself. A clean, harmless version of a package called plain-crypto-js was published to npm first, doing nothing except establishing a history on the registry, because a brand-new package with no history raises flags and this one needed to look like it had been around.

At 00:21 UTC on March 31, the first malicious Axios version went live, and at 01:00 UTC the second followed. Both the latest and legacy branches were hit within 39 minutes, which meant projects using either the current or the older API were both exposed. The malicious Axios versions listed plain-crypto-js@4.2.1 as a dependency, and when npm processes dependencies it runs postinstall hooks automatically without prompting. Installing Axios pulled in plain-crypto-js, which immediately executed a script in the background that checked the operating system and downloaded the appropriate payload from a command-and-control server. The developer never had to do anything extra. The install just ran.

Three RAT builds were waiting, one for each platform, all sharing the same command structure, the same C2 protocol, and the same beacon behavior. Depending on the operating system, the malware drops its artifact in a different location:

• → Windows: %PROGRAMDATA%\wt.exe
• → macOS: /Library/Caches/com.apple.act.mond
• → Linux: /tmp/ld.py

The malicious packages stayed live for approximately three hours before the npm security team removed them, and during that same window the attacker was using the compromised account to quietly delete the community reports flagging the attack as it was happening.

There is one technical detail worth highlighting. Every legitimate Axios release since 2023 was published through GitHub Actions with OIDC Trusted Publishing, which links each npm package to a verifiable build record. The malicious versions had none of that. They were pushed directly from the command line with a stolen token, leaving no provenance trail, and that absence alone was a signal the moment the packages appeared for anyone monitoring supply chain integrity.

This attack is also not an isolated incident. In the two weeks before Axios was hit, four other widely used developer tools were compromised in rapid succession: a vulnerability scanner, an infrastructure-as-code scanner, an AI proxy library, and a communications library. Whether the same group was behind all of them is not confirmed, but the pattern of targeting developer tooling and pushing malicious versions through legitimate accounts is consistent across all five incidents.

Most security tools, pentesting frameworks, and automated scripts run on Node.js. If you build tools, run pipelines, or have anything in your stack that uses JavaScript, this is relevant to you.

Here is what to check.

• → Open your package-lock.json and search for axios@1.14.1 or axios@0.30.4
• → Search the same file for any mention of plain-crypto-js
• → If either shows up, treat the machine as fully compromised
• → Downgrade to axios@1.14.0 or axios@0.30.3 and pin that version
• → Check for the RAT artifacts listed above for your operating system
• → If any artifact is found, do not try to clean the system, rebuild from a known-clean snapshot
• → Rotate every credential that was on the affected machine: npm tokens, API keys, SSH keys, cloud credentials, GitHub tokens, .env files, all of it
• → Review CI/CD pipeline logs for any npm install that ran between 00:21 and 03:20 UTC on March 31

Quick terminal check:

1
2

grep -A3 '"axios"' package-lock.json
grep 'plain-crypto-js' package-lock.json

The attack that made this possible was not technical. It was social engineering. A fake company, a fake meeting, a fake software update. That is what handed over access to a package with 100 million weekly downloads.

I cover social engineering in depth in my complete ethical hacking course, including the psychology behind it, how these attacks are built, and how to recognize them:

• → Join my complete ethical hacking course

(The link supports me directly as your instructor!)

The attack surface in modern software development is not only your own code. It is every library your code depends on, every library those libraries depend on, and the humans who maintain them. Solid code and solid security practices still leave exposure through a dependency that nobody looked at twice and a maintainer nobody had ever heard of.

Hacking is not a hobby but a way of life.