North Korea-linked hackers briefly poisoned Axios on npm, putting Windows, macOS, and Linux systems at risk

Yes, developers and organizations that installed [email protected] or [email protected] during the brief exposure window should treat those systems as potentially compromised. Google Threat Intelligence Group says an attacker inserted a malicious dependency called plain-crypto-js into those two official Axios releases between 00:21 and 03:20 UTC on March 31, 2026.

This attack matters because Axios sits deep inside the JavaScript ecosystem. Elastic Security Labs says the package sees about 100 million weekly downloads, which means a short-lived compromise could still hit developer laptops, CI systems, build servers, and production workflows that pulled fresh installs during that period.

Google attributes the activity to UNC1069, a threat actor it describes as North Korea-nexus and financially motivated. That attribution comes from Google’s investigation, so it is best described as Google’s current assessment rather than a final public consensus across all vendors.

What happened

The attacker appears to have gained access to a maintainer account and then published backdoored Axios packages through npm. Researchers say the malicious builds bypassed the project’s normal GitHub Actions publishing path, which made the releases look legitimate to anyone who simply trusted the official package name and version tag.

Instead of changing Axios source code in a loud or obvious way, the attacker added [email protected] as a dependency. That package ran a postinstall script, which meant the infection could begin as soon as npm resolved dependencies and finished installation. No click, file open, or separate download was required from the victim.

Researchers say the malicious chain delivered a cross-platform remote access trojan. Windows received a PowerShell-based payload, macOS received a Mach-O implant, and Linux received a Python backdoor, all tied to the same command-and-control design.

Why defenders are taking this seriously

This was not a fake lookalike package on a side registry. The attacker published through the real Axios npm package, which sharply increased the chance that automated pipelines would trust and install it without raising suspicion.

Google says the malware family involved includes SILKBELL as the obfuscated JavaScript dropper and WAVESHAPER.V2 as the later-stage backdoor. Elastic’s analysis adds that the tooling used the same beaconing pattern, command set, and protocol logic across all three operating systems.

The malware also tried to cover its tracks. Elastic and Google both say the dropper attempted cleanup steps after execution, including swapping back a clean-looking package.json so defenders would have a harder time spotting the malicious install path during a quick review.

Affected versions and safe versions

Package	Status	Notes
axios 1.14.1	Compromised	Do not use
axios 0.30.4	Compromised	Do not use
plain-crypto-js 4.2.1	Malicious dependency	High risk
axios 1.14.0	Safe fallback	Common recommended rollback target
axios 0.30.3 or earlier	Safe fallback	Use on legacy branch

The safest immediate move is to pin Axios away from the compromised versions and inspect lockfiles. StepSecurity says npm later replaced plain-crypto-js with a security-holder stub, but that does not make previously exposed machines safe. If a system installed the malicious package during the live window, defenders should still assume compromise and investigate.

A practical temporary override for affected projects looks like this:

• "overrides": { "axios": "1.14.0" }
• use the equivalent resolution or override feature in Yarn, pnpm, or Bun
• commit the lockfile after forcing a clean reinstall
• avoid 1.14.1 and 0.30.4 completely

What the malware did on each platform

On Windows, the malware searched for PowerShell, copied it to a different path, fetched the next stage with curl, and executed it with hidden and policy-bypass options. Google says it could also establish persistence through a hidden batch file and a Run registry entry named MicrosoftUpdate.

On macOS, the installer used shell tooling to drop a Mach-O binary into /Library/Caches/com.apple.act.mond, changed permissions, and launched it through zsh. On Linux, it fetched a Python payload into /tmp/ld.py.

The backdoor then contacted infrastructure tied to sfrclak[.]com:8000 and used Base64-encoded JSON in its communications. Researchers say it could gather system information, list files, run commands, and pull additional payloads, which pushes this incident well beyond a nuisance package compromise.

What organizations should do now

If you installed either malicious Axios version, treat the affected machine as compromised first and clean second. Rebuild or restore it from a known-good state, then rotate tokens, API keys, cloud credentials, and any secrets that may have touched that host.

Security teams should also pause relevant CI/CD jobs, inspect package-lock, yarn.lock, pnpm-lock, or bun.lock files, clear package caches, and check whether plain-crypto-js appears anywhere in the dependency tree. Snyk specifically recommends searching lockfiles and dependency graphs for [email protected], [email protected], and plain-crypto-js.

Network defenders should hunt for connections tied to the command-and-control infrastructure and for suspicious child processes launched from Node.js install flows. That includes review of build runners, ephemeral containers, and internal developer tooling, not just production servers.

Quick response checklist

• identify any use of [email protected] or [email protected]
• search for plain-crypto-js in lockfiles and node_modules
• isolate any machine that installed the bad versions
• rebuild affected systems from a trusted baseline
• rotate credentials and tokens exposed on those hosts
• pin Axios to a safe version such as 1.14.0
• review CI logs for installs during the March 31 exposure window
• hunt for connections to sfrclak[.]com or 142.11.206.73

FAQ