The Axios Supply Chain Attack: What Happened, How to Check, and What to Do Next

Two malicious versions of Axios were published to npm on March 31, 2026, hiding a dependency that deployed a Remote Access Trojan to developer machines and CI/CD servers. Here is what happened, how the attacker covered their tracks, and exactly what to do if your environment was exposed.

On March 31, 2026, two versions of Axios were pulled from npm after security researchers confirmed they contained a hidden dependency that deployed a Remote Access Trojan to any machine that ran npm install during a window of under three hours. Axios, a JavaScript HTTP client with over 100 million weekly downloads, had been poisoned. The malicious code inside Axios itself was zero lines. The weapon was a dependency that nobody invited, delivered through a mechanism every JavaScript developer trusts: the npm install lifecycle.

What a Supply Chain Attack Is

A supply chain attack targets the tools and dependencies developers use to build software rather than the deployed application itself. Instead of trying to exploit a production server directly, the attacker inserts malicious code into a package that developers install as part of their normal workflow. Every npm install runs with implicit trust that the resulting dependency tree is safe. Supply chain attacks exploit that trust by corrupting a link in the chain well before the code reaches any deployment environment. Because the attack executes at install time on the developer's own machine or CI/CD runner, it can access secrets, credentials, and file system contents that production servers would never expose.

Axios became a target because of its reach. A package downloaded 100 million times per week appears in frontend frameworks, backend services, and enterprise codebases across every industry. A successful compromise of even a two-hour window touches hundreds of thousands of installs. The axios attack was not the first npm supply chain incident, but the scale of the target, the operational sophistication of the execution, and the completeness of the self-cleanup make it one of the most significant ever documented.

How the Attack Was Staged: A Timeline

The operation shows clear evidence of deliberate preparation. Forensic analysis by StepSecurity traced the groundwork back more than 18 hours before any malicious Axios version appeared on npm. The attacker executed each step in sequence, with each one making the next harder to detect.

1. 1March 30, 2026, early morning: An attacker-controlled account published a package called plain-crypto-js@4.2.0 to npm. This version was a clean, bit-for-bit copy of the legitimate crypto-js library. No malicious code was present. Its sole purpose was to establish publishing history for the account so it would not trigger "brand-new account" warnings in security scanners during later steps.
2. 2Later that same day, late evening: The same account published plain-crypto-js@4.2.1. This version introduced two new files: an obfuscated JavaScript dropper named setup.js, and a pre-staged clean replacement file used for anti-forensic cover after execution. It also added a postinstall hook to the package manifest pointing to setup.js. Socket's automated scanner flagged this version as malicious within six minutes of publication.
3. 3March 31, 2026, 12:21 AM UTC: The primary Axios maintainer account, which the attacker had compromised, published axios@1.14.1 to npm. The only difference from the previous clean version (1.14.0) was a single addition to package.json: plain-crypto-js listed as a runtime dependency. No corresponding commit or release tag exists in the Axios GitHub repository for this version. Every legitimate Axios release uses npm's OIDC Trusted Publisher mechanism, tying each publish cryptographically to a verified GitHub Actions workflow. The malicious version had no such verification.
4. 439 minutes later: axios@0.30.4 was published using the same method. Both the 1.x and 0.x release branches were now compromised. Any project using a caret range on either branch would pull the poisoned version on its next npm install.
5. 5Approximately 3:15 AM UTC: npm unpublished both malicious Axios versions and placed a security hold on plain-crypto-js. Between the first malicious publish and the removal, less than three hours elapsed.

What the Dropper Did Once Installed

When a developer ran npm install and resolved either malicious Axios version, npm automatically installed plain-crypto-js@4.2.1 as a transitive dependency, then executed the postinstall hook, launching setup.js. The dropper used a two-layer obfuscation scheme to hide its strings from static analysis tools: module names, the command-and-control server address, shell commands, and file paths were all encoded behind a combination of reversed Base64 and an XOR cipher keyed to a string embedded in the script.

Once the strings were decoded at runtime, the dropper detected the operating system and routed to a platform-specific payload delivery path. On macOS, it wrote an AppleScript to a temporary file, executed it silently, and instructed it to download a compiled binary to /Library/Caches/com.apple.act.mond, a path deliberately constructed to resemble a legitimate Apple system daemon. On Windows, it located PowerShell, copied it to a path inside Program Data under the name wt.exe (mimicking Windows Terminal), then used a hidden VBScript wrapper to fetch and run a PowerShell payload without opening any visible window. On Linux and other Unix-like systems, it fetched a Python script, saved it to the /tmp directory, and launched it as a background process orphaned from the npm process tree.

All three platform payloads contacted the same command-and-control server at sfrclak.com on port 8000. The server returned a second-stage Remote Access Trojan tailored to each platform. The macOS RAT was captured and reverse-engineered by researchers before the server went offline. It was a fully functional C++ binary that fingerprinted the victim system, collected running processes and directory listings, executed arbitrary shell commands, deployed further payloads, and beaconed back to the attacker every 60 seconds. Each platform variant sent a distinct identifier in its POST body so the server could route the correct second-stage payload.

“There are zero lines of malicious code inside Axios itself. Both poisoned releases inject a fake dependency whose sole purpose is to run a postinstall script that deploys a cross-platform remote access trojan.”

StepSecurity, March 2026

