Axios npm Attack: Hijacked Maintainer Account Threatened…

8 min read

On 31 March 2026, security firm StepSecurity uncovered a remote-access Trojan (RAT) hidden in two tampered versions of the npm package Axios—one of the world’s most-used JavaScript libraries, with more than 100 million weekly downloads. The attack weaponised a fake dependency, a hijacked maintainer account, and a command-and-control server to plant cross-platform backdoors on developers’ machines. It ranks among the most sophisticated supply-chain strikes ever recorded in the npm ecosystem.

What happened

Axios has been a staple JavaScript library for HTTP requests for more than a decade. Even though modern runtimes like Node.js and Deno now ship with the native Fetch API, millions of developers still prefer Axios for its friendlier API, automatic JSON parsing, and built-in interceptors. That popularity made it a prime target.

On 30 March 2026 at 23:59 UTC, an attacker published version 4.2.1 of npm package plain-crypto-js—a lookalike of the legitimate and widely used crypto-js. Twenty-two minutes later, the poisoned Axios 1.14.1 appeared, tagged “latest.” At 01:00 UTC the same night, version 0.30.4 surfaced, tagged “legacy.” Both Axios builds declared plain-crypto-js as a new runtime dependency.

The operation was meticulously staged. Eighteen hours earlier the attacker had released a harmless plain-crypto-js 4.2.0—a decoy that would sail past automated scans. Only version 4.2.1 carried the actual payload.

Normally Axios releases flow through GitHub Actions. The poisoned versions, however, were pushed directly from a compromised npm account. The attacker had seized control of lead maintainer jasonsaayman’s account and swapped the registered e-mail for a ProtonMail address. Exactly how the account was hijacked remains unconfirmed as of April 2026.

npm removed both malicious releases within roughly two to three hours. For a package clocking 100 million weekly downloads, even a few hours is a critical exposure window.

Anatomy of the Attack: From postinstall Script to C2 Server

The source code of Axios itself contained no malicious code. The manipulation was limited to adding plain-crypto-js as a dependency in the package.json. Anyone auditing only the Axios code would have found nothing. The real weapon was hidden in the new dependency.

The plain-crypto-js package included a postinstall script called setup.js. As soon as a developer ran npm install, a two-stage XOR-obfuscated JavaScript executed in the background—the so-called RAT dropper. It operated in four phases:

Phase 1 – System Detection: The script identifies the target system’s operating system. macOS, Windows, and Linux are supported.

Phase 2 – Payload Download: The dropper establishes a connection to the command-and-control server (domain: sfrclak.com, IP: 142.11.206.73, port 8000). From there, a platform-specific binary is downloaded.

Phase 3 – Execution: The RAT is written to disk and launched. On macOS it lands as com.apple.act.mond in the Library Cache and is executed via /bin/zsh. On Windows it disguises itself as wt.exe (Windows Terminal) in %PROGRAMDATA% and uses a VBScript dropper. On Linux a Python RAT is downloaded to /tmp/ld.py and started in the background with nohup.

Phase 4 – Cleanup: The postinstall script deletes itself and replaces the package.json with the clean version 4.2.0. Running npm list then shows version 4.2.0. An npm audit finds no anomalies. The infection is active yet invisible.

Once installed, the RAT gains access to everything on the compromised system: AWS credentials, OpenAI API keys, GitHub tokens, SSH keys, .env files with database passwords. In CI/CD environments the impact can be even more severe: deployment credentials, signing keys, and access to production systems often reside there. A compromised build server can become the gateway to the entire infrastructure.

StepSecurity discovered the attack via their AI Package Analyst and the runtime-monitoring tool Harden-Runner in instrumented GitHub Actions pipelines. The tool logs outgoing network connections during npm install and raised the alarm when an unknown C2 server was contacted.

“The most important security tip has been to keep your packages up to date for years. Lately it feels like doing exactly that is the fastest way to get compromised.”
– Editorial note

Why this attack is a new level of threat

Supply-chain attacks on npm aren’t new. The 2018 event-stream incident went undetected for months and targeted crypto wallets. The 2021 compromise of ua-parser-js affected a package with seven million weekly downloads and distributed credential stealers. The 2022 sabotage of colors.js was a political protest by the maintainer themselves. Each of these incidents shook the ecosystem—and yet the Axios attack marks an escalation.

The target is unprecedented: Axios is among the top ten most-used npm packages overall. A successful compromise could ripple out to hundreds of thousands of projects and CI/CD pipelines worldwide.

