Axios Supply Chain Attack (March 31, 2026): What Happened, Why It Was Dangerous, and What Teams Must Learn

On March 31, 2026, the JavaScript ecosystem saw one of the most serious npm supply-chain compromises in recent years: malicious Axios releases were published to npm from a compromised maintainer account.

Because Axios is used by an enormous part of the web stack, the attack had immediate blast-radius potential across developer machines, CI/CD runners, and production software pipelines.

This post explains the incident end-to-end: timeline, attack chain, impact, indicators of compromise (IOCs), response, and practical lessons for engineering teams.

Executive summary

Two malicious Axios versions were published:
- axios@1.14.1
- axios@0.30.4
Both injected a malicious dependency:
- plain-crypto-js@4.2.1
The malicious dependency executed a postinstall hook and dropped platform-specific malware payloads.
Public reporting indicates the malicious versions were available for a short but critical window (a few hours).
Any system that installed these versions during that window should be treated as potentially compromised.

Timeline (UTC)

Based on public security write-ups:

2026-03-30 23:59: plain-crypto-js@4.2.1 (malicious) published.
2026-03-31 00:21: axios@1.14.1 published with malicious dependency.
2026-03-31 01:00: axios@0.30.4 published with the same dependency.
~2026-03-31 03:15: malicious Axios versions removed from npm.

Even a short exposure window was enough to create risk, because many automated pipelines run installs continuously.

How the attack worked

1) Maintainer account compromise

Attackers gained control of a maintainer account and published malicious Axios versions that looked legitimate in npm at first glance.

2) Dependency injection

The malicious Axios releases added plain-crypto-js@4.2.1 as a dependency.

This was clever because Axios package code itself did not need obvious malicious code; compromise happened during dependency install.

3) Install-time execution

The malicious dependency used a postinstall script (node setup.js) to execute automatically during npm install.

4) Multi-platform payload delivery

Public analyses reported C2 callback and second-stage payload retrieval for:

macOS
Windows
Linux

5) Anti-forensics behavior

A key danger in this incident: the dropper reportedly attempted to hide traces by replacing package metadata after execution, making post-incident folder inspection less reliable.

Why this attack was especially dangerous

Massive dependency surface

Axios is one of the most used HTTP libraries in JavaScript. A compromise at that layer affects:

app repos
internal tools
build/deploy pipelines
transitive dependencies

CI/CD is a high-value target

The install step in CI often has access to secrets:

cloud credentials
npm tokens
deploy keys
signing keys

That turns a package compromise into a potential organization-wide incident.

“Trusted package” bias

Teams often trust mature packages more and scrutinize them less. This event showed that trust must be continuously verified, not assumed.

Impact model: who was at risk?

You were at high risk if any environment installed:

axios@1.14.1, or
axios@0.30.4, or
plain-crypto-js@4.2.1

during the compromise window.

Risk surfaces:

Developer machines
Self-hosted CI runners
Ephemeral CI runners (runner dies, but exposed secrets may still be stolen)
Build agents and release systems

Known indicators (reported publicly)

Malicious package versions

axios@1.14.1
axios@0.30.4
plain-crypto-js@4.2.1

Network indicators

sfrclak.com
142.11.206.73
C2 traffic over port 8000 (as reported in analyses)

File indicators (platform-specific, from public reports)

macOS: /Library/Caches/com.apple.act.mond
Linux: /tmp/ld.py
Windows: %PROGRAMDATA%\wt.exe (plus short-lived temp artifacts)

Note: IOC sets evolve over time. Always validate against latest threat intel from your security tooling and trusted advisories.

Incident response playbook (practical)

If you suspect exposure, treat it as a real incident.

1) Contain

Isolate suspected machines/runners.
Temporarily block known C2 domains/IPs at network egress.

2) Scope

Search lockfiles and logs for compromised versions.
Check CI logs for installs in the affected time window.
Investigate network telemetry for C2 callbacks.

3) Eradicate and recover

Rebuild affected hosts from known-good images.
Do not rely on “manual cleanups” alone for compromised dev machines.

4) Rotate secrets immediately

At minimum rotate:

npm tokens
cloud credentials
SSH keys
CI/CD secrets
any .env secrets available at install time

5) Validate

Confirm malicious versions no longer resolvable in lockfiles.
Add policy controls to prevent reintroduction.

What engineering teams should change now

A) Treat install hooks as executable code

postinstall is effectively code execution. Install phase is part of your threat surface.

B) Add release-age gates

Introduce dependency freshness delay (for example, 24h to 7d) to reduce risk from newly-published malicious versions.

C) Harden CI

Use least-privilege tokens.
Segment secrets by environment/repo.
Restrict egress from runners.
Prefer ephemeral runners where possible.

D) Monitor outbound network in pipelines

Anomalous outbound calls from build steps are one of the strongest early signals in attacks like this.

E) Pin + verify dependencies

lockfile discipline
deterministic installs
dependency review on update PRs

F) Separate build from release credentials

If build gets compromised, blast radius should not automatically include production deployment authority.

Strategic lesson

This was not just “a bad package version.”
It was a demonstration that modern software compromise often starts in dependency distribution + CI trust boundaries, not in your application code.

The right response is not panic; it is maturity:

better package governance
better pipeline isolation
better credential hygiene
faster incident playbooks

If your org can detect, contain, and rotate quickly, you can turn events like this into a resilience advantage.

Recommended immediate checks (quick list)

Audit lockfiles for axios@1.14.1, axios@0.30.4, plain-crypto-js.
Review CI jobs that ran during the incident window.
Rotate sensitive secrets that were accessible in those jobs/machines.
Enforce install-time hardening (--ignore-scripts where safe, egress controls, least-privilege).
Add package release-age policy across npm/pnpm/yarn/bun workflows.

Sources and references

If new primary disclosures emerge, this post should be updated with corrected timeline details and additional verified IOCs.