Axios Supply Chain Attack 2026: Malicious npm Versions, Postinstall Malware, and How to Protect Your Systems

Axios Supply Chain Attack 2026: TL;DR

• StepSecurity reported malicious Axios versions [email protected] and [email protected] on npm.
• The poisoned releases added a hidden dependency, [email protected], which executed during install.
• The malicious package used a postinstall hook and was described as a cross-platform remote access trojan dropper.
• Any developer machine, CI runner, or build environment that freshly installed those versions during the exposure window should be treated as potentially compromised.
• This is an incident response issue, not just a package upgrade issue: rotate secrets, review logs, and rebuild from a clean state.
• For prevention, enforce lockfiles, deterministic installs, install-script controls, runner hardening, and egress monitoring.

Confirmed Facts

• Axios is a widely used JavaScript HTTP client for browser and Node.js applications.
• The affected versions reported by StepSecurity were [email protected] and [email protected].
• The malicious dependency was [email protected].
• The attack was published through npm, not through a normal upstream source release flow.
• The malicious payload was install-time code, so fresh installs are the primary exposure path.

What Happened?

On March 31, 2026, StepSecurity reported that malicious versions of the real axios package were published to npm through a compromised maintainer account. That is what makes this incident so serious: the attacker did not need to create a fake package or trick developers into typing the wrong name. They abused a trusted publishing identity on one of the most widely used JavaScript libraries in the ecosystem.

The poisoned releases were [email protected] and [email protected]. StepSecurity reported that the malicious dependency, [email protected], was added solely to trigger a postinstall payload, with the dropper contacting command-and-control infrastructure and delivering platform-specific second-stage malware.

Why This Attack Matters

Axios is not a niche dependency. It appears in frontend apps, backend services, scripts, CI pipelines, preview deploys, and internal tooling. When a package with that distribution profile is poisoned, the blast radius extends beyond application code into build systems, developer laptops, deployment runners, and the secrets those systems can access.

The core lesson is simple: dependency installation is part of your attack surface. If an attacker can run code during install, they can bypass runtime defenses, tests, and many code review expectations.

Which Versions Were Malicious?

• Malicious: [email protected]
• Malicious: [email protected]
• Malicious dependency: [email protected]
• Known clean release in the 1.x line before the incident: [email protected]
• Known fixed release in the 0.x line after the earlier CVE-2026-25639 issue: [email protected]

If your repository never resolved to those exact versions, you were not affected by this specific compromise. If any machine or runner installed them while they were available, treat that environment as suspect until triage is complete.

How the Attack Worked

The malicious Axios releases were engineered to look ordinary. The package source itself was not obviously rewritten; instead, the attacker introduced a hidden dependency in package.json. That dependency was not there to support Axios functionality. It existed to execute code during installation.

That pattern is common in supply chain malware because it shifts execution earlier in the lifecycle. The code runs on a developer laptop or CI runner before the application starts, before business logic imports the library, and sometimes before a human has a chance to notice anything unusual.

According to StepSecurity, that single extra dependency was enough to make a normal install path dangerous. Once npm resolved the tree, the postinstall hook could execute the dropper and begin the next stage of the attack.

Why postinstall Hooks Are Dangerous

Package managers do not just download dependencies. They can also run lifecycle scripts such as preinstall, install, and postinstall. Those hooks execute on developer workstations, CI runners, build agents, and deployment systems. If you trust them by default, you are giving dependency authors code execution on your infrastructure.

StepSecurity reported that the malicious payload used obfuscation, contacted a live C2 endpoint, and delivered platform-specific second-stage payloads for macOS, Windows, and Linux. In other words, this was malware delivery through the install process, not a simple vulnerable dependency.

Indicators of Compromise

• Presence of [email protected] or [email protected] in a freshly installed dependency tree.
• Presence of [email protected] in the resolved install path.
• Unexpected outbound traffic to attacker infrastructure, including sfrclak.com.
• Unexpected files or artifacts created during dependency installation.
• Any secrets present on a machine at the time of install should be treated as exposed until proven otherwise.

The right sequence is: confirm exposure, determine whether code executed, assume secrets may have been exposed, then contain and rotate.

How to Check Whether You Were Exposed

Start with lockfiles and dependency resolution history. Your first goal is to answer one question: did any environment install the malicious Axios versions or the malicious dependency?

# package-lock.json
grep -E '"axios"' package-lock.json | grep -E '1\.14\.1|0\.30\.4'

# yarn.lock
grep -E 'axios@' yarn.lock | grep -E '1\.14\.1|0\.30\.4'

# bun.lock
grep -E 'axios' bun.lock | grep -E '1\.14\.1|0\.30\.4'

# look for the malicious dependency
npm ls plain-crypto-js
find node_modules -name "plain-crypto-js" -type d

If any of those checks are positive, escalate the event internally as a supply chain incident rather than a routine dependency update.

