On March 31, 2026, one of the most widely used JavaScript libraries in the world became the center of a serious software supply-chain incident. Axios, a package used across countless frontend apps, backend services, CLIs, and CI pipelines, was not hit by a normal vulnerability. It was hit by something worse: a malicious package publication through a compromised maintainer account.
The attacker published two poisoned Axios versions to npm: axios@1.14.1 and axios@0.30.4. Those releases were not just buggy. They were weaponized. Anyone who installed them during the short time they were live may have executed malware on the machine doing the install.
That is the part people need to understand clearly. This was not about a bad HTTP client bug. This was about trust in the package distribution pipeline itself.
Why this incident matters
Axios is not some obscure dependency buried in a niche ecosystem. It is one of the most heavily used packages in JavaScript, with reporting placing it at roughly 100 million weekly downloads. When a package that common gets compromised, even a short-lived malicious release can have real consequences across developer laptops, CI runners, internal build systems, and production deployment pipelines.
This is what makes software supply-chain attacks so dangerous. Attackers do not need to break into your app directly if they can slip malicious code into the tools and libraries you already trust.
What actually happened
Based on public reporting from security researchers and incident write-ups, the attacker appears to have gained access to an Axios maintainer's npm publishing account and used that access to release two malicious versions of the official package. Public reports consistently identify those versions as 1.14.1 and 0.30.4.
The most important technical detail is that the attacker did not need to visibly rewrite Axios's source in an obvious way. Instead, the malicious releases added a hidden dependency: plain-crypto-js@4.2.1. That dependency was used as the delivery mechanism. Once npm pulled it in, its install behavior triggered a malicious chain that dropped a cross-platform remote access trojan, affecting macOS, Windows, and Linux.
That means the real danger was at install time. A developer could do a routine dependency update or a fresh CI build, never import Axios in a running application, and still end up executing malicious code.
The timeline, in plain English
Here is the broad story as reconstructed from public reporting.
First, the attacker prepared the dependency path. Security write-ups describe plain-crypto-js as a staged package that later became the malicious dependency used in the poisoned Axios releases.
Then the attacker published the compromised Axios versions. Snyk reports that axios@1.14.1 was published at 00:21 UTC on March 31, 2026, and axios@0.30.4 followed at 01:00 UTC. Researchers and community members quickly noticed that something was wrong, raised the alarm publicly, and coordinated disclosure. Elastic says it filed a GitHub Security Advisory for Axios at 01:50 UTC to help trigger response and containment.
The malicious Axios versions were then removed from npm. Snyk says both were taken down by 03:29 UTC, which means the malicious window lasted only a few hours. That short window helped reduce the blast radius, but it did not eliminate it. Any system that installed those versions during that time should still be treated as potentially compromised.
Why this attack worked
Attacks like this succeed because modern development depends heavily on automation and trust.
Developers trust package registries. CI pipelines trust lockfiles and install commands. Teams trust maintainers to protect publishing access. npm trusts that a published package is what it claims to be. In a healthy ecosystem, that chain works well enough most of the time. In a compromise like this, the attacker abused that trust at the exact point where the ecosystem is most vulnerable: the moment code gets pulled into your environment automatically.
What makes the Axios incident especially instructive is that it shows how little malicious code needs to be visible in the main package itself. A single injected dependency can be enough. If that dependency runs a postinstall flow or otherwise executes on install, the attack can jump from "bad package metadata" to "host-level compromise" almost instantly.
Why install-time malware is worse than a normal dependency bug
A normal vulnerable dependency usually becomes dangerous only when your application executes a vulnerable code path. That is serious, but it is still somewhat bounded. You patch the bug, review exposure, and move on.
Install-time malware is different.
If the payload runs during npm install, the compromised environment is not just your app. It can be the developer laptop, the build runner, the container build stage, or the CI worker. Those environments often have secrets available: cloud credentials, npm tokens, GitHub tokens, deployment keys, SSH material, API secrets, and access to internal package registries. That is why so many responders immediately advised potentially affected teams to rotate secrets, not just upgrade Axios.
When the installation environment is compromised, the attacker does not just get code execution. They may get a path deeper into your supply chain.
Who was affected
The key question is not simply, "Do you use Axios?"
The real question is, "Did any of your systems install axios@1.14.1 or axios@0.30.4 while those versions were live?" Public reporting consistently names only those two releases as compromised in this incident.
If your environment was pinned to older safe versions and your lockfile never resolved to those releases, this particular attack likely did not touch you. But if a laptop, CI runner, or build process pulled one of the poisoned versions during the exposure window, it should be investigated as a possible host compromise rather than treated as a routine dependency issue.
What developers and security teams should learn from this
The first lesson is that package popularity is not protection. In fact, popularity can make a package a more attractive target. A compromise in a package with huge adoption gives attackers scale.
The second lesson is that the publish path matters as much as the codebase. A secure GitHub repo means less if the maintainer account or the npm publishing workflow can be hijacked. The Axios story, as publicly understood right now, points to compromised maintainer-level access rather than a traditional code-review failure.
The third lesson is that CI should be treated as hostile terrain. Builds should not have more secrets than they need. Install jobs should be isolated. Fresh dependency resolution in high-privilege environments should make teams uncomfortable by default.
And the fourth lesson is the one most teams still underinvest in: dependency changes deserve the same scrutiny as application code changes. If a dependency suddenly introduces a package no one recognizes, that should be a review event, not background noise.
How to reduce the odds of getting burned next time
No defense is perfect, but this incident reinforces some practical controls that matter.
Use lockfiles and deterministic installs. Avoid letting CI float to newly published versions unless that change was reviewed intentionally. npm's documented install behavior around lockfiles and npm ci exists for a reason.
Review dependency diffs in pull requests, especially newly introduced transitive packages, odd lifecycle behavior, or dependency additions that make no architectural sense.
Minimize secrets in build environments. The less privilege a dependency install job has, the less damage an attacker can do.
Treat postinstall and lifecycle scripts with suspicion. If your environment can safely disable them for some workflows, that is often worth considering. The Axios incident shows exactly why install-time execution is such a dangerous attack surface.
For maintainers, harden publishing. Use strong 2FA, reduce token sprawl, prefer short-lived trusted publishing flows where possible, and monitor publish activity aggressively. Public reporting in this incident points to abuse of maintainer publishing access, which is exactly the scenario those controls are meant to reduce.
The bigger picture
The Axios compromise is part of a broader reality in software security. Attackers increasingly go after the spaces between teams: package registries, CI systems, maintainer accounts, release pipelines, and dependency graphs. Those are the seams of modern software development, and they are often softer than production systems themselves.
This is why supply-chain security keeps moving from "nice to have" to core engineering discipline. The real asset attackers want is often not the library. It is the trust relationship around the library.
Axios just made that painfully visible.
Final takeaway
This incident should not cause panic, but it should reset a few assumptions.
- A trusted package can become untrusted quickly.
- A short exposure window can still be enough.
- A dependency install can be a compromise event.
- And "we use popular libraries" is not the same thing as "we are safe."
The right response is not fear. It is tighter process, better visibility, better publishing hygiene, and less blind trust in automation.
Credits
Credit to StepSecurity for early reporting and technical breakdown of the malicious releases and delivery chain.
Credit to Aikido for its write-up on the maintainer-account hijack angle and practical guidance on checking exposure.
And thanks to John Hammond for covering the Axios compromise quickly and helping spread awareness fast across the security and developer communities, and to all the other researchers who sounded the alarm.
More sources:
- CrowdStrike — Stardust Chollima attribution and technical analysis of the compromise
- Google Cloud Threat Intelligence — North Korea threat actor targeting the Axios npm package
Update Apr 4:
The attacker targeted Axios lead maintainer Jason Saayman with a highly convincing impersonation campaign. According to the reporting and the maintainer’s account, they pretended to be a real company, copied its branding, invited him into a fake-but-believable Slack workspace, and made it look populated with real employees and even other open-source maintainers. From there, they scheduled a Microsoft Teams meeting. The key trick was a fake Teams/RTC connection error used to push the victim toward installing something they believed would fix the call issue. BleepingComputer says another maintainer targeted in the same campaign shared a screenshot of that fake error flow. The Axios post-mortem says this social engineering led to the maintainer installing malware on his machine. Once that malware was on the maintainer’s system, the attacker gained access to the credentials or session needed for the maintainer’s npm publishing account. Datadog’s analysis says the malicious Axios versions were not published through the project’s normal GitHub Actions trusted publishing flow, but directly from the compromised maintainer account session instead. That is one of the strongest technical signs this was an account takeover rather than a source repository compromise. After taking over the npm publisher account, the attacker released axios@1.14.1 and axios@0.30.4 on March 31, 2026. Those versions did not meaningfully change Axios application code. Instead, they added a new dependency, plain-crypto-js@4.2.1, which was made to look like the legitimate crypto-js package. That fake dependency carried the real payload. It used an install-time hook, specifically a postinstall script, so anyone who installed one of the bad Axios versions could automatically run attacker code during npm install or similar package manager operations. Microsoft says this was designed to fetch a second-stage RAT from attacker-controlled infrastructure, with platform-specific payloads for Windows, macOS, and Linux. A subtle part of the operation was staging the fake dependency ahead of time. Microsoft and Snyk both describe plain-crypto-js@4.2.0 as a clean or less suspicious initial release, followed by 4.2.1 with the malicious install logic. That suggests the attacker wanted the package to have some history before weaponizing it, probably to reduce suspicion. The malicious Axios versions were live only for a short window, roughly about three hours, before they were removed from npm. But because Axios is so widely used, any developer workstation, CI runner, or build pipeline that pulled those exact versions during that window should be treated as potentially compromised. Axios maintainers and security researchers recommend rotating credentials and secrets if those versions were installed.
So the cleanest way to say how it happened is:
- They social-engineered a maintainer with a fake company + fake collaboration setup.
- They used a fake Teams error/fix flow to get malware onto the maintainer’s machine.
- That gave them access to the maintainer’s npm publishing capability.
- They published official-looking Axios releases that quietly added a malicious dependency.
- The malicious dependency executed during install and dropped a cross-platform RAT.
One more point: attribution is not just rumor at this stage. Google Threat Intelligence linked the activity to UNC1069, a North Korea-linked financially motivated actor, and Microsoft separately attributed the infrastructure and compromise to Sapphire Sleet, which is also a North Korean state-linked tracking label. Different vendors use different names, but both are pointing in the same broad direction.