The Poisoned Library: Inside the Axios npm Supply Chain Attack That Threatened 300 Million Weekly Downloads

At 12:21 AM UTC on March 31, 2026, a package appeared on the npm registry that looked completely normal. Version 1.14.1 of axios - the most popular HTTP client library in the JavaScript ecosystem, installed over 300 million times per week - hit the registry bearing the name of its lead maintainer. Thirty-nine minutes later, version 0.30.4 followed for the legacy branch. Both looked legitimate. Both carried the same maintainer credentials. Both contained a remote access trojan designed to compromise every developer machine that ran npm install.

The attack didn't touch a single line of axios source code. Instead, it injected a phantom dependency called plain-crypto-js@4.2.1 - a package that appears nowhere in the axios codebase, is never imported, never referenced, and exists for one purpose only: to execute a postinstall script that deploys a cross-platform RAT, contacts a command-and-control server, drops platform-specific second-stage payloads for macOS, Windows, and Linux, then erases every trace of itself from the filesystem.

Security firm StepSecurity identified the compromise within hours. Socket's automated malware scanner flagged the malicious dependency within six minutes of its publication. But the window between publication and detection was long enough for the poisoned versions to enter an unknown number of dependency trees, CI/CD pipelines, and developer workstations worldwide.

This is the story of how a single stolen npm token turned the internet's most-downloaded HTTP library into a malware delivery vehicle - and what it reveals about the fundamental fragility of the software supply chain.

What Is Axios and Why It Matters

To understand the magnitude of this attack, you need to understand what axios is. It's the HTTP client. The one. If you've written JavaScript in the last decade - whether you're building a React frontend, a Node.js API, a CI/CD pipeline, or an internal enterprise tool - there's a very good chance axios is somewhere in your dependency tree. The library handles HTTP requests and responses with a clean, promise-based API that works identically in browsers and server environments. It is, for practical purposes, infrastructure.

The numbers tell the story. Over 300 million weekly downloads on npm, according to StepSecurity's analysis. Socket, which also investigated the compromise, cites 100 million weekly downloads - likely measuring direct installs rather than transitive resolutions. Either number represents an extraordinary attack surface. A single compromised minor release of axios reaches more development environments in 24 hours than most malware campaigns reach in their entire lifetime.

The library's popularity creates a compounding problem. Axios doesn't just appear in applications - it appears in other packages. Libraries depend on it. Frameworks bundle it. Build tools use it internally. A developer might never explicitly install axios and still have it in their node_modules directory because something three levels deep in their dependency tree requires it. This is the nature of transitive dependencies, and it's what makes npm supply chain attacks so devastating: the blast radius extends far beyond the package's direct users.

Until March 31, axios had an essentially clean security record. Its maintainer, known by the npm handle jasonsaayman, had been publishing releases through GitHub Actions using npm's OIDC Trusted Publisher mechanism - a system where each publish is cryptographically tied to a verified CI/CD workflow. This was considered a gold-standard practice. It meant that even if someone stole the maintainer's npm password, they couldn't publish a release because the publish operation required a cryptographic token generated by the GitHub Actions workflow itself. The token was ephemeral, scoped, and mathematically unforgeable.

But there was a gap. Alongside the OIDC workflow, the maintainer's account still had a long-lived classic npm access token active. And that token, unlike the OIDC mechanism, could be used from anywhere. A laptop. A VPN endpoint in another country. An attacker's terminal. This is the gap the attacker exploited.

The 18-Hour Setup: Anatomy of a Pre-Staged Attack

Supply chain attacks against major packages are not smash-and-grab operations. They require planning, patience, and an understanding of how security scanners work. The axios compromise followed a textbook pre-staging strategy designed to avoid triggering the exact alarms that exist to catch this kind of attack.

The operation began on March 30, 2026, at 05:57 UTC - roughly 18 hours before the axios releases - when a brand-new npm account published a package called plain-crypto-js@4.2.0. The account's email was nrwise@proton.me. The package was clean. It contained a full, legitimate copy of the popular crypto-js library source code. No postinstall hook. No malicious code. No dropper. Its description, author attribution, and repository URL all pointed to the real crypto-js project on GitHub. To any scanner or human reviewer, it looked like a fork or mirror of a well-known package.

