Cyber Kendra

The JavaScript ecosystem woke up on March 31, 2026, to one of its most alarming supply chain attacks on record. Two malicious versions of the widely used axios HTTP client library — [email protected] and [email protected] — were published to npm using the compromised credentials of a lead axios maintainer, bypassing the project's normal GitHub Actions CI/CD pipeline entirely.

The attacker didn't touch a single line of axios's actual source code. Instead, they did something far more sinister — and harder to spot.

What Is Axios, and Why Does This Matter?

If you've written JavaScript in the last decade, you've almost certainly used axios. It is used in virtually every Node.js and browser application that makes HTTP requests — from React front-ends to CI/CD tooling to server-side APIs. With over 300 million weekly downloads, a compromise of even a single minor release can have an enormous blast radius.  (Stepsecurity) A developer running a routine npm install or npm update on Tuesday had no reason to suspect their machine was about to be silently backdoored.

This isn't a theoretical risk. The malware ran. The C2 server was live. The payloads were delivered.

The Attack

This attack was not improvised. It was pre-staged over 18 hours with military-like precision across three phases.

Phase 1 — Building Credibility

On March 30 at 05:57 UTC, an attacker-controlled account (nrwise, using [email protected]) published [email protected] — a completely clean decoy containing a full copy of the legitimate crypto-js source with no postinstall hook. Its sole purpose was to establish a publishing history for npm so the account wouldn't appear as a zero-history throwaway during later inspection.

Phase 2 — Arming the Payload

The malicious package [email protected] was published on March 30, 2026, at 23:59:12 UTC. Socket's automated malware detection flagged the package within minutes, at 00:05:41 UTC on March 31. Five minutes from weapon to detection — but by then, the damage was already in motion.

Phase 3 — Hijacking the Maintainer

Both versions were published using the compromised npm credentials of a lead axios maintainer, bypassing the project's normal GitHub Actions CI/CD pipeline. The attacker changed the maintainer's account email to an anonymous ProtonMail address and manually published the poisoned packages via the npm CLI. 

A critical forensic signal is visible in the npm registry metadata. Every legitimate axios 1.x release is published via GitHub Actions with npm's OIDC Trusted Publisher mechanism — meaning the publish is cryptographically tied to a verified GitHub Actions workflow. [email protected] breaks that pattern entirely — published manually via a stolen npm access token with no OIDC binding and no gitHead. There is no commit or tag in the axios GitHub repository for 1.14.1. The release exists only on npm.

Both the 1.x and legacy 0.x release branches were poisoned, within 39 minutes of each other. Any project using a caret range (^1.14.0 or ^0.30.0) would pull in the compromised version on its next npm install.

The Trojan Horse: [email protected]

Neither malicious version contains a single line of malicious code inside axios itself. Instead, both inject a fake dependency, [email protected], a package that is never imported anywhere in the axios source, whose only purpose is to run a postinstall script that deploys a cross-platform remote access trojan (RAT).

The package was designed to look legitimate — it masqueraded as the well-known crypto-js library, with the same description, same author attribution (Evan Vosberg), and even the same repository URL pointing to github.com/brix/crypto-js. A developer glancing at it would see nothing alarming.

The timeline is what should unsettle you. plain-crypto-js was published at 23:59:12 UTC on March 30 — a brand new package with no prior history, created for this. The poisoned Axios versions went up roughly two minutes later. Socket's detection flagged the anomaly at 00:05:41. Five minutes elapsed from the dropper to the infected package. This wasn't manual — it was a script waiting to fire. 

StepSecurity researchers performed full static and runtime analysis of setup.js — the 4,209-byte obfuscated dropper at the heart of the attack.

Obfuscation: All sensitive strings — module names, OS identifiers, shell commands, the C2 URL, and file paths — are stored as encoded values in an array. Two functions decode them at runtime using a combined XOR cipher and base64 decode scheme, designed to evade static analysis tools and confuse human reviewers. 

C2 Infrastructure: The dropper phones home to http://sfrclak.com:8000/6202033 (IP: 142.11.206.73). The packages.npm.org/ prefix in the POST body is a deliberate attempt to make outbound traffic appear, at a glance, as benign npm registry communication in network logs and SIEM rules.

Platform-Specific Payloads:

• macOS: Deploys an AppleScript binary disguised as a legitimate Apple process at /Library/Caches/com.apple.act.mond — a path designed to blend in with genuine Apple background daemons.
• Windows: Copies PowerShell to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal), drops a hidden VBScript that runs a PowerShell RAT with -ExecutionPolicy Bypass and -WindowStyle Hidden.
• Linux: Fetches a Python RAT to /tmp/ld.py, executing it in the background with nohup to survive the parent process.

Self-Destruction: After launching the platform payload, setup.js deletes itself, removes the package.json containing the incriminating postinstall hook, and renames a pre-staged clean stub into place. Any post-infection inspection of node_modules/plain-crypto-js/package.json will show a completely clean manifest — no postinstall script, no setup.js file, no indication that anything malicious was ever installed.