The sophistication far exceeds earlier attacks. Instead of injecting malicious code directly into the source, the attacker used a staged dependency-injection with time-delayed activation and automatic cleanup. After installation the system looked clean—a form of active camouflage that goes beyond passive hiding. StepSecurity logged the first C2 contact within two seconds of an npm install on an instrumented runner; without that automated monitoring the attack might have gone undetected for far longer.

Comparing it to earlier npm incidents highlights the escalation: in the 2018 event-stream attack an attacker took over an abandoned package via social engineering and planted malicious code over months targeting Bitcoin wallets. In the 2021 ua-parser-js compromise the maintainer’s account was hijacked and a credential stealer was distributed—similar to Axios, but without the multi-layer obfuscation or cross-platform payloads. The 2022 colors.js sabotage was a deliberate protest by the maintainer, not an external compromise.

Attribution adds another layer: Microsoft Threat Intelligence ties the attack to the group Sapphire Sleet, while Google Threat Intelligence Group labels it UNC1069. Both point to North-Korean actors with financial motives. Elastic Security Labs identified overlaps between the macOS binary and WAVESHAPER, a known North-Korean backdoor. If confirmed, this would be the first documented case of a state actor compromising a top-100 npm package.

What IT teams must do now

The compromise affects more than just JavaScript developers. Every organisation that uses Axios in its projects or CI/CD pipelines should prioritise the following steps:

1. Check versions: Inspect all package.json and lock files for axios@1.14.1 or axios@0.30.4. Immediately downgrade to 1.14.0 or 0.30.3 respectively.
2. Scan node_modules: Search for the package plain-crypto-js. If found, treat the system as compromised.
3. Inspect RAT artefacts: On macOS look for /Library/Caches/com.apple.act.mond, on Windows for %PROGRAMDATA%/wt.exe, on Linux for /tmp/ld.py.
4. Rotate credentials: Renew every API key, token and access credential on affected systems at once – AWS, OpenAI, GitHub, .env files.
5. Block C2: Block IP 142.11.206.73 and domain sfrclak.com at the network perimeter.
6. Secure CI/CD: Make npm ci –ignore-scripts the default. Activate minimum-release-age policies so freshly published versions are not installed automatically.

The structural vulnerability remains

The Axios incident exposes a fundamental flaw in the npm ecosystem: a single account with a valid publish token can push malicious code to millions of systems. npm has made progress with Trusted Publishers and OIDC-based authentication – yet the attacker bypassed this very mechanism by taking over the maintainer account itself.

For CISOs and IT-security teams the takeaway is clear: software-supply-chain security must command the same priority as network or endpoint security. Automated dependency monitoring, runtime analysis within CI/CD pipelines and rigorous third-party-package policies are no longer nice-to-haves.

Concretely, every organisation needs an up-to-date Software Bill of Materials (SBOM), automated alerts for unusual dependency changes and a clear policy governing how quickly new package versions may reach production. Consistently using lock files, disabling postinstall scripts in CI/CD by default and configuring minimum-release-age policies are three measures that eliminate most of this attack surface. The next attack will not target Axios – yet it will exploit the same mechanics.

Frequently Asked Questions

Am I affected if I use Axios?

Only if you have version 1.14.1 or 0.30.4 installed. All other versions are safe. Check your package.json and lock files (package-lock.json, yarn.lock, pnpm-lock.yaml).

Is uninstalling the affected Axios version enough?

No. If the RAT has already executed, it copied itself into system paths and deleted the postinstall script. Downgrading Axios alone will not remove the trojan. Treat the system as compromised and rotate all credentials.

How was the maintainer account compromised?

The exact attack vector remains unconfirmed as of April 2026. It is known that the npm account’s registered e-mail address jasonsaayman was replaced with a ProtonMail address and the releases bypassed the regular GitHub Actions pipeline.

Is there a CVE number for this incident?

As of April 2026 no CVE has been assigned. Several security firms have documented the incident, but formal CVE assignment is still pending.

Why didn’t npm detect the malicious versions sooner?

npm does not perform automated behavioural analysis at publish time. Packages are primarily scanned for known malware signatures. A postinstall script that contacts an external server is technically unremarkable – many legitimate packages use similar mechanisms for setup steps. Detection occurred through external monitoring, not npm’s own safeguards.

What can I do to mitigate supply-chain attacks in general?

Use lock files consistently, run npm ci instead of npm install in CI/CD pipelines, enable –ignore-scripts for untrusted packages and adopt runtime-monitoring tools. A minimum-release-age policy prevents freshly published versions from being installed automatically. Teams should also maintain a Software Bill of Materials (SBOM) and set up automated alerts for dependency changes.

Image source: AI-generated (May 2026), C2PA certificate embedded in image

About the author: Benedikt Langer

More articles by Benedikt Langer