This was the decoy. Its sole purpose was to establish publishing history. Most npm security tools flag packages published from zero-history accounts as suspicious. By publishing a clean version first and waiting 18 hours, the attacker ensured that when the malicious version dropped, the account wouldn't trigger "brand-new publisher" alarms. The package had history. It had a prior clean version. It had been on the registry for almost a full day without incident.

At 23:59 UTC on March 30 - four minutes before midnight - plain-crypto-js@4.2.1 was published from the same account. This version was different. It added a postinstall hook to package.json: "postinstall": "node setup.js". It included a 4,209-byte obfuscated JavaScript file called setup.js. And it included a file called package.md - a clean package.json stub ready to overwrite the real manifest after the attack executed.

Twenty-two minutes later, at 00:21 UTC on March 31, axios@1.14.1 appeared on the npm registry. Published by jasonsaayman - the compromised account of the project's lead maintainer. The account's email had been changed to ifstap@proton.me, another ProtonMail address operated by the attacker. The shared ProtonMail pattern across both accounts - nrwise@proton.me for the malicious dependency, ifstap@proton.me for the hijacked maintainer - is a consistent operational signature that both StepSecurity and Socket have identified as belonging to the same threat actor.

At 01:00 UTC, axios@0.30.4 followed. Same injection. Same phantom dependency. But targeting the legacy 0.x branch, which is still actively used in older projects and enterprise codebases that haven't migrated to the 1.x line. By poisoning both branches simultaneously, the attacker maximized coverage: any project using a caret range like ^1.14.0 or ^0.30.0 would pull in the compromised version on its next install.

The Tell in the Metadata

The attack was technically sophisticated but left a forensic fingerprint that, in retrospect, should have been detectable by automated systems in real time. Every legitimate axios 1.x release is published via GitHub Actions with OIDC binding. The npm registry metadata for each release includes a trustedPublisher field containing the OIDC configuration ID, linking the publish cryptographically to the GitHub Actions workflow that produced it. The metadata also includes a gitHead field pointing to the specific commit in the axios repository.

Axios 1.14.1 had neither. No trustedPublisher. No gitHead. No corresponding commit or tag in the GitHub repository. The release existed only on npm - published manually via a stolen access token, from a terminal that was not part of the project's CI/CD infrastructure. StepSecurity documented the contrast directly:

This metadata gap is significant not just for forensics but for the broader ecosystem. npm already has the data to detect this pattern in real time. A package that has always been published via Trusted Publisher suddenly appearing without OIDC binding should trigger an immediate hold or review - the same way a credit card transaction from an unusual location triggers a fraud alert. As of this writing, npm does not implement this check automatically. That needs to change.

The Phantom Dependency: A Trojan Horse Made of JSON

The brilliance - and the horror - of this attack is its surgical precision. The attacker did not modify a single line of axios source code. No files were changed. No functions were altered. No test was broken. If you diff the source files between axios 1.14.0 and 1.14.1, they're identical. The only change is in package.json: one additional line in the dependencies object.

StepSecurity confirmed with a grep across all 86 files in the compromised package: plain-crypto-js is never imported, never required, never referenced anywhere in the axios source code. It is a phantom dependency - a package that exists in the manifest but has zero usage in the codebase. Its sole purpose is to be installed by npm's dependency resolution, which triggers the postinstall lifecycle hook that launches the dropper.

This technique is not new, but it's rarely executed this cleanly against a package of this scale. Most supply chain attacks involve modifying source code, adding malicious scripts directly, or hijacking build processes. The phantom dependency approach is harder to detect because it doesn't trip any of the usual static analysis checks: no suspicious function calls, no network requests in the main code, no obfuscated strings in the primary package. The malware lives entirely in a transitive dependency that most security tools won't examine until it's already been installed and executed.