Immediate Response Plan

• Stop using any machine or runner confirmed to have installed the malicious versions until triage is complete.
• Pin Axios to a known safe version immediately.
• Delete node_modules and reinstall from a reviewed safe state.
• Rotate npm tokens, GitHub tokens, cloud credentials, SSH keys, service tokens, and environment secrets that existed on impacted hosts.
• Review CI logs, shell history, and outbound network logs for suspicious activity.
• Rebuild affected workloads from a clean environment instead of trusting in-place cleanup.
• Notify security and engineering leadership if the affected installs touched shared runners or production-adjacent systems.

The common mistake is underreacting. Replacing the package version is necessary, but it is not enough if install-time code already executed on a host.

Safe Remediation Commands

# remove potentially poisoned install artifacts
rm -rf node_modules package-lock.json yarn.lock bun.lock

# pin to a known safe version
npm install [email protected] --save-exact

# if you are on the older branch
npm install [email protected] --save-exact

# reinstall deterministically in CI afterward
npm ci

Pinning exact versions reduces ambiguity during containment. Once the incident is controlled, you can return to normal upgrade workflows with stricter release and install controls in place.

How to Protect Your Team Going Forward

• Commit lockfiles and treat unexpected lockfile churn as a security-relevant change.
• Use npm ci in CI instead of npm install whenever possible.
• Pin critical dependencies more strictly, especially infrastructure-facing packages.
• Review or block dependency install scripts where feasible.
• Use dependency monitoring tools that surface suspicious releases quickly.
• Create a cooling-off period before adopting freshly published package versions in production pipelines.
• Reduce secrets on build runners to the minimum necessary.
• Separate build-time credentials from deployment-time credentials.
• Restrict network egress from CI runners so malicious installers cannot freely call home.
• Prefer trusted publishing flows and verify whether upstream projects use them.

A Strong Security Baseline for JavaScript Teams

A mature JavaScript engineering org should treat the following as baseline controls rather than nice-to-haves:

• Deterministic installs with committed lockfiles
• Exact or tightly controlled dependency versioning for high-risk libraries
• Automated dependency scanning in pull requests and CI
• Install-script awareness and package reputation monitoring
• Short-lived credentials and fast token rotation processes
• Network restrictions on build systems
• Clean rebuild capability for runners and ephemeral environments
• Documented supply chain incident response playbooks

A Practical Team Policy You Can Adopt Today

# package-manager hygiene
npm config set ignore-scripts true

# use this selectively in controlled environments where your build does not depend on lifecycle scripts
# if your project needs scripts for native modules or setup, build an allowlist process instead

Do not apply ignore-scripts blindly across every workflow without testing, because some packages rely on legitimate lifecycle hooks. The point is to force explicit review for dependency code execution instead of allowing it by default.

Why Lockfiles Helped Some Teams

The strongest defensive pattern in this incident was lockfile discipline. If a repository had a clean lockfile committed before the malicious versions were published and CI used a deterministic install path, many teams were insulated because they reused an already reviewed dependency graph instead of resolving fresh packages from the registry.

That is the kind of boring engineering habit that looks trivial on an ordinary day and looks excellent during an incident.

What Solo Developers and Small Teams Should Do

Supply chain security is not just an enterprise problem. Small teams are often more exposed because one laptop may hold source access, production access, billing access, cloud access, and deployment access at the same time.

• Use a password manager and hardware-backed MFA wherever possible.
• Keep npm, GitHub, cloud, and deployment credentials separate.
• Avoid leaving broad long-lived tokens on local machines.
• Use exact dependency versions for core infrastructure packages.
• Review dependency updates before merging them.
• Treat laptops and CI runners as production-adjacent assets.

Frequently Asked Questions

• Was [email protected] malicious? Yes. StepSecurity identified it as part of the compromised npm release set.
• Was [email protected] malicious? Yes. It was the second poisoned release in the legacy 0.x line.
• Does npm ci protect me? It helps a lot when combined with a clean committed lockfile, because it avoids fresh version resolution.
• Should I rotate secrets? If any affected machine or runner installed the malicious versions, yes. Assume install-time code may have accessed them.
• Is this just a patching problem? No. Treat it as an incident response problem, then improve dependency controls afterward.

Final Takeaway

The Axios compromise is a reminder that software security is not only about vulnerable code. It is about who publishes the code, how it is published, what runs during installation, what secrets exist on the machine doing the install, and whether your workflow assumes trust where it should require verification.

If your team installed [email protected] or [email protected], treat it as a real incident. If you were not affected, treat this as a warning and harden your build pipeline now: deterministic installs, tighter dependency controls, reduced runner privileges, egress monitoring, and a faster incident playbook.

The fastest teams are not the ones that trust everything. They are the ones that ship quickly without giving up control of their supply chain.