Umesh Malik

Posted on Jun 12 • Originally published at umesh-malik.com

Axios Compromised on npm: How 1.14.1 and 0.30.4 Dropped a Cross-Platform RAT

#axios #npm #security #supplychainsecurity

Axios is one of the most trusted packages in the JavaScript ecosystem. On March 31, 2026, that trust path broke.

StepSecurity disclosed that malicious npm releases axios@1.14.1 and axios@0.30.4 pulled a hidden dependency, plain-crypto-js@4.2.1, whose postinstall script fetched a cross-platform remote access trojan. An axios GitHub issue documenting the compromise was opened the same day.

The short answer: if a developer laptop or CI runner installed either version during the exposure window, treat it as a potential host compromise, not just a bad library update.

What makes this incident unusually serious is that the attacker did not need obvious malicious changes across the Axios codebase. According to StepSecurity's diff analysis, the attack path was built around publish credentials, dependency injection, install-time execution, and anti-forensics cleanup.

TL;DR

The malicious Axios versions were 1.14.1 and 0.30.4, published on March 31, 2026.
According to StepSecurity, both releases injected plain-crypto-js@4.2.1, a dependency not used anywhere in Axios source code.
The malicious package ran a postinstall hook that contacted the attacker's infrastructure and pulled platform-specific payloads for macOS, Windows, and Linux.
StepSecurity says the malware then rewrote its own package.json to look clean, which means naive post-incident inspection can miss what happened.
StepSecurity's March 31 timeline says npm later unpublished the bad Axios versions and reverted latest to 1.14.0.
If plain-crypto-js exists in node_modules at all, that is already suspicious, because legitimate Axios releases do not depend on it.
If a developer machine or runner installed the bad versions and had secrets available, rotate credentials and rebuild from known-good state.
The larger lesson is about release provenance: npm's own docs recommend trusted publishing with OIDC because it removes the reusable token risk that attacks like this exploit.

Source: StepSecurity technical analysis published on March 30-31, 2026.

What happened to Axios on npm?

The verified story starts on March 30, 2026 and unfolds quickly.

StepSecurity says the attacker first seeded a lookalike dependency, then published the poisoned Axios versions just after midnight UTC on March 31. The packages were removed within hours, but the short exposure window does not make the incident low risk. An install-time payload only needs one successful run.

The exact dates matter here. The bad Axios releases were live on March 31, 2026, not for days or weeks, but for a long enough window to compromise any machine that installed them.

Why this attack was worse than a normal bad patch release

The deeper lesson is that package trust is not only about reviewing source files anymore. It is about verifying who published the package, how it was published, what changed in the dependency graph, and what happens during install.

How the kill chain actually worked

Important inference from release metadata
StepSecurity proved that the malicious publish broke Axios's normal release pattern by lacking the expected GitHub-linked provenance fields. npm's own documentation recommends trusted publishing with OIDC because it removes the risk of reusable publish credentials in CI/CD. The exact credential theft path is still an inference, but the release-path deviation is not.

Clean Axios vs the compromised releases

How do you check whether your team was exposed?

Start with the version check, but do not stop there.

npm ls axios 2>/dev/null | grep -E '1\.14\.1|0\.30\.4'
grep -R "plain-crypto-js" package-lock.json pnpm-lock.yaml yarn.lock 2>/dev/null
test -d node_modules/plain-crypto-js && echo "POTENTIALLY AFFECTED"

The presence of node_modules/plain-crypto-js is especially important. StepSecurity says legitimate Axios versions never install it, and the malware rewrites its own manifest after execution, so the directory itself is a stronger signal than the displayed version string.

Then check for platform artifacts StepSecurity published:

# macOS
ls -la /Library/Caches/com.apple.act.mond 2>/dev/null

# Linux
ls -la /tmp/ld.py 2>/dev/null

For Windows, StepSecurity lists %PROGRAMDATA%\wt.exe, %TEMP%\6202033.vbs, and %TEMP%\6202033.ps1 as relevant artifacts. The same report also lists the network indicators sfrclak.com and 142.11.206.73.

Source: StepSecurity Harden-Runner runtime validation and file event capture.

Escalation rule
If you find the bad Axios versions or any host artifact on a machine that had usable secrets, do not stop at deleting node_modules. Rebuild from known-good state and rotate credentials.

What should teams do in the first hour?

StepSecurity's remediation guidance on March 31 was to pin back to clean versions, remove the malicious dependency, and treat any machine with the dropper as compromised. In practical terms, the first hour should look like this:

What package maintainers should change after this

The official npm guidance is unusually relevant here. npm says to prefer trusted publishing with OIDC for CI/CD because it eliminates the security risks tied to long-lived publish credentials. npm also documents a stricter package setting, "Require two-factor authentication and disallow tokens", for cases where interactive publishing is acceptable and tokenless safety is worth the operational tradeoff.

DEV Community