Socket's analysis confirmed the approach. "A dependency that appears in the manifest but has zero usage in the codebase is a high-confidence indicator of a compromised release," StepSecurity noted in their technical breakdown. Socket separately flagged the package within six minutes of its publication using their automated scanner, which detected the postinstall hook and the characteristic obfuscation pattern. But six minutes is an eternity in npm's ecosystem - enough time for automated CI/CD pipelines worldwide to pull and install the compromised version.

Inside the RAT: A Self-Destructing, Cross-Platform Kill Chain

The dropper itself - setup.js, a single 4,209-byte minified file inside plain-crypto-js - is a masterclass in evasion engineering. It employs a two-layer obfuscation scheme that encodes every sensitive string - module names, OS identifiers, shell commands, URLs, file paths - in an array called stq[]. Two decoding functions strip the strings at runtime.

The first layer, _trans_1, implements an XOR cipher with the key string "OrDeR_7077". But the key is parsed through JavaScript's Number() function, which converts alphabetic characters to NaN. In bitwise operations, NaN becomes 0. Only the digits 7, 0, 7, 7 at positions 6 through 9 survive, producing an effective key of [0,0,0,0,0,0,7,0,7,7]. Each character is decoded as charCode XOR key[(7 * position * position) % 10] XOR 333. The quadratic index selection adds just enough non-linearity to defeat simple pattern matching.

The second layer, _trans_2, reverses the encoded string, replaces underscores with = characters (restoring base64 padding), decodes the result as base64 UTF-8, then passes it through the XOR cipher. This double encoding means that neither the base64-encoded strings nor the XOR-encoded strings appear in their recognizable forms in the source file. Automated scanners looking for known C2 URLs, suspicious shell commands, or OS detection patterns see nothing but an array of gibberish.

StepSecurity fully decoded all 18 entries in the stq[] array. The recovered plaintext reveals the complete attack infrastructure: child_process, os, fs for Node.js module access. The C2 base URL: http://sfrclak.com:8000/. Platform identifiers: win32, darwin. Shell command templates for each operating system. And the self-cleanup targets: package.json for deletion, package.md for replacement.

macOS: The AppleScript Path

On macOS systems, the dropper writes an AppleScript file to the system temp directory and executes it silently via osascript with nohup to ensure it survives the parent process terminating. The AppleScript contacts the C2 server with the POST body packages.npm.org/product0, downloads a binary RAT, saves it to /Library/Caches/com.apple.act.mond, makes it executable with chmod 770, and launches it in the background via /bin/zsh.

The persistence path is deliberately chosen. /Library/Caches/ is a system-owned directory that's rarely examined during incident response. The filename com.apple.act.mond mimics Apple's reverse-DNS daemon naming convention - the suffix likely abbreviates "Activity Monitor Daemon." An analyst scrolling through the Caches directory would see what appears to be a legitimate Apple system process. The AppleScript file self-deletes after execution.

Windows: VBScript, PowerShell, and a Disguised Interpreter

The Windows attack chain is more elaborate, involving three stages. First, the dropper runs where powershell to locate the PowerShell binary. Then it copies the PowerShell executable to %PROGRAMDATA%\wt.exe - disguised as the Windows Terminal executable, giving the attacker a persistent copy of the interpreter under a legitimate-looking filename. Finally, it writes a VBScript to the temp directory and executes it via cscript //nologo.

