One Stolen Token Turned Axios Into a Trojan. Here Is the Full Attack, and How to Check If You Are Affected.

The Package You Trusted Became the Attack Vector

On March 31, 2026, between 00:21 and 03:20 UTC, anyone who ran npm install and resolved to axios@1.14.1 or axios@0.30.4 silently installed a cross-platform Remote Access Trojan on their machine. No error appeared. No warning surfaced. The install completed normally. The compromise happened in the background before the terminal prompt returned.

Axios is the most widely used JavaScript HTTP client library, with over 100 million weekly downloads on npm. It is a standard dependency in frontend frameworks, backend APIs, CI/CD pipelines, and developer workstations across virtually every industry. On March 31, it became the delivery mechanism for a targeted supply chain attack attributed by Google Threat Intelligence Group to UNC1069, a North Korea-nexus threat actor active since at least 2018.

The malicious versions have been removed from the npm registry. The attack window is closed. But any machine that installed the compromised versions during that window remains compromised until remediated.

Confirmed Timeline of the Attack

The attack was pre-staged across approximately 18 hours before the malicious Axios versions appeared.

March 30, 2026, approximately 06:00 UTC: An npm account named nrwise published plain-crypto-js@4.2.0, a clean package designed to look like a legitimate fork of the well-known crypto-js library. This version contained no malicious payload. Its purpose was to establish registry history and avoid triggering "new package" alerts from security scanners.

March 30, 2026, 23:59 UTC: The attacker published plain-crypto-js@4.2.1, the malicious version. This version contained a postinstall hook in its package.json declaring node setup.js, which npm executes automatically during every install.

March 31, 2026, 00:21 UTC: Using a stolen long-lived npm access token, the attacker accessed the npm account of jasonsaayman, the lead maintainer of Axios, changed its registered email to ifstap@proton.me, and published axios@1.14.1 tagged as latest. This version introduced plain-crypto-js@4.2.1 as a new dependency, a package that does not appear anywhere in the legitimate Axios source code.

March 31, 2026, 01:00 UTC: The attacker published axios@0.30.4, tagged as legacy, reaching developers on the older 0.x API branch and maximizing exposure across both current and legacy user bases.

March 31, 2026, 01:50 UTC: Elastic Security Labs filed a GitHub Security Advisory after detecting the compromise through automated supply chain monitoring.

March 31, 2026, approximately 03:20 UTC: npm removed the compromised package versions. The malicious versions were live for approximately three hours.

How the Malware Worked

When a developer ran npm install against either compromised Axios version, npm resolved the dependency tree, downloaded plain-crypto-js@4.2.1, and automatically executed its postinstall script. The script, named setup.js, is an obfuscated dropper identified by Google Threat Intelligence Group as SILKBELL.

SILKBELL checked the target operating system and contacted the attacker's command and control server at sfrclak[.]com:8000 to retrieve a platform-specific second-stage payload. Google Threat Intelligence Group identified this payload as WAVESHAPER.V2, a backdoor previously associated with UNC1069 operations.

After delivering the payload and executing it, the dropper erased itself and replaced plain-crypto-js's own package.json with a clean decoy version. Any developer who inspected node_modules after the install would find no postinstall script, no setup.js file, and no indication of compromise. npm audit would show nothing. Manual inspection of the installed package directory would show nothing.

The malicious publishing method also differed from every prior legitimate Axios release. Legitimate Axios releases carry OIDC provenance metadata and SLSA build attestations. The malicious versions had neither, published directly via CLI rather than through the project's normal GitHub Actions workflow.

Two additional packages were subsequently confirmed by Socket to distribute the same malware: @shadanai/openclaw and @qqbrowser/openclaw-qbot@0.0.130, both of which either vendored the malicious plain-crypto-js directly or shipped a tampered axios@1.14.1 with the malicious dependency injected.

Are You Affected? Check These Now

