# How North Korea Poisoned the npm Package You Use Every Day: The Axios Supply Chain Attack (2026)

TL;DR — On March 31, 2026, North Korean state-sponsored hackers (UNC1069 / Sapphire Sleet) compromised the axios npm package — used in 80% of all cloud environments with over 100 million weekly downloads — and deployed a cross-platform backdoor called WAVESHAPER.V2 for three hours. If you use axios, read this now.

---

The Package That Runs the Internet

Before we talk about the attack, let's appreciate the target.

axios is not just another npm package. It is the most widely used JavaScript HTTP client in existence. If you've built a React app, a Next.js project, a Node.js API, or virtually any modern JavaScript application — you've almost certainly used it.

npm install axios
# Downloaded ~100 million times per week
# Present in ~80% of cloud and code environments
# One of the top 10 npm packages of all time

Now imagine that package was weaponized by a nation-state actor at midnight on a Sunday. That's exactly what happened.

---

The Timeline: 3 Hours That Shook the Ecosystem

~2 weeks before  → UNC1069 social engineers axios maintainer Jason Saayman
March 30, 2026   → Attacker gains access to maintainer's npm account
March 31, 00:21 UTC → Malicious axios v1.14.1 and v0.30.4 published to npm
March 31, 00:45 UTC → Sophos detects activity in customer telemetry
March 31, 09:49 PM ET (prior) → Huntress SOC flags wt.exe on multiple endpoints
March 31, ~03:20 UTC → Malicious packages removed from npm registry
Total exposure window: ~3 hours
Estimated victims: ~3% of axios userbase, 135+ endpoints confirmed by Huntress

Three hours. That's all it took for a package present in hundreds of thousands of codebases to become a global attack vector.

---

How the Attack Was Executed

Step 1 — Social Engineering the Maintainer

This was not a brute-force attack. It was a carefully crafted human deception.

According to axios maintainer Jason Saayman in his post-mortem, the attackers approached him posing as the founder of a legitimate, well-known company. They had:

• Cloned the founder's likeness and identity
• Created a fully branded Slack workspace with plausible channels
• Shared real LinkedIn posts to build credibility
• Scheduled a Microsoft Teams call with him

When Saayman joined the Teams call, the attackers displayed a technically plausible error message and prompted him to download a native app. When he refused, they asked him to run a curl command in Terminal. When that also failed, they went dark — but they had already compromised his account weeks earlier through prior interaction.

"They had channels where they were sharing LinkedIn posts. The Slack workspace was thought out very well." — Jason Saayman, axios maintainer

Step 2 — Account Takeover & Token Abuse

Once the attackers had access, they:

1. Changed the maintainer email to an attacker-controlled address ([e-mail])
2. Used a long-lived npm access token to publish directly via the npm CLI
3. Bypassed 2FA entirely — because long-lived tokens don't require it
4. Bypassed GitHub Actions OIDC — because when both a token and OIDC credentials are present, npm uses the token

// Critically, the publish workflow still passed NPM_TOKEN alongside OIDC credentials
// When both exist, npm uses the token — making OIDC protections irrelevant
"scripts": {
  "publish": "npm publish --access public"
}

This is a critical architectural flaw in npm's security model that the attack exposed.

Step 3 — Malicious Dependency Injection

The compromised axios versions (1.14.1 and 0.30.4) introduced a hidden dependency:

// Inside the compromised axios package.json
{
  "dependencies": {
    "plain-crypto-js": "4.2.1"  // ← Malicious package injected here
  }
}

The plain-crypto-js package was a trojanized dropper. Inside its package.json:

{
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1",
    "postinstall": "node setup.js"  // ← Executes automatically on npm install
  }
}

The postinstall hook is a legitimate npm feature used by many packages. The attackers weaponized it to silently execute malicious code without any user interaction — just running npm install was enough.

Step 4 — Payload Delivery (WAVESHAPER.V2)

