Axios supply chain attack explained

To explain the Axios npm suplly chain attack in non-technical terms, we’ll use an analogy.

Think of a mechanic who orders parts from a supplier they have used for years. The account of that supplier gets hijacked. The next batch of parts looks identical to every previous order, passes every check, and gets installed as normal. But one component has a hidden tracking device inside. The car drives fine, nothing looks wrong, but everything that happens in it is now being sent back to the attacker.

That is essentially what happened here, and the execution was planned roughly 18 hours before it went live to stay under the radar.

The attacker first published a seemingly legitimate package called plain-crypto-js to npm, the public registry where developers pick up ready-made code components. Seeding it early gave the package just enough history to avoid raising red flags with security scanners. Then, in the early hours of March 31st, they used stolen maintainer credentials to publish two backdoored versions of Axios (version 1.14.1 and version 0.30.4) within 39 minutes of each other.

The poisoned versions did not touch Axios’s own code at all. Instead, they quietly added plain-crypto-js as a dependency, a component Axios would automatically pull in during installation. That component ran a script the moment a developer installed Axios, with no prompt, no warning, and no user interaction required.

That script fetched a trojan tailored to the developer’s operating system, Windows, macOS, or Linux, which then connected to an attacker-controlled server and began harvesting whatever credentials it could find: cloud access keys, API tokens, SSH keys, database passwords. Credentials like these give an attacker access to production systems, cloud infrastructure, and codebases far beyond the machine they landed on.

The malware then deleted itself and restored a clean-looking package file. Any inspection after the fact showed nothing wrong, and standard security tools would find nothing. The compromise left no visible trace.

Huntress, a managed cybersecurity platform designed to protect small and mid-sized businesses, confirmed the first infections 89 seconds after the malicious package went live. By the time the poisoned versions were removed from npm roughly three hours later, at least 135 systems among Huntress customers alone had been compromised.

Why existing CI/CD pipeline security defenses did not catch it

What makes this attack so scary is that Axios had done the right things. Its releases were published through a verified, automated process using GitHub Actions and npm’s OIDC Trusted Publisher mechanism. This means it cryptographically ties every update to a known, trusted source, the digital equivalent of a tamper-evident seal on a package. The project had also adopted SLSA provenance attestations; a set of industry-standard guarantees confirming that what gets published is exactly what was built, with no interference in between.

By the standards of open-source security best practice, it looked solid.

The project’s publishing workflow still included a long-lived npm token as an environment variable, alongside its OIDC credentials. You can view this as an old access key, essentially a permanent password that had never been removed, sitting alongside all the modern security measures. When both exist, the system quietly falls back to the older one. So, the attacker never had to break through the modern defenses, they just used the spare key that was left under the mat.

This is a pattern we see repeatedly when we analyze software portfolios at Software Improvement Group (SIG). Organizations invest in the visible parts of their security posture — the scanners, the policies, the compliance checkboxes. But the underlying configuration, the environment variables that have been there for years, the tokens that were never rotated, the dependencies that have never been reviewed — that is where open-source dependency risk quietly accumulates.

It is part of a broader surge in supply chain attacks in March 2026. Separate from the TeamPCP campaign we covered in our LiteLLM supply chain attack explainer, this attack is attributed by Google’s Threat Intelligence Group to UNC1069, a financially motivated North Korea-nexus threat actor active since 2018. Two different threat actors, but in the same month and using similar methods.

The software portfolio visibility gap this attack exposed

The organizations that responded fastest to this incident already knew what was in their pipelines. They could immediately check whether the affected versions had been installed, assess what credentials might have been present, and act. The organizations without that visibility had to start from scratch, under time pressure, with credentials potentially already in attacker hands.

Software portfolios grow faster than the structures around them. Dependencies accumulate. Tokens persist. Transitive dependencies, the packages that your packages depend on, receive almost no scrutiny compared to the libraries your teams chose directly.

As the SANS Institute noted, the attack surface is your vendor’s vendor’s vendor. That is what this looks like in practice. Organizations with solid dependency pinning and a current software bill of materials (SBOM) were protected. Organizations relying on floating version ranges were not.

When we look at portfolios in Sigrid®, open-source dependency health is one of the clearest signals of organizational risk. Organizations with fresh, well-governed dependency trees respond to incidents like this quickly. Organizations without that visibility respond in days — sometimes weeks, sometimes long after the damage is done.

What to do now if your team uses Axios

The immediate actions are concrete. If your organization runs JavaScript-based software pipelines, these checks are worth doing now.

1. Check for affected versions

Axios versions 1.14.1 and 0.30.4, installed between March 31, 2026 at 00:21 UTC and approximately 03:29 UTC, are confirmed compromised. Any system where one of those versions was installed should be treated as fully compromised.

2. Rotate exposed credentials

Assume all credentials present on affected systems during that window have been stolen. That includes cloud access keys (AWS, Azure, GCP), npm tokens, SSH keys, API tokens, and environment variables. Rotate them all. Rebuild affected environments from a known-clean state rather than attempting to clean them.

3. Audit CI/CD pipelines

Review build logs for the March 31 window. Automated pipelines that pulled a fresh npm install, particularly overnight jobs that did not pin to a specific version, are the highest-risk environments.

4. Review your dependency pinning

Projects using a caret range like ^1.14.0 would have automatically resolved to the compromised version. Pinning to exact versions, or to verified commit hashes in your lockfile, removes that exposure. Wiz’s advisory also recommends auditing lockfiles specifically for the plain-crypto-js package.