Axios npm Hijacked | RAT Malware in 83M Download Library

The attack began with a credential compromise of jasonsaayman, the lead maintainer of the axios GitHub repository and npm package. The attacker obtained jasonsaayman's npm login credentials, changed the account's registered email address to a ProtonMail address, and gained full publish rights to the package.

Once in control, the attacker manually published two malicious releases: axios@1.14.1 and axios@0.30.4. Both bypassed the project's standard GitHub Actions CI/CD pipeline entirely. Neither has a corresponding GitHub commit or tag, a clear deviation from the project's established release hygiene, where every legitimate 1.x release is published via npm's OIDC Trusted Publisher mechanism with a verifiable commit in the repository.

The choice to target axios was deliberate. With roughly 83 million weekly downloads, axios sits in the dependency trees of an enormous share of Node.js applications, CI/CD build pipelines, and serverless functions. A malicious version that goes undetected for even a few hours can propagate to tens of thousands of developers running npm install in automated pipelines.

According to Socket's incident report, the malicious dependency plain-crypto-js@4.2.1 was published to npm at exactly 23:59:12 UTC on March 30, 2026. Socket's automated detection pipeline flagged it as malicious at 00:05:41 UTC on March 31, a response window of 6 minutes and 29 seconds.

StepSecurity independently confirmed the same findings. Both firms cross-analyzed the malicious versions and identified the injected dependency as the sole mechanism. Critically, the axios source code itself was not modified. The attack worked by adding a dependency to the package's package.json at publish time, meaning the malicious payload would only execute on a fresh npm install, not in any existing node_modules folder already present on a developer's machine.

Rather than embedding malware directly in axios source code, the attacker decoupled the payload into a separate package, plain-crypto-js@4.2.1, which was published to npm at the same time. This staging approach is tactically significant: it allows the attacker to update or swap the payload independently and reduces the volume of suspicious code visible in the axios diff itself.

The dropper's first layer used reversed string constants, a technique that trivially evades pattern-matching scanners looking for known malicious strings. After reversal, a base64-encoded blob was decoded to produce the second layer. That second layer was then XOR-decrypted with a key embedded in the first layer, yielding fully executable JavaScript. The result was a minimal but functional stager: detect OS, contact C2, download payload, execute, clean up.

The C2 server at sfrclak.com:8000 served three distinct payloads, one per platform. Cross-platform targeting at this level of specificity indicates operational maturity. A generic supply chain attack might target only a single platform or use a platform-agnostic interpreted payload. Providing OS-matched binaries requires more infrastructure investment and signals the attacker expected to infect machines across polyglot development environments, including full-stack developers on macOS running Linux servers and Windows CI agents.

The absence of a corresponding GitHub tag or commit for either malicious version is the clearest signal that something was wrong, and the one that developers with proper tooling could catch immediately. Legitimate axios releases follow a strict pattern: a version bump commit, a v1.x.x tag, a GitHub Actions workflow run, and a resulting npm publish with OIDC provenance attestation attached.

None of those artifacts exist for versions 1.14.1 or 0.30.4. A developer running npm info axios@1.14.1 would see no provenance block. A developer checking the axios GitHub repository would find no release entry, no tag, and no pull request associated with those version numbers.

For engineering teams using dependency pinning, lockfiles (package-lock.json, yarn.lock), and provenance verification in CI, this attack would have had no effect. The threat was concentrated among developers running unguarded npm install commands against floating version ranges such as ^1.14.0, which would have resolved to 1.14.1.

Both malicious versions have been unpublished from the npm registry. However, developers who ran npm install during the window between 23:59:12 UTC on March 30 and roughly 01:00 UTC on March 31 may have received poisoned packages. The dropper's self-deletion makes post-hoc detection difficult.