Breaking: Axios npm supply chain attack — what happened, who's at risk, and what to do now
Today, attackers compromised the npm account of the primary axios maintainer and published two malicious versions of the library — present in roughly 80% of cloud and JavaScript environments. If your CI/CD pipeline ran npm install between 00:21 and 03:15 UTC today, you may be affected.
What happened
Axios is one of the most widely used JavaScript HTTP client libraries, downloaded approximately 100 million times per week. On March 31, 2026, a threat actor hijacked the npm account of its lead maintainer (jasonsaayman), changed its registered email to an attacker-controlled ProtonMail address, and used a stolen long-lived npm access token to publish two poisoned versions directly to the registry — bypassing GitHub Actions and the project's CI/CD pipeline entirely.
The malicious versions injected a fake dependency — plain-crypto-js@4.2.1 — that was never referenced in the actual code. This "phantom dependency" is an unambiguous indicator of tampering. Once installed, it executed a postinstall script that dropped a cross-platform Remote Access Trojan (RAT) onto the host machine, communicating with an attacker-controlled command-and-control server.
A critical tell that expert defenders caught immediately: legitimate axios releases always include OIDC provenance metadata and SLSA build attestations. The malicious versions had none — they were published directly, leaving no verifiable build trail.
Attack timeline
plain-crypto-js@4.2.1 as a clean decoy to establish registry trustplain-crypto-js@4.2.1 published — RAT dropper activatedaxios@1.14.1 published using compromised maintainer credentialsaxios@0.30.4 published — targeting legacy axios usersplain-crypto-jsWhat the malware does
The RAT payload was purpose-built for cross-platform stealth. On macOS, it used AppleScript to download and execute a binary disguised as a system process. On Windows, it leveraged VBScript and PowerShell with persistence mechanisms disguised as system binaries. On Linux, it dropped a Python script and executed it in the background via nohup. All three variants communicated with the same C2 infrastructure, with traffic engineered to mimic legitimate npm registry activity.
Indicators of compromise (IOCs)
| Type | Value |
|---|---|
| Malicious package | axios@1.14.1 |
| Malicious package | axios@0.30.4 |
| Injected dependency | plain-crypto-js@4.2.1 |
| C2 server | sfrclak.com:8000 |
| Attacker email | ifstap@proton.me |
| Package publisher | nrwise (nrwise@proton.me) |
| CVE tracking | GHSA-fw8c-xr5c-95f9 · MAL-2026-2306 |
Additional packages distributing the same payload
Socket identified two additional packages carrying the same malware via vendored dependencies:
@shadanai/openclaw — versions 2026.3.28-2, 2026.3.28-3, 2026.3.31-1, 2026.3.31-2
@qqbrowser/openclaw-qbot@0.0.130 — ships a tampered axios@1.14.1 in its node_modules/
How to check if you're affected
- Search your lockfiles (
package-lock.jsonoryarn.lock) foraxios@1.14.1,axios@0.30.4, orplain-crypto-js@4.2.1 - Review CI/CD build logs for any
npm installruns between 00:21–03:15 UTC on March 31, 2026 - Search endpoint and network logs for outbound connections to
sfrclak.com:8000— confirmed C2 server - Also audit for
@shadanai/openclawand@qqbrowser/openclaw-qbot@0.0.130— secondary packages confirmed distributing the same payload - If any of the above match: treat the affected system as fully compromised, rotate all credentials and API keys, and initiate a full forensic investigation for RAT persistence
Note for security teams: Even if your environment installed these versions, execution of the payload requires the postinstall hook to have run. Environments using --ignore-scripts during installation would not have triggered the dropper — though you should still audit for the presence of the affected packages.
How we do it at Emergence AI
Supply chain attacks like this follow a playbook we know well — and have responded to firsthand. Our defense posture is built around the assumption that trusted packages can be compromised, not as a theoretical edge case but as an operational reality.
axios@1.14.1 can't silently enter our dependency tree because loose version ranges simply don't merge.What every engineering team should do now
Beyond the immediate triage steps above, the following controls would have blocked or significantly reduced the blast radius of this attack for any organization:
- Pin all dependencies to exact versions and commit your lockfile to version control
- Replace
npm installwithnpm ciin all CI/CD pipelines - Add
--ignore-scriptsto npm installs in build environments where lifecycle hooks aren't required - Require SLSA provenance and OIDC attestations on critical package versions — treat missing provenance as a red flag
- Implement a package release cooldown — reject packages published within the last 72 hours in automated pipelines
- Audit npm maintainer account security: disable long-lived classic access tokens, enforce MFA, and move to short-lived OIDC tokens tied to GitHub Actions
The lesson isn't to stop trusting open source. It's to stop assuming trust without verification. This attack didn't exploit a zero-day. It exploited a human account with too much access and too few controls around it. That's a solvable problem.
Matthew Pace is CISO at Emergence AI, an autonomous agent orchestration platform for enterprise. For security inquiries or to report a vulnerability, see our trust portal.