Axios npm Attack: What Zero Trust Egress Stops

April 2026 · Tracenyx Security Team

On March 31, 2026, engineers across the world woke up to a serious supply chain attack. Two versions of Axios — the JavaScript HTTP client with over 100 million weekly downloads — were found to contain malware. The attacker was a North Korean state-sponsored group. The blast radius was potentially enormous.

This post explains what happened, what it means for teams running workloads in Kubernetes, and — honestly — what Nyx can and cannot do about it.

What Happened

The attacker compromised the npm account of the lead Axios maintainer and published two backdoored versions — axios@1.14.1 and axios@0.30.4 — within a 39-minute window. Both were tagged as latest, meaning any project running npm install axios without a pinned version automatically pulled the malicious package.

The attack chain was elegant and precise:

npm install axios@1.14.1
  → pulls plain-crypto-js@4.2.1 (malicious dependency)
    → postinstall hook executes setup.js silently
      → contacts C2 at sfrclak.com:8000
        → downloads platform-specific RAT
          → Windows / macOS / Linux all targeted

No Axios source code was modified. The malicious behaviour lived entirely in a transitive dependency triggered automatically by npm's postinstall lifecycle. Traditional code review would not have caught it.

Microsoft Threat Intelligence attributed the attack to Sapphire Sleet, a North Korean state actor. Google Threat Intelligence Group tracks the same actor as UNC1069.

The Kubernetes Angle

Most analysis of this attack focused on developer workstations and CI/CD pipelines — and rightly so, those are the primary targets. But if your Kubernetes cluster runs Node.js workloads that install npm packages as part of their build or startup process, the same attack surface exists inside your cluster.

Consider a common pattern:

Kubernetes pod:
  → Node.js application
  → npm install runs at container build time
  → Malicious axios version pulled
  → Container image now contains RAT
  → Pod starts — RAT executes
  → RAT tries to beacon to sfrclak.com:8000

At this point, the malware is running inside your cluster. The question is: what happens next?

What Nyx Blocks — And What It Doesn't

We want to be direct about this, because trust matters more than marketing.

What Nyx cannot stop

Nyx is a network policy engine. It operates at the network layer — Layer 3 and Layer 4. It does not inspect npm packages, analyse container images, or intercept process execution inside a pod (process-level visibility via eBPF syscall tracepoints is on our roadmap).

If a compromised Axios package is installed in your container image and the RAT executes, Nyx cannot prevent that execution. That is the job of image scanning tools (Trivy, Grype), supply chain security tools (Sigstore, SLSA), and endpoint detection tools.

What Nyx stops cold

This is where the story gets interesting.

The C2 beacon. The RAT's first action after executing is to contact sfrclak.com:8000 to receive commands and download second-stage payloads. Without a successful C2 connection, the RAT is inert.

With Nyx zero trust egress policy, every pod has an explicit list of approved outbound destinations. Anything not on that list is denied at the kernel level — eBPF on Linux, WFP on Windows.

# Example: payments service egress policy
apiVersion: nyx.tracenyx.io/v1alpha1
kind: NyxNetworkPolicy
metadata:
  name: payments-egress
  namespace: cloudmart-payments
spec:
  podSelector:
    matchLabels:
      app: payments
  policyTypes:
  - Egress
  egress:
  - decision: Allow
    toFqdn:
      matchName: api.stripe.com
    toPorts:
      port: 443
  - decision: Allow
    toFqdn:
      matchName: approved-storage.blob.core.windows.net
    toPorts:
      port: 443
  - decision: Deny
    toFqdn:
      matchPattern: "*"

sfrclak.com is not on the approved list. The C2 beacon is blocked at the kernel before it leaves the node. The RAT cannot receive commands. The second-stage payload never downloads.

As the StepSecurity team noted in their analysis: "If the C2 is unreachable, the chain silently fails — npm install still exits 0." The malware runs but accomplishes nothing.

Data exfiltration. Even if the RAT managed to establish persistence through some other channel, it needs to send data back. Filesystem enumeration results, running processes, harvested credentials — all need to leave your cluster. With Nyx egress policy, that data has nowhere to go.

Lateral movement. A compromised frontend pod should never be able to reach your payments namespace, your database namespace, or your secrets. Nyx zero trust policy enforces this at the network level. Even a fully compromised pod is contained to the blast radius of its own namespace.

The FQDN Egress Point Deserves More Attention

Traditional network firewalls work on IP addresses. Azure Blob Storage, AWS S3, and many other cloud services share IP ranges across thousands of customers. A firewall rule allowing *.blob.core.windows.net also allows an attacker's blob account on the same IP range.

Nyx enforces egress policy at the FQDN level by inspecting the TLS SNI header at the kernel. This means:

approved-storage.blob.core.windows.net  → ✅ Allowed
attacker-storage.blob.core.windows.net  → ❌ Blocked

Same IP address. Different enforcement result.

This is not something a traditional firewall can do. It is what kernel-level SNI inspection enables — and it directly addresses the data exfiltration path that a RAT would use.

What You Should Do Right Now

Regardless of Nyx, if you run Node.js workloads:

Check for the malicious versions — axios@1.14.1 and axios@0.30.4
Check for RAT artifacts — /tmp/ld.py (Linux), %PROGRAMDATA%\wt.exe (Windows), /Library/Caches/com.apple.act.mond (macOS)
Block the C2 domain — sfrclak.com and 142.11.206.73 at your perimeter
Downgrade Axios — to 1.14.0 or 0.30.3 (last clean versions)
Audit your CI/CD pipelines — for runs that installed the affected versions between March 31 00:21 UTC and 03:15 UTC
Rotate credentials — if any pipeline was exposed during that window

For your Kubernetes clusters specifically:

Review your egress policies — do your pods have default-allow egress? If so, any malware that executes can call home freely
Implement FQDN-level egress control — know exactly what external endpoints each service is allowed to reach
Check your Windows nodes — the RAT specifically targets Windows with a PowerShell backdoor — your Windows Kubernetes nodes are in scope

The Broader Point

Supply chain attacks are not going away. The Axios attack followed SolarWinds, XZ Utils, and dozens of others in a clear pattern — compromise a trusted dependency, achieve broad downstream reach, blend in with legitimate traffic.

The security community's response has rightly focused on supply chain hygiene: pin your dependencies, verify provenance, use SLSA attestation, scan your images.

But defence in depth matters. Even if malware gets in — and it will, eventually — zero trust network policy means it cannot call home, cannot move laterally, and cannot exfiltrate data. A RAT with no C2 connection is just dead code sitting in a container.

That is the layer Nyx provides. Not the only layer you need. But a critical one.

About Nyx

Nyx is an AI-powered Kubernetes network security and observability platform built by Tracenyx. It enforces zero trust network policy at the kernel level — eBPF on Linux, WFP on Windows — from a single unified control plane.

Try Nyx free →
Contact us →

IOCs referenced in this post:

Malicious packages: axios@1.14.1, axios@0.30.4, plain-crypto-js@4.2.1
C2 domain: sfrclak[.]com
C2 IP: 142.11.206[.]73
Attribution: Sapphire Sleet / UNC1069 (North Korea-nexus)
Sources: Microsoft Security Blog, Google Threat Intelligence Group, Elastic Security Labs, StepSecurity EOF

Command Palette