Axios npm Supply Chain Attack Delivers RAT via plain-crypto-js, Hits 83M Weekly-Download Package
The npm ecosystem has been hit by a serious supply-chain compromise after attackers published malicious versions of the official Axios package, one of the most widely used HTTP client libraries in modern JavaScript development. The poisoned releases, axios@1.14.1 and axios@0.30.4, were pushed directly to npm on March 30 and 31, 2026 and pulled in a malicious dependency, plain-crypto-js@4.2.1, that executed automatically during installation. Socket says the package was flagged within minutes, but the risk window was still large because Axios is installed at enormous scale across developer laptops, CI/CD runners, and production build systems.
What makes this incident especially dangerous is that the attackers did not heavily modify Axios itself. Instead, they made a small, low-noise change by introducing a malicious transitive dependency. That is a highly effective tactic because many teams review direct dependency changes, but far fewer scrutinize newly introduced sub-dependencies in a popular package update. Socket’s analysis says the malicious package plain-crypto-js@4.2.1 was published at 23:59:12 UTC on March 30, 2026, and the poisoned Axios releases followed roughly two minutes later, suggesting a coordinated and likely automated release chain rather than a manual opportunistic attack.
The working theory in public reporting is account compromise. GitHub issue traffic around the incident says the malicious versions were published through the official Axios npm package and that maintainers were struggling to revoke attacker access in the immediate aftermath. The user-provided incident notes add that the maintainer email was reportedly replaced with a Proton Mail address and that the release did not align with Axios’s legitimate GitHub release process, reinforcing the conclusion that this was a registry-side publishing compromise rather than a source-code compromise.
The malicious payload lives inside plain-crypto-js and runs through npm’s postinstall lifecycle hook. In practical terms, this means the malware executes the moment a victim runs npm install, before most developers would notice anything unusual. The user-provided technical analysis says the execution chain is npm install → postinstall hook → node setup.js → _entry("6202033"), after which the malware performs OS detection, downloads or stages a platform-specific second stage, and then deletes evidence of the installer from disk. That design makes the initial compromise easy to trigger and the forensic footprint harder to recover after the fact.
The code is also intentionally obfuscated. According to the supplied analysis, strings for module names, the command-and-control infrastructure, shell commands, and filesystem paths are hidden using a two-layer scheme consisting of reversed Base64 plus XOR with the key OrDeR_7077. That is not just cosmetic packing. It is a deliberate attempt to slow static inspection, defeat simple signature matching, and make the package appear more benign in casual review.
The second-stage behavior differs by platform. On macOS, the malware uses AppleScript to download a binary to /Library/Caches/com.apple.act.mond, marks it executable, and launches it in the background. Elastic’s reverse engineering, as quoted in the uploaded notes, describes the macOS payload as a C++ RAT capable of periodic beaconing, directory listing, shell or AppleScript execution, and on-demand execution of a secondary binary via a command identified as peinject. The beacon reportedly includes host metadata such as hostname, username, macOS version, timezone, CPU type, and application/library directory information, giving the operator a fast profile of the infected machine.
On Windows, the malware reportedly locates PowerShell, copies it to %PROGRAMDATA%\wt.exe to masquerade as Windows Terminal, then uses a VBScript wrapper and a PowerShell script to fetch and execute a follow-on payload from the attacker infrastructure. On Linux, it downloads a Python script to /tmp/ld.py and executes it via nohup python3. Across platforms, the malware exfiltrates environment-derived secrets, which means the blast radius can include cloud credentials, API tokens, database passwords, CI variables, and anything exposed in the install environment.
The network tradecraft is also worth noting. The uploaded analysis says the malware calls home to sfrclak.com at 142.11.206.73:8000 and uses campaign-specific paths including /6202033. It also uses lookalike paths under packages.npm.org such as /product0, /product1, and /product2 to make malicious traffic appear similar to ordinary package-registry activity in logs. That kind of naming camouflage can delay detection in environments where outbound traffic is only lightly inspected.
The compromise is broader than the two Axios versions alone. The uploaded notes say two additional packages were caught distributing the same malware family: @shadanai/openclaw in versions 2026.3.31-2 and 2026.3.32-1, and @qqbrowser/openclaw-qbot@0.0.130, which reportedly included a compromised Axios build inside its own vendored node_modules. That matters because even teams that did not directly pin Axios to the bad versions may still have ingested the malware indirectly through other packages or automated dependency resolution.
From a defensive perspective, this incident is a reminder that postinstall malware is one of the most dangerous patterns in the JavaScript ecosystem. It executes at install time, often inside privileged CI contexts, and can immediately see secrets that would not be present at application runtime. In this case, the uploaded analysis explicitly warns that if a machine installed the malicious versions, defenders should assume compromise and rotate all reachable credentials rather than rely on simple package cleanup. That is a sound operational conclusion because the package’s purpose was clearly credential theft and remote access staging, not just one-off sabotage.
Indicators of Compromise (IoCs)
- Malicious npm packages:
axios@1.14.1,axios@0.30.4,plain-crypto-js@4.2.0,plain-crypto-js@4.2.1,@shadanai/openclaw@2026.3.31-2,@shadanai/openclaw@2026.3.32-1,@qqbrowser/openclaw-qbot@0.0.130 - C2 domain:
sfrclak.com - C2 IP / port:
142.11.206.73:8000 - Base URL:
http://sfrclak.com:8000/ - Campaign URL:
http://sfrclak.com:8000/6202033 - Campaign identifier:
6202033 - macOS artifact:
/Library/Caches/com.apple.act.mond - Windows artifacts:
%PROGRAMDATA%\wt.exe,%TEMP%\6202033.vbs,%TEMP%\6202033.ps1 - Linux artifact:
/tmp/ld.py - Behavioral patterns:
node setup.js, use ofcurl,osascript,cscript //nologo, andnohup python3during install-time execution - Obfuscation indicators: XOR key
OrDeR_7077, reversed Base64 + XOR, array namestq[] - Anti-forensics:
fs.unlink(__filename), postinstall removal,package.md → package.jsonswap behavior
What defenders should do now
First, check lockfiles, dependency trees, caches, and build logs for the malicious versions. Socket’s public guidance says any project using ^1.14.0 or ^0.30.0 could have silently resolved to the compromised releases during a normal install. If found, pin to a known-good version such as axios@1.14.0, delete node_modules and lockfiles, clean caches, and reinstall from a trusted baseline. More importantly, assume the host is compromised if the malicious versions were installed and rotate all credentials present in that environment, including cloud keys, GitHub tokens, database credentials, SSH material, and CI secrets.
The bigger lesson is that the Axios incident is not just another package hijack. It is a case study in modern, high-speed supply-chain compromise: trusted package, tiny change, transitive dependency, install-time execution, multi-platform second stage, self-deletion, and immediate credential theft. For teams that still rely on broad semver ranges, unreviewed install scripts, and long-lived registry tokens, this attack chain is a warning that the weakest point in the build pipeline is now often the dependency resolver itself.
Reference Links and Sources