Exposure window: Any npm install that resolved to axios@1.14.1 or axios@0.30.4 between 00:21 and 03:20 UTC on March 31, 2026.

Safe versions:

Check your lockfiles immediately:

Search package-lock.json, yarn.lock, or pnpm-lock.yaml for:

Check installed packages:

Run in any Node.js project directory: ``` npm list axios npm list plain-crypto-js ```

If plain-crypto-js appears at any version, treat the machine as compromised.

Check network logs:

Look for any outbound connections to sfrclak[.]com or sfrclak[.]com:8000. Any connection to this domain confirms the payload was retrieved.

Important: If you are using axios@1.14.0 or earlier, or axios@0.30.3 or earlier, and did not run npm install during the UTC exposure window, you are not affected.

Immediate Remediation if You Are Affected

Huntress, Elastic Security Labs, and StepSecurity all recommend the same response for any machine that installed the compromised versions: treat the machine as fully compromised and act accordingly.

Step 1: Isolate the machine from the network immediately. Do not continue using it while investigating.

Step 2: Rotate all secrets that were accessible on or from the machine during the exposure window. This includes cloud provider API keys, GitHub personal access tokens, npm access tokens, SSH keys, database credentials, and any credentials stored in environment variables, dotfiles, or local credential managers.

Step 3: Audit your npm publish history. If the compromised machine had npm publish access, review recent publish activity for any packages your organization maintains to confirm no unauthorized versions were released using stolen tokens.

Step 4: Audit recent repository and cloud activity. Check for unauthorized commits, new deploy keys, modified CI/CD configurations, or unexpected API calls in cloud provider activity logs.

Step 5: For CI/CD pipelines that ran during the exposure window, review build logs to determine which jobs installed the affected versions and rotate any credentials those pipelines had access to.

Step 6: Downgrade Axios across all affected projects to a safe version and commit the updated lockfile: ``` npm install axios@1.14.0 ```

What This Attack Reveals About npm Security

The Axios attack did not require a vulnerability in the npm registry or in Axios's code. It required one thing: a long-lived npm access token belonging to a project maintainer.

The Axios project had configured OIDC trusted publishing, a more secure publishing method that ties releases to verifiable GitHub Actions runs. However, the project continued passing NPM_TOKEN alongside OIDC credentials in its publishing workflow. When both are present, npm uses the token. The long-lived token was therefore the effective authentication mechanism for all publishes, regardless of the OIDC configuration. The attacker obtained that token and used it directly.

For developers and engineering teams, the confirmed actionable changes from this incident are:

Replace long-lived npm tokens with short-lived OIDC-based publishing for any package your organization maintains. A token that cannot be stolen because it expires in minutes cannot be used to publish malicious versions.

Use npm ci instead of npm install in all CI/CD pipelines. The npm ci command installs from the committed lockfile exactly, refusing to resolve floating version ranges. Had every affected pipeline used npm ci with a committed lockfile pinned to axios@1.14.0, the malicious versions would not have been installed.

Consider running npm install with --ignore-scripts for dependency installation in automated environments. Most production builds do not require postinstall scripts from third-party dependencies. Disabling lifecycle script execution eliminates the mechanism this attack depended on entirely.

Conclusion

The Axios supply chain attack was a targeted, pre-staged operation attributed to a state-linked threat actor. The malicious versions were live for approximately three hours. The cleanup was fast. The damage, on machines that installed those versions during the window, is potentially significant and ongoing until credentials are rotated and machines are rebuilt.

The attack exploited no software vulnerability. It exploited the trust that the JavaScript ecosystem places in registered npm packages and the accounts that publish them. That trust is necessary for the ecosystem to function. It is also the attack surface.

If you are looking for help auditing your organization's supply chain security posture, implementing dependency governance policies, or securing your CI/CD infrastructure against this class of attack, please reach out to MonkDA. We work with engineering teams building secure software infrastructure at every stage.