The setup.js dropper (internally named SILKBELL by Google's GTIG) performed OS detection and fetched platform-specific payloads from the C2 server at sfrclak[.]com (IP: 142.11.206.73):

Platform	Payload Language	Capabilities
Windows	PowerShell	System recon, file enumeration, code execution
macOS	C++	Directory enumeration, payload execution
Linux	Python	Remote access, lateral movement

The backdoor, WAVESHAPER.V2, was a fully functional RAT capable of:

• System reconnaissance and environment fingerprinting
• File system enumeration
• Executing additional payloads remotely
• PE injection (Windows variant)
• Communicating via base64-encoded JSON beacons to evade SIEM detection

The C2 traffic was deliberately crafted to mimic legitimate npm registry traffic using the prefix packages.npm.org — a clever SIEM evasion technique, since npm.org (not the actual npm registry) has belonged to the National Association of Pastoral Musicians since 1997.

// Fake C2 traffic pattern designed to blend in:
POST https://packages.npm.org/product1/[OS-identifier]
// Looks like npm traffic. Is actually C2 communication.

---

Who Did This? Attribution Deep Dive

Three major security organizations independently attributed this attack:

Organization	Threat Actor Name	Notes
Google GTIG / Mandiant	UNC1069	Active since 2018, financially motivated
Microsoft Threat Intelligence	Sapphire Sleet (aka CryptoCore, BlueNoroff, APT38)	Focus: crypto, VC, blockchain
Sophos CTU	NICKEL GLADSTONE	Identical forensic metadata and C2 patterns

These are all names for the same North Korean state-sponsored group — an offshoot of BlueNoroff, a unit under the Lazarus Group, which operates under North Korea's Reconnaissance General Bureau.

Their primary mission: generate revenue for the North Korean regime. The UN Panel of Experts estimated this group stole approximately $1.7 billion in cryptocurrency in 2024 alone.

The axios attack marks a significant strategic evolution: instead of targeting individual crypto wallets or exchanges, they're now targeting development infrastructure itself — the tools developers use to build everything else.

---

Are You Affected? How to Check Right Now

# Check if you installed the compromised versions
npm list axios | grep -E "1\.14\.1|0\.30\.4"

# Check your package-lock.json
grep -E '"axios".*"1\.14\.1|0\.30\.4"' package-lock.json

# Check for the malicious dependency
npm list plain-crypto-js

# Audit your full dependency tree
npm audit

If you find axios 1.14.1 or 0.30.4:

# Update to a clean version immediately
npm install axios@latest

# Remove plain-crypto-js if present
npm uninstall plain-crypto-js

# Check for the malicious binary on Windows
# Look for: C:\ProgramData\wt.exe

# Check C2 connections in your logs
# IOC: sfrclak[.]com | 142.11.206.73

Treat any system that installed either version as fully compromised. Removing the package does not undo backdoor deployment — the RAT may already have established persistence.

---

Indicators of Compromise (IOCs)

# Malicious packages
axios@1.14.1
axios@0.30.4
plain-crypto-js@4.2.1

# Attacker-controlled email
[e-mail]

# C2 Infrastructure
Domain: sfrclak[.]com
IP:     142.11.206.73

# Malicious binary (Windows)
C:\ProgramData\wt.exe

# SILKBELL dropper (setup.js) SHA256
e10b1fa84f1d6481625f741b69892780140d4e0e7769e7491e5f4d894c2e0e09

# WAVESHAPER.V2 (PowerShell) MD5
04e3073b3cd5c5bfcde6f575ecf6e8c1

# WAVESHAPER.V2 (SILKBELL) MD5
7658962ae060a222c0058cd4e979bfa1

# C2 traffic pattern (SIEM evasion)
packages.npm.org/product[1-4]

---

The Bigger Security Lessons

Lesson 1: The postinstall Hook Is a Danger Zone

The npm postinstall lifecycle script executes automatically after every npm install. It requires no user approval, no prompt, no confirmation. This is a systemic design issue that has now been weaponized at scale.

# Before installing any package, inspect its postinstall scripts
npm pack [package-name] --dry-run
cat node_modules/[package]/package.json | grep -A5 '"scripts"'

# Or use a tool like Socket.dev to scan before install
npx socket npm install axios

Lesson 2: Long-Lived Tokens Are a Liability

The attackers didn't need to crack any passwords. They used a long-lived access token that bypassed all other security controls — 2FA, OIDC, hardware keys. All of it irrelevant.

# Audit your npm tokens
npm token list

# Revoke all tokens and rotate
npm token revoke [token-id]

# Use granular, short-lived tokens with publish restrictions
npm token create --read-only
npm token create --cidr=[your-ci-ip-range]

Lesson 3: Social Engineering Targets Humans, Not Systems

No technical control stopped this attack. The attacker defeated the human first. As security researcher Taylor Monahan put it, this evolution of targeting OSS maintainers is concerning because maintainers are the trusted root of the entire open-source supply chain.

Red flags the maintainer could have caught:

• A video call that requires you to download a new app
• Being asked to run curl commands during a meeting
• A meeting where the other party's video "doesn't work"
• An urgent request to publish or push code

Lesson 4: Dependency Pinning Is Non-Negotiable

Any project with axios@^1.14.0 or axios@^0.30.0 in package.json would have automatically pulled the malicious version on npm install — because the ^ caret allows minor version upgrades.

// Vulnerable — caret allows auto-upgrade to 1.14.1
{
  "dependencies": {
    "axios": "^1.13.0"
  }
}

// Safer — pin to exact version
{
  "dependencies": {
    "axios": "1.13.0"
  }
}

Better yet, use a lockfile (package-lock.json or yarn.lock) and commit it to version control. Then use npm ci instead of npm install in CI/CD pipelines — it installs exactly what's in the lockfile.

---

What npm / GitHub Is Doing Now

In response to this incident, GitHub announced:

• Mandatory short-lived tokens for all packages with 1M+ weekly downloads, effective June 2026
• A "critical package" designation for the top 500 most-depended-upon packages, requiring two-person publish approval
• Accelerated rollout of additional identity verification for high-impact maintainers

These are good steps — but they come after the fact.

---

Hardening Your Supply Chain: A Practical Checklist

# 1. Use npm audit in CI/CD — fail the build on high severity
npm audit --audit-level=high

# 2. Use Socket.dev or Snyk to scan for suspicious postinstall hooks
npx socket scan .

# 3. Enable npm provenance attestations (verify package origin)
# Check: https://docs.npmjs.com/generating-provenance-statements

# 4. Use Dependabot or Renovate with pinned versions + PR review
# Never auto-merge dependency updates without review

# 5. Monitor your node_modules for unexpected binaries
find node_modules -name "*.exe" -o -name "wt.exe" 2>/dev/null

# 6. Block outbound connections from your build environment
# Your npm install should NOT be making requests to unknown domains

# 7. Use private npm mirrors or artifact caches (Verdaccio, Artifactory)
# Gives you time to vet packages before they reach developers

---

The Uncomfortable Truth

Every major JavaScript project in the world has axios in its dependency tree. For approximately three hours on a Sunday night, every new npm install in any project using axios@^1.14.0 was deploying North Korean malware.

The malicious packages were removed within three hours. That sounds reassuring. But:

• 3% of the axios userbase downloaded the malicious versions
• 135+ endpoints were confirmed compromised by Huntress alone
• Any system that ran the installer is still compromised even after the package was removed
• The full breadth of post-compromise activity is still unknown

As John Hultquist, Chief Analyst at Google GTIG, stated: "Given the popularity of the compromised package, we expect it will have far-reaching impacts."

Supply chain attacks are not a future threat. They are happening right now, to the packages you install every day. The axios attack is a wake-up call for every developer to treat their dependency tree as a security-critical attack surface.

---

Key Takeaways

1. Audit your axios version immediately — check for 1.14.1 or 0.30.4
2. Pin your dependencies — stop using ^ for critical packages
3. Rotate your npm tokens — long-lived tokens are ticking time bombs
4. Add npm audit to your CI/CD pipeline — make it a build gate
5. Educate your team on social engineering — the human is always the weakest link
6. Assume compromise if exposed — removal of the package is not remediation

---

References & Further Reading

• Google GTIG Official Attribution Report
• Microsoft Security Blog — Mitigating the Axios Compromise
• Huntress — Full Technical Analysis
• SecurityWeek — Attack Breakdown
• The Hacker News — UNC1069 Social Engineering Details
• Sophos CTU Analysis

---

If this post helped you, drop a ❤️ and share it with your team. Every developer in your organization should know about this. Follow me for more security deep-dives at the intersection of cybersecurity and software development.

---

Tags: #security #javascript #npm #nodejs #supplychain #cybersecurity #northkorea #devto #infosec #webdev