Runtime Confirmation: StepSecurity validated execution inside a live GitHub Actions runner. The first C2 connection fires just 1.1 seconds into the npm install — before npm had finished resolving all dependencies. A second C2 connection occurs 36 seconds later in an entirely different workflow step, confirming the stage-2 payload had persisted as a detached background process orphaned to PID 1 (init) — severing all parent-child relationships and actively evading process attribution.

Axios Was Not Alone

Socket's research team identified two additional npm packages distributing the identical malware:

• @shadanai/openclaw — a fork of the open-source OpenClaw AI gateway. The malicious plain-crypto-js trojan is hidden deep in a vendored path. The setup.js file is identical — the same obfuscation, the same C2, the same platform payloads, the same self-deletion mechanism.
• @qqbrowser/[email protected] — uses a different injection vector, shipping a tampered [email protected] in its node_modules/ with plain-crypto-js already injected as a dependency. When npm processes this vendored axios, it installs plain-crypto-js and triggers the same malicious postinstall chain.

This points to an organised campaign, not a lone opportunist.

The Maintainers Are Locked Out

The most alarming aspect of this incident is that, at the time of writing, Axios maintainers appear unable to regain control of the project. 

In a public GitHub issue, a collaborator stated they could not revoke access from the account responsible for the malicious publish, noting that the attacker's permissions exceed their own. Attempts to remediate the release are currently ineffective, as any changes can be overridden. Maintainers have requested npm intervention, including revoking tokens, but the response may be delayed.

GitHub issues warning about the compromise are actively being deleted — further evidence that the attacker still controls both the npm and GitHub accounts. A CVE has been filed.

The news was sounded publicly on X by Feross Aboukhadijeh, co-founder of Socket Security:

"🚨 CRITICAL: Active supply chain attack on axios — one of npm's most depended-on packages. The latest [email protected] now pulls in [email protected], a package that did not exist before today. This is a live compromise. This is textbook supply chain installer malware." 

On Hacker News, where the story quickly climbed to the front page with over 130 points, the developer community raised urgent technical debates. 

One commenter noted: "Good news for pnpm/bun users who have to manually approve postinstall scripts." Another proposed a broader systemic fix: "Maybe a GitHub Action to deploy requires a final human click, and changing to CLI has a 3-day cooling period with mandatory security emails sent out."

A Linux-focused developer advised: "I recommend everyone to use bwrap if you're on Linux and alias all package managers with it. This limits the blast radius to your CWD and package manager caches and often won't even work since the malware usually expects some things to be available which are not in a permissionless sandbox."

Another noted: "I also have ignore-scripts=true in my ~/.npmrc. Based on the analysis, that alone would have mitigated the vulnerability. Bun and pnpm do not execute lifecycle scripts by default."

Am I Affected? How to Check

Run these commands immediately:

aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Check for RAT artifacts on your system:

cccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccccc

Indicators of Compromise (IOCs)

bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb

What You Must Do Right Now

1. Downgrade and pin axios immediately:
   sssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssssss
   Add this to your package.json to prevent silent resolution back to malicious versions:
   fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
2. Remove plain-crypto-js:
   ggggggggggggggggggggggggggggggggggggggggggggggggggggg
3. If a RAT artifact was found — do not attempt to clean in place. Rebuild from a known-good state.
4. Rotate every credential on any machine that ran the affected versions: npm tokens, AWS keys, SSH keys, GitHub tokens, cloud credentials, CI/CD secrets, and anything in .env files accessible at install time.
5. Audit your CI/CD pipelines — any workflow that ran npm install in the past 24 hours should be treated as potentially compromised, and all injected secrets should be rotated.
6. Harden going forward — add --ignore-scripts to all CI npm installs as a standing policy:
   npm ci --ignore-scripts
7. Block C2 at the network layer:
   hhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh

The Bigger Picture: A Wake-Up Call for npm

This was not opportunistic. The malicious dependency was staged 18 hours in advance. Three separate payloads were pre-built for three operating systems. Both release branches were hit within 39 minutes. Every trace was designed to self-destruct. This is among the most operationally sophisticated supply chain attacks ever documented against a top-10 npm package.  (Stepsecurity)

The Axios codebase itself is fine. This was a distribution attack, not a code problem. But most developers occasionally audit their direct dependencies — almost nobody audits the dependencies of those dependencies. That's the gap.  (The CyberSec Guru)

The incident joins a growing list of high-profile npm compromises — from event-stream to ua-parser-js to node-ipc — each exploiting the implicit trust developers place in packages they install without a second thought. What distinguishes this attack is its scale, its surgical precision, and its forensic discipline. The attackers weren't just good — they were thorough.

The investigation remains active. Further technical analysis of the second-stage payloads is expected as researchers continue to examine the full scope of the compromise.