The VBScript spawns a completely hidden cmd.exe window (using WScript.Shell's Run method with visibility flag 0 and wait flag False), which contacts the C2 with POST body packages.npm.org/product1, receives a PowerShell RAT script, saves it as %TEMP%\6202033.ps1, and executes it with -ExecutionPolicy Bypass and -WindowStyle Hidden. Both the VBScript and PowerShell files self-delete after execution. The only persistent artifact is the copied PowerShell binary at %PROGRAMDATA%\wt.exe.

Linux: The Python Route

Linux gets the most direct attack path. The dropper executes a single shell command via Node.js's execSync: curl the C2 with POST body packages.npm.org/product2, save the response to /tmp/ld.py, and launch it with nohup python3 in the background. Unlike the macOS and Windows variants, the Linux payload doesn't self-delete from disk - /tmp/ld.py remains, making it the easiest variant to detect forensically.

The C2 Traffic Camouflage

A clever detail across all three platforms: the POST body sent to the C2 server starts with packages.npm.org/. This is not the npm registry (which lives at registry.npmjs.org). The domain npm.org belongs to the National Association of Pastoral Musicians and has since 1997. The string is the data payload sent to sfrclak.com:8000 via curl's -d flag. But in network logs and SIEM rules, a quick scan of outbound traffic would show packages.npm.org in the request body - a string that looks entirely benign for a JavaScript development environment. It's a deliberate attempt to make malicious traffic blend into the noise of legitimate npm activity.

The Evidence Swap: How the Malware Covers Its Tracks

The most unsettling aspect of this attack isn't the RAT deployment - it's what happens afterward. After launching the platform-specific payload, setup.js performs three forensic cleanup operations that make post-infection analysis dangerously unreliable.

First, it deletes itself. fs.unlink(__filename) removes setup.js from the node_modules/plain-crypto-js/ directory. The file that contained the obfuscated dropper no longer exists.

Second, it deletes the real package.json - the one containing the incriminating "postinstall": "node setup.js" hook that triggered the entire attack.

Third, it renames package.md to package.json. This pre-staged clean stub contains version 4.2.0 metadata, no scripts section, and no reference to setup.js. It's the decoy that the attacker planted before the attack even began.

The result: any post-infection inspection of node_modules/plain-crypto-js/package.json shows a completely clean manifest. Running npm audit reveals nothing. Manually reviewing the installed package directory shows no malicious files, no suspicious scripts, no evidence that anything unusual occurred. A developer who noticed the attack reports hours later and checked their own system would find... nothing. The malware deleted the evidence and left a convincing forgery in its place.

StepSecurity's Harden-Runner instrumentation caught the evidence swap in real time during their controlled reproduction. The file event log shows two writes to node_modules/plain-crypto-js/package.json from two different processes - PID 2380 (npm install) writing the malicious manifest at 01:30:50.905Z, and PID 2392 (node setup.js) overwriting it with the clean stub 36 seconds later at 01:31:27.736Z. The 36-second gap is the execution time of the dropper - proof that the malware ran to completion before cleaning up.

There is exactly one reliable indicator of compromise: the existence of the node_modules/plain-crypto-js/ directory itself. This package is not a dependency of any legitimate axios version. If you find this directory in your project, the dropper ran. Period. The contents of the directory will look clean. The damage was already done.

Runtime Proof: 1.1 Seconds From Install to C2 Contact

Static analysis tells you what malware intends to do. Runtime analysis tells you what it actually does. StepSecurity went further than most researchers by reproducing the attack in a live GitHub Actions runner instrumented with their Harden-Runner tool in audit mode - capturing every outbound network connection, every spawned process, and every file write at the kernel level without interfering with execution.

The results are alarming. The first C2 connection - a curl request from PID 2401 to sfrclak.com:8000 - fired at 01:30:51Z, just 1.1 seconds after npm install began at 01:30:49Z. The postinstall hook triggered, the obfuscated strings decoded, and an outbound HTTP connection to an external command-and-control server was established before npm had even finished resolving all dependencies. By the time npm install returned its success message to the terminal, the RAT dropper had already contacted the C2 and begun downloading its second-stage payload.

A second C2 connection appeared 36 seconds later - but not in the install step. It appeared in an entirely different workflow step called "Verify axios import and version." The npm install had finished long ago. The malware had persisted into subsequent steps as a detached background process - the nohup command that the dropper used to launch the Python payload on Linux had orphaned the process to PID 1 (init), completely severing it from the npm process tree.

This orphaning is the reason Harden-Runner labeled both connections with calledBy: "infra" instead of "runner". The process couldn't be attributed to a specific Actions step because it had deliberately abandoned its parent-child relationship. It was running independently, as an orphan process on the system. This is active evasion of process attribution - a technique more commonly associated with nation-state malware than open-source supply chain attacks.

The full process tree, reconstructed from Harden-Runner's kernel-level process events, shows four levels of indirection between the original npm install and the C2 callback: npm spawns sh, which spawns node setup.js, which spawns sh -c, which spawns curl and nohup python3. Each layer adds distance between the user's command and the malicious activity. By the time the RAT payload is running, the process ancestry has been scrubbed clean.

The Maintainer Problem: How One Stolen Token Compromised Everything

The root cause of this attack is a problem the npm ecosystem has known about for years but hasn't fully solved: the maintainer bottleneck. Axios, a package with 300 million weekly downloads and an incalculable number of dependent projects, had its publishing authority concentrated in a single npm account. When that account was compromised, everything downstream was exposed.

Socket's investigation revealed a particularly alarming detail. When the attack was first discovered, axios collaborators found they could not revoke the compromised account's access. In a public GitHub issue (#10604), a project collaborator stated that the attacker's permissions exceeded their own - meaning the compromised jasonsaayman account held the highest-level npm publishing rights for the axios package, and other project members lacked the authority to remove it.

This is a governance failure at the ecosystem level, not just at the project level. npm allows package owners to grant publishing rights, but the hierarchy of those rights - who can revoke whom, what happens when the top-level owner is compromised - is poorly defined and poorly tooled. The axios team had done many things right: they used GitHub Actions for CI/CD, they implemented OIDC Trusted Publishing, they had a multi-contributor development process. But the presence of a single long-lived classic npm access token on the primary maintainer's account undid all of that.

How the token was stolen remains unknown as of this writing. The axios team has stated they are investigating the compromise and working to secure the release pipeline. Early discussion in the project's GitHub issues suggests a focus on revoking all existing tokens, eliminating long-lived access tokens entirely, and tightening the publish workflow to require OIDC exclusively. These are necessary steps, but they address the symptom rather than the disease.

The disease is structural. npm's security model trusts individuals rather than processes. When a maintainer creates an access token, that token grants the same publishing authority as the OIDC workflow - but without any of the protections. No audit log showing which machine was used. No cryptographic binding to a specific CI/CD pipeline. No MFA challenge at publish time (npm does offer MFA for publishes, but enforcement is optional and adoption rates are estimated to be below 20% for packages with over a million weekly downloads, according to a 2025 Socket analysis). The token is a skeleton key, and every maintainer who creates one is creating a point of failure for everyone who depends on their package.

The Bigger Picture: Supply Chain Attacks Are Accelerating

The axios compromise doesn't exist in isolation. It's the latest entry in a rapidly expanding catalog of open-source supply chain attacks that have grown more frequent, more sophisticated, and more damaging throughout 2025 and into 2026.

Earlier in March 2026, the threat actor known as TeamPCP compromised the Telnyx Python SDK on PyPI, deploying credential-stealing malware through a multi-stage supply chain attack (Socket, March 27). The same group partnered with ransomware group Vect to turn supply chain attacks on security tools like Trivy and LiteLLM into ransomware delivery vectors (Socket, March 26). A widespread GitHub campaign used fake VS Code security alerts to drive developers to malicious sites (Socket, March 25). Five malicious npm packages typosquatting Solana and Ethereum libraries were caught stealing private keys via Telegram (Socket, March 24).

And that's just March. The pattern extends back through the XZ Utils compromise of March 2024, the event-stream attack of 2018, the ua-parser-js hijack of 2021, and dozens of smaller incidents that never made headlines. Each attack refines the playbook. The XZ Utils attack demonstrated that nation-state actors were willing to spend years building trust in open-source projects before deploying a backdoor. The axios attack demonstrates that the same impact can be achieved in 18 hours if you steal the right token.

The rate of escalation is the most concerning trend. According to Socket's 2025 annual report, the number of malicious packages detected on npm, PyPI, and other registries increased roughly 40% year-over-year. The average time from package publication to detection fell from 14 days in 2023 to under 24 hours in 2025 - a testament to improved automated scanning. But the attackers are adapting too, using techniques like the self-destructing evidence swap in the axios attack to make detection after the initial window nearly impossible.

The fundamental problem remains unsolved: the entire modern software industry runs on a trust model that was designed for a world where open-source packages were published by hobbyists sharing code with friends, not serving as critical infrastructure for Fortune 500 companies and government agencies. The security measures layered on top of this model - token rotation, MFA, signed commits, trusted publishing - are improvements, but they're patches on a foundation that wasn't built for this threat environment.

What Needs to Change

Several structural reforms could reduce the blast radius of future attacks, though none would eliminate the risk entirely:

Mandatory publish-pattern monitoring. npm already records whether a package is published via OIDC Trusted Publisher or a classic token. If a package that has exclusively used OIDC for its last N releases suddenly publishes via classic token, that should trigger an automatic hold for review. This single check would have caught the axios attack before any user installed it.

Deprecation of long-lived access tokens. npm should set an aggressive timeline for deprecating classic access tokens in favor of short-lived, scoped tokens or OIDC-only publishing for packages above a download threshold. The axios maintainer had OIDC set up and working - the classic token was a legacy artifact that should have been revoked.

Postinstall hook quarantine. The postinstall lifecycle hook is the most commonly exploited attack vector in npm supply chain attacks. npm should offer maintainers the option to mark their packages as not requiring postinstall execution, and should warn or block when a transitive dependency adds a postinstall hook that wasn't present in its prior version.

Phantom dependency detection. Dependencies that appear in package.json but are never imported in the codebase should be flagged automatically by security scanners and CI/CD tools. This pattern - a dependency with zero usage - is a high-confidence indicator of compromise and could be detected statically before any code executes.

Multi-party publish authorization. Packages above a certain download threshold should require multiple maintainer approvals for new releases, similar to how financial transactions above certain amounts require dual authorization. A single compromised account should not be able to unilaterally publish to 300 million downstream projects.

What We Still Don't Know

Several critical questions remain unanswered as the investigation continues.

How was the maintainer's token stolen? Phishing, credential reuse from a data breach, malware on the maintainer's development machine, or a compromise of a service where the token was stored are all possibilities. The method matters because it determines whether this attack is repeatable against other npm maintainers using similar workflows.

How many systems were compromised during the exposure window? Socket flagged the malicious dependency within six minutes. StepSecurity published their analysis within hours. But automated CI/CD pipelines run continuously. Docker image builds, deployment workflows, development environment setups - any of these that ran npm install with a caret range during the exposure window could have pulled in the poisoned version. The malware's self-cleanup means most compromised systems will show no evidence of the attack unless they were running kernel-level monitoring like Harden-Runner.

Who is behind it? Neither StepSecurity nor Socket has attributed the attack to a known threat actor. Socket explicitly noted they have "not observed any evidence linking this activity to the recently reported TeamPCP campaigns." The operational pattern - ProtonMail accounts, pre-staged clean decoys, platform-specific payloads, anti-forensic cleanup - suggests a sophisticated actor, but the attribution remains open.

What was the second-stage payload? The RAT dropper downloads platform-specific payloads from the C2 server. The analysis covers the dropper in exhaustive detail, but the second-stage payloads themselves - the actual RAT code running on compromised systems - have not been fully characterized in the public analyses. What capabilities does the RAT provide? Keylogging? Screen capture? File exfiltration? Lateral movement? Persistence through reboots? These questions will be critical for organizations assessing their exposure.

Is the C2 still active? The command-and-control server at sfrclak.com:8000 was live during StepSecurity's controlled reproduction. Whether it remains active, has been seized by law enforcement, or has been rotated to a new domain is unknown. Organizations should check network logs for connections to this address regardless.

The axios team has begun remediation. The compromised versions have been flagged on npm. The maintainer's access has been secured. The release pipeline is being locked down. But the damage from the exposure window - however brief - may take months or years to fully assess. That's the nature of supply chain attacks: the blast radius isn't measured in the moment of compromise but in the long tail of systems that pulled in the poisoned dependency and never knew it.

The JavaScript ecosystem's most-downloaded HTTP library was weaponized overnight. It took 18 hours of pre-staging, one stolen token, and 39 minutes of execution. The malware contacted its C2 server in 1.1 seconds, then erased every trace of itself. This is what modern supply chain warfare looks like. And it's moving faster than the defenses built to stop it.