After launching the platform-specific payload, setup.js performed three cleanup steps in sequence: it deleted itself, deleted the malicious package.json (which contained the postinstall hook), and replaced it with the pre-staged clean version that reported version 4.2.0 rather than 4.2.1. Running npm audit after the fact would raise no flags. Inspecting the package directory in node_modules would show what appeared to be a clean, ordinary package. The only forensic indicator that survived the cleanup was the presence of the plain-crypto-js directory itself, because that package has never appeared as a dependency in any legitimate Axios release.

The Windows payload left one additional persistent artifact: the copied PowerShell binary at %PROGRAMDATA%\wt.exe. This file would survive dependency reinstalls and system reboots. Even after removing plain-crypto-js and installing a clean version of Axios, wt.exe would remain on the machine as long as the operating system was not reformatted.

How to Determine Whether You Were Affected

The malicious versions were live between approximately 12:21 AM and 3:15 AM UTC on March 31, 2026. Any environment where npm install ran during that window and could have resolved axios@1.14.1 or axios@0.30.4 through a caret or wildcard range warrants a full investigation. Work through the following checks in order.

1. 1Search your dependency lockfiles. Open package-lock.json, yarn.lock, or pnpm-lock.yaml in every project that uses Axios and search for references to axios 1.14.1, axios 0.30.4, and the string plain-crypto-js. Any match in a lockfile means the compromised version was resolved during an install. If your repositories live on GitHub, the code search interface lets you scan your entire organization's lockfiles at once.
2. 2Check the installed node_modules directory. In any project where you suspect the package was installed, look inside node_modules for a folder named plain-crypto-js. Its presence confirms the dropper ran, regardless of the version number reported inside the folder. Because the dropper replaces the manifest with a downgraded version number as part of its cleanup, the folder's existence is a more reliable indicator than any version string.
3. 3Review CI/CD pipeline logs. Identify every npm install or npm ci run that executed between 12:21 AM and 3:15 AM UTC on March 31. Search those logs for plain-crypto-js appearing in the dependency resolution output. If you have outbound network monitoring on your CI runners, look for connections to the domain sfrclak.com or the IP address 142.11.206.73 on port 8000.
4. 4Check developer machines for RAT artifacts. The dropper writes a payload file at a predictable location on each operating system. On macOS, look for a file named com.apple.act.mond inside the Library/Caches directory. On Windows, look for a file named wt.exe inside the Program Data directory. On Linux, look for a file named ld.py inside the tmp directory. Finding any of these files confirms that the dropper reached its second stage and established a RAT on the machine.
5. 5Search corporate network and DNS logs. If your organization runs DNS filtering, a proxy, or a firewall with logging, search for any queries or connections to the domain sfrclak.com. A hit from a developer machine or CI runner in the early hours of March 31 confirms that the RAT dropper contacted the attacker's server successfully.

What to Do Based on What You Found

The Compromised Version Appeared Only in Source Files

If you found the version in a lockfile or branch that was never actually installed in a live environment, the exposure is limited to source. Update your version specification to a known-safe release: axios@1.14.0 for 1.x projects, or axios@0.30.3 for 0.x projects. Add an overrides or resolutions block to your package.json to prevent future installs from resolving to the compromised versions through a transitive dependency. Delete the node_modules/plain-crypto-js directory if it exists, run a clean install, and regenerate your lockfile. Review any open pull requests that reference the compromised versions and close them without merging, even if CI passed. The CI runner may have executed the dropper on those branches.

The Package Was Installed on an Ephemeral CI Runner

GitHub-hosted runners and similar ephemeral environments are destroyed after each job executes, so the runner itself is not a persistent threat. The concern is the credentials that were accessible to the workflow during the compromised run. Rotate every secret that was injected into that environment: npm tokens, cloud provider access keys and session tokens for AWS, GCP, and Azure, SSH keys, API keys stored as environment variables, and any values sourced from the repository's secrets store. After rotating, review the access logs for each service those credentials could reach and look for activity in the window following the compromised install.

The Dropper Ran on a Developer Machine or Self-Hosted Runner

Treat any machine where you confirmed the dropper ran as fully compromised. A loaded Remote Access Trojan can execute arbitrary commands, deploy additional payloads, exfiltrate files, and establish persistence mechanisms beyond the initial install. Local inspection alone cannot determine what the attacker accessed, exfiltrated, or modified. The response path has four steps: isolate the machine from the network immediately; document every credential that was accessible on that machine before wiping it, including API keys, SSH keys, cloud access tokens, npm tokens, database connection strings, and any .env files across local projects; reformat the operating system and rebuild from a known-good baseline; rotate every documented credential from a separate, clean machine before reconnecting anything to internal services. Review the access logs for those services covering the period during and after the compromise window.

Hardening Your Workflow to Limit Exposure Going Forward

The axios attack exploited a detection window measured in hours. Several controls at the package manager level narrow or close that window for future attacks. Most major JavaScript package managers now support a minimum release age policy, a setting that prevents newly published packages from being automatically resolved until they have been live for a configured number of days. This policy would have blocked plain-crypto-js@4.2.1, which was published only hours before the compromised axios versions appeared. The documentation for npm, pnpm, yarn, and bun each covers this setting directly. Running installs with the ignore-scripts flag in CI/CD pipelines prevents postinstall hooks from executing at all, removing the specific mechanism the dropper relied on. Combining a minimum release age policy with script suppression in CI provides two independent controls against this class of attack.

Ryan VerWey

Founder & Lead Strategist at Echo Effect LLC. Veteran-owned. Meta certified. Helping businesses grow through social media and web development.