The Axios npm Hack: How a Single Stolen Token Delivered a RAT to Millions of Developers

A single compromised npm token. Two backdoored package versions. A cross-platform Remote Access Trojan calling home 1.1 seconds into npm install. That is what happened to Axios — the HTTP client library downloaded over 100 million times per week — on 31 March 2026.

This was not a theoretical supply chain risk. It was a live demonstration of how one hijacked maintainer account can push malicious code into CI/CD pipelines across the globe in under a minute.

Here is what happened, how it worked, and what your organisation should be doing about it.

What Happened

On 31 March 2026, an unknown threat actor compromised the npm account of Jason Saayman (jasonsaayman), the lead maintainer of the Axios library. Using a long-lived classic npm access token, the attacker published two backdoored versions — [email protected] and [email protected] — directly to the npm registry.

Both versions contained a single change: a new dependency called [email protected]. That package carried a postinstall script that deployed a full-featured RAT across macOS, Windows, and Linux.

The attacker had pre-staged a clean version of plain-crypto-js (v4.2.0) roughly 18 hours earlier to build a brief package history and evade new-package scanners.

Timeline (UTC)

The exposure window was approximately three hours. Both the 1.x and 0.x release branches were poisoned within 39 minutes of each other, maximising the number of affected consumers.

How the Attack Worked

The attacker never modified a single line of Axios source code. All 85 library files in the published packages were bit-for-bit identical to the legitimate versions. The only change was in package.json: a new dependency entry.

This is important. Code review of the library source would have revealed nothing. The attack lived entirely in the dependency graph.

The Malicious Payload

The plain-crypto-js package contained a setup.js postinstall script (4.2 KB) with two layers of obfuscation:

1. Base64 decoding with a character substitution trick (underscore-to-equals padding)
2. XOR cipher using a key derived from the string "OrDeR_7077", applying the formula: charCode XOR key[(7 * r * r) % 10] XOR 333

When decoded, the script performed the following:

• Fingerprinted the host: hostname, username, OS version, CPU architecture
• Contacted C2: http://sfrclak[.]com:8000/ with campaign ID 6202033
• Downloaded platform-specific RAT payloads

The C2 callback happened 1.1 seconds into npm install — before npm had even finished resolving other dependencies.

Platform-Specific Payloads

macOS: Binary dropped to /Library/Caches/com.apple.act.mond, executed via AppleScript and /bin/zsh, with ad-hoc code signing to bypass Gatekeeper. The RAT supported process injection, remote shell execution, directory browsing, and credential harvesting. It beaconed to C2 every 60 seconds.

Windows: VBScript and PowerShell chain. PowerShell was copied to %PROGRAMDATA%\wt.exe (disguised as Windows Terminal) with execution policy bypass. Staging files landed in %TEMP%.

Linux: Direct curl fetch of a Python script to /tmp/ld.py, executed via nohup python3 as an orphaned background process — fully detached from the npm process tree.

Anti-Forensics

After launching its payload, the dropper:

1. Deleted setup.js
2. Removed the malicious package.json
3. Renamed a pre-staged package.md (reporting version 4.2.0) to package.json

Post-infection, running npm list would report [email protected] — the known-clean version. Inspecting node_modules after the fact was useless. The malware had erased its own tracks.

Why This Attack Matters

Axios is present in approximately 80% of cloud and code environments. It is one of the most depended-upon packages in the JavaScript ecosystem. According to researchers, 3% of affected environments showed evidence of the malicious code executing during the three-hour window.

Three per cent might sound small. Applied to Axios's install base, that is a significant number of compromised developer machines, CI/CD pipelines, and build environments — each one a potential foothold into corporate networks, cloud infrastructure, and production systems.

This Was Not Opportunistic

The sophistication of this attack — pre-staging packages, multi-platform payloads, anti-forensic cleanup, credential harvesting without ransomware or cryptomining — points away from financially motivated cybercrime. Multiple security researchers have assessed this as likely espionage or APT activity: an actor interested in persistent access to developer environments and the credentials they contain.

Developer machines are high-value targets. They typically hold SSH keys, cloud API tokens, CI/CD secrets, database credentials, and access to source code repositories. Compromising one developer machine can provide lateral movement into an organisation's entire infrastructure.

The CI/CD Bypass

Axios uses OIDC-based GitHub Actions with Trusted Publisher workflow for legitimate releases. The attacker bypassed this entirely by publishing manually with the stolen npm token. The malicious versions had no trustedPublisher field, no gitHead, and no corresponding GitHub commit or tag.

This exposes a fundamental gap: Trusted Publishers only work if token-based publishing is disabled entirely. As long as classic tokens can bypass the CI/CD pipeline, they represent a single point of failure.

Am I Affected?

If your organisation ran npm install between approximately 00:21 and 03:29 UTC on 31 March 2026, check your projects immediately.

Check for Compromised Versions

macOS / Linux:

# Check installed axios version
npm ls axios

# Search lock files for compromised versions
grep -r "[email protected]\|[email protected]" package-lock.json
grep -r "plain-crypto-js" package-lock.json

Windows (PowerShell):

npm ls axios
Select-String -Path package-lock.json -Pattern "[email protected]|[email protected]|plain-crypto-js"

Check for RAT Artefacts

# macOS
ls -la /Library/Caches/com.apple.act.mond

# Linux
ls -la /tmp/ld.py

# Windows (PowerShell)
Test-Path "$env:ProgramData\wt.exe", "$env:TEMP\6202033.vbs", "$env:TEMP\6202033.ps1"

If the compromised version was installed but no RAT artefacts are present, downgrade immediately:

npm install [email protected]   # 1.x users
npm install [email protected]   # 0.x users
rm -rf node_modules/plain-crypto-js

If any RAT artefacts are found: treat the system as fully compromised. Isolate from the network. Rebuild from a known-good state. Rotate all credentials — npm tokens, AWS keys, SSH keys, CI/CD secrets, environment variables, cloud credentials. Do not attempt in-place cleaning.

Network and Hash IOCs

Block the following at your firewall and use the hashes for threat hunting across your estate.

Network:

• Domain: sfrclak[.]com
• IP: 142.11.206.73
• Port: 8000

Package hashes (SHA1):

• [email protected]: 2553649f2322049666871cea80a5d0d6adc700ca
• [email protected]: d6f3f62fd3b9f5432f5782b62d8cfd5247d5ee71
• [email protected]: 07d889e2dadce6f3910dcbc253317d28ca61c766

What This Tells Us About Supply Chain Security

This incident reinforces several uncomfortable truths about the state of software supply chains.

Postinstall Scripts Are a Critical Attack Surface

The entire attack executed through npm's postinstall lifecycle hook. No Axios code was imported. No library function was called. The malware ran purely because npm install triggered a script. Running npm ci --ignore-scripts in CI/CD pipelines would have prevented execution entirely.

New Dependency Detection Matters

The only change to Axios was a new dependency that was never imported in any source file. Dependency audits that flag new packages added but never referenced in code would have caught this anomaly. Most organisations do not perform this check.

Age-Based Package Blocking Works

[email protected] existed for less than 24 hours before it was weaponised. Security tools that block packages younger than 48 hours from entering production builds would have stopped the attack cold. This is a simple policy with outsized defensive value.

Point-in-Time Audits Are Insufficient

The malware deleted its own traces. Post-infection node_modules inspection showed a clean state. Organisations relying solely on periodic audits or manual code review of dependencies missed the window entirely. Runtime monitoring, install-time logging, and network-level detection are necessary complements.

Speed Is Everything

Six minutes from publication to first detection (Socket.dev). Three hours to full removal. 1.1 seconds from install to C2 contact. The attacker designed every step for speed — and so must defenders. Automated, real-time scanning of package registries and build pipelines is not optional for organisations at scale.

Key Takeaways

• A single compromised npm token bypassed all CI/CD protections and delivered a RAT to one of the most widely-used JavaScript libraries.
• The attack was invisible to source code review — the malicious payload lived entirely in the dependency graph and a postinstall script.
• Developer machines are high-value targets containing credentials that enable lateral movement across cloud, infrastructure, and production systems.
• Passive, point-in-time security assessments cannot catch attacks designed for speed and self-destruction. Continuous monitoring is a requirement, not a luxury.
• Supply chain security is not just about your code. It is about every dependency, every maintainer account, and every build step in your pipeline.

Protect Your Organisation's Software Supply Chain

Supply chain attacks like the Axios compromise exploit the trust relationships between software components, maintainers, and the organisations that depend on them. Defending against them requires continuous visibility, not periodic snapshots.

RavenEye provides continuous attack surface monitoring that detects changes in your external exposure — including vulnerable dependencies and compromised assets — before attackers exploit them. Automated scanning identifies the risks that point-in-time audits miss.

Vulnerability Disclosure Program (VDP) gives external security researchers a trusted, managed channel to report vulnerabilities in your applications and infrastructure. If a researcher spots a compromised dependency in your public-facing systems, a VDP ensures that report reaches your security team — not a public disclosure that damages trust.

Bug Bounty Program extends that coverage with incentivised, continuous security testing from a global community of researchers. Crowdsourced testing catches what automated tools and internal teams cannot — including subtle supply chain risks embedded in build processes and deployment pipelines.

Supply chain compromises will continue. The question is whether your organisation detects them in minutes or discovers them in months. Talk to V-Formation about building continuous security into your development lifecycle.