Axios npm Supply-Chain Attack: How a Trojanized Release Turned a Web Workhorse Into a RAT Delivery System (and What to Do Now)

On March 31, 2026, the internet got a reminder that “dependency” is just another word for “trust fall.” Attackers briefly compromised axios, one of the most widely used JavaScript HTTP client libraries, by publishing malicious versions to the npm registry. Those releases pulled in a hidden dependency that executed a cross-platform remote access trojan (RAT) during installation—meaning that a routine npm install could have turned a developer laptop, CI runner, or build container into an attacker-controlled beachhead.

This article expands on the original reporting from VentureBeat (source and credit below) and cross-checks technical details with incident write-ups from security researchers and industry outlets. The key takeaway is not just “don’t install axios@1.14.1,” but rather: assume any build that ran during the exposure window needs incident response-level scrutiny, because supply-chain attacks don’t care whether your organization calls itself a startup, a Fortune 50, or “just a few scripts in a repo.”

Original RSS source: VentureBeat, “Hackers slipped a trojan into the code library behind most of the internet. Your team is probably affected” by Robert Lemos. Read the original.

What happened (in plain English, without the fairy tale ending)

Attackers gained the ability to publish new versions of axios to npm—reporting indicates this was done via a compromised maintainer account and/or a stolen long-lived token. Two malicious versions were published:

axios@1.14.1 (the “latest” line)
axios@0.30.4 (an older line still used in some environments)

Multiple analyses agree the core axios source code itself wasn’t meaningfully altered. Instead, the attackers added a new dependency—plain-crypto-js—that existed primarily to execute a malicious install-time script (the classic npm “postinstall surprise”). citeturn2search2turn2search6turn1search2

The malicious versions were available for only a few hours before being removed, but that’s plenty of time in modern CI/CD terms: lots of organizations rebuild containers, redeploy services, and refresh dependencies continuously. Datadog Security Labs reports the effective window as roughly 00:21 to 03:25 UTC on March 31, 2026. citeturn2search2

Why axios is such a high-impact target

Axios isn’t obscure plumbing. It’s the popular convenience layer for HTTP requests in Node.js and frontend tooling. It’s embedded directly or indirectly in enormous numbers of applications, build systems, and developer environments. That ubiquity makes it attractive to attackers for the same reason airports are attractive to advertisers: the foot traffic is unreal.

Even if your application doesn’t import axios explicitly, it may be a transitive dependency pulled in by frameworks, CLIs, SDKs, or internal tooling. And if your developers run npm install on laptops with cached credentials, SSH keys, cloud tokens, or access to production, a RAT doesn’t need to “hack production” immediately—it can just patiently wait until a developer does something useful.

The malware chain: a “phantom dependency” with very real consequences

One of the more interesting aspects of this incident is that defenders quickly flagged the added dependency as suspicious because it behaved like a phantom dependency: present in the manifest but not used by the codebase in any normal way. CSO Online notes StepSecurity’s view that such phantom deps are a high-confidence indicator of compromise. citeturn2search6

Datadog’s analysis describes the key mechanics:

Malicious axios releases introduced plain-crypto-js, described as a typosquat-like package meant to look legitimate.
That dependency executed code during installation to fetch and run a cross-platform RAT.
The “latest” tag pointing to 1.14.1 meant that unpinned installs were especially exposed.

citeturn2search2

Several reports also highlight a key defense-evasion move: after execution, the malicious package attempted to remove traces of itself and even “clean up” metadata in ways that could mislead casual inspection. CSO Online cites Socket researchers saying the malware tried to replace its own manifest so that npm list might show a different version than the one that executed. citeturn2search6

Attribution: why North Korea is being mentioned (and why it matters)

Attribution is always a spicy topic because it tends to age poorly. But in this case, Axios (the news outlet) reports that Google researchers linked the activity to a North Korea–nexus group tracked as UNC1069, historically associated with targeting crypto and DeFi organizations. citeturn1news12

This matters operationally for defenders because:

North Korea–linked actors are often financially motivated and persistent.
Developer compromise is a proven path to reach higher-value targets (cloud environments, wallets, CI/CD, signing keys).
Follow-on activity may include credential theft, lateral movement, and targeted exfiltration rather than loud ransomware.

At the same time, not every analysis has taken a firm stance on attribution. Some write-ups focus on mechanics and response over naming an actor, which is often the most useful approach during the first 48 hours. citeturn2search1

Who is most at risk

The highest-risk population isn’t “anyone who ever used axios.” It’s more specific:

Teams that ran builds (CI or local) during the exposure window and pulled the malicious version via semver ranges (for example caret ranges like ^1.14.0).
Organizations that do frequent container builds and publish images automatically.
Developers with powerful credentials on their workstations (cloud admin, prod access, signing keys, etc.).
Companies with weak egress controls, where a postinstall script can freely call out to the internet.

Bitdefender’s advisory explicitly warns that projects using standard caret ranges (like ^1.14.0 or ^0.30.0) could have pulled the compromised versions automatically. citeturn2search8

“But we use lockfiles, we’re fine”… maybe

Lockfiles help a lot, but they don’t help retroactively if a lockfile was generated or updated during the window. They also don’t protect you if you build without lockfiles, allow ranges in internal tooling, or run dependency updates automatically. And even if you fixed the dependency later, a compromised machine or baked container image can remain compromised.

A recurring theme in postmortems of supply-chain incidents is that reproducibility is necessary but not sufficient. You can reproduce a compromised build perfectly—congratulations, you have a reliable pipeline for malware.

Immediate response checklist (what I’d ask a team to do in the first hour)

This is not legal advice and not a substitute for professional incident response, but it reflects common guidance from security research write-ups and practical DevSecOps reality.

1) Find out if you pulled the bad versions

Search your repos for axios@1.14.1 and axios@0.30.4 in package-lock.json, yarn.lock, and pnpm-lock.yaml.
Search for the presence of plain-crypto-js in lockfiles and node_modules.

2) Identify which machines ran installs during the window

Look at:

CI logs (GitHub Actions, GitLab CI, Jenkins, Buildkite, etc.)
Container build logs (Docker/BuildKit, Kaniko, etc.)
Developer shell history if you have EDR/telemetry (or ask directly)

3) Treat affected endpoints as potentially compromised

If you confirm the malicious versions were installed, assume the host that performed the install executed untrusted code. The RAT angle means you should consider:

Credential theft (cloud tokens, SSH keys, API keys)
Persistence mechanisms
Lateral movement opportunities

4) Rotate secrets aggressively (and thoughtfully)

Rotating secrets is painful, but not as painful as discovering weeks later that an attacker has been quietly reusing a GitHub token to publish “helpful hotfixes.” Focus on:

CI/CD secrets and deploy keys
npm tokens and registry credentials
Cloud credentials (AWS/GCP/Azure access keys, workload identity bindings)
GitHub/GitLab PATs and OAuth tokens

5) Hunt for IOCs using trusted sources

IOCs can change as analysis develops, so prefer reputable security lab write-ups and vendor advisories. Datadog and Bitdefender both published technical notes quickly; CSO Online aggregated details from multiple firms. citeturn2search2turn2search8turn2search6

Longer-term fixes: how to make “npm install” less exciting

This incident is also a case study in the limits of today’s trust model for open-source packaging. You can do a lot right—code review, 2FA, even CI-based publishing—and still get burned if a valid token can publish a release outside the expected pipeline.

Move publishers to OIDC-based “Trusted Publishing” where possible

In 2025, npm made Trusted Publishing with OIDC generally available, aiming to reduce reliance on long-lived tokens by letting CI workflows exchange short-lived identity for publish rights. GitHub’s changelog describes this as a way to publish without storing long-lived tokens, and it ties into provenance attestations. citeturn2search0

npm’s documentation also frames trusted publishing as a trust relationship between npm and your CI provider via OIDC. citeturn2search5

Important nuance: OIDC helps, but only if it’s the only way releases happen. If a maintainer has an old token sitting around (in a password manager, a dotfile, an environment variable on a laptop, or a compromised CI secret store), attackers will go token-hunting because it’s easier than breaking modern identity.

Require provenance verification (where the ecosystem supports it)

Provenance is not a silver bullet, but it’s the direction the industry is moving: cryptographically linking “this package” to “this build process” and “this source repository.” npm maintains a public repository describing npm provenance tooling and SLSA-aligned approaches. citeturn2search3

On the consumer side, projects like the SLSA verifier are working toward verifying provenance for artifacts (including experimental npm verification flows). citeturn2search9

Reduce install-time execution in your environment

Npm’s lifecycle scripts are incredibly convenient and incredibly abusable. You don’t have to ban them globally, but you can:

Block install scripts in high-trust environments unless explicitly allowed
Run builds in restricted sandboxes without access to developer credentials
Enforce outbound network controls during dependency installation

If your build environment can’t call out to random servers during dependency install, a “download stage two payload” trick becomes much harder.

Pin dependencies in production builds (and understand what “pin” really means)

Pinning a direct dependency is good. Pinning transitive dependencies is better. Ensuring that your production build is reproducible and built from a verified lockfile is better still.

But pinning doesn’t fix an already-compromised endpoint. This incident has reminded many teams that you need both:

Software supply-chain controls (pinning, provenance, scanning, review)
Endpoint and CI security controls (EDR, least privilege, secret isolation)

Industry context: supply-chain attacks are no longer “rare edge cases”

It’s tempting to compare every modern incident to the ones that made headlines—SolarWinds, Log4Shell, xz-utils drama, and so on. But the uncomfortable truth is that package ecosystem attacks have become routine. StepSecurity documented earlier npm incidents like the 2025 compromise of the popular is package, which also involved malicious releases published to npm. citeturn2search7

Attackers go where the leverage is:

One compromised maintainer account can impact thousands of downstream projects.
One malicious patch release can ride semver ranges into production.
One install-time script can run wherever CI and developers run builds.

Axios is a particularly brutal example because the library is so common and because HTTP request tooling naturally sits in places that have network access. Malware doesn’t like being trapped in an air-gapped box (it gets lonely).

What to watch next

Based on patterns in similar incidents, the next developments typically include:

More precise IOCs and detection rules from vendors as reverse engineering continues.
Follow-on compromises using credentials harvested from developer systems (GitHub orgs, cloud accounts, npm publishers).
Registry and platform changes (or at least proposals) about mandatory 2FA, stronger publisher verification, and stricter publishing workflows for high-impact packages.

Axios (the news outlet) noted that it was not immediately clear how the attackers gained access to the maintainer’s account, which means defenders should consider multiple possibilities: phishing, token theft, endpoint compromise, or compromised third-party services. citeturn1news12

A quick sanity check: what you should tell your execs (without causing a fire drill for the wrong reasons)

If you’re briefing leadership, aim for clarity:

This was a real supply-chain compromise of a widely used library.
Exposure depends on whether your organization installed the specific malicious versions during a short window.
If exposure occurred, it may be an endpoint compromise problem (developer machines/CI), not just an application dependency issue.
Response may require secret rotation and forensic review, not just bumping a version number.

And yes: your developers will say “but it was only three hours.” Remind them that many of the most expensive outages in history started with shorter periods of bad luck.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org