Session CRT-20260604 — 4 June 2026 · Afternoon Edition

Look, this is actually impressive work from the JFrog and SlowMist teams — they caught a genuinely sophisticated campaign here. Let me break down the technical guts of IronWorm and address your questions:

(1) The eBPF Rootkit — This Is the Real Deal

The eBPF component isn't some half-baked toy. It hooks execve() syscalls specifically — this is surgical, not spray-and-pray. When you execute a wallet binary (MetaMask, Phantom, whatever), the rootkit intercepts that execve() call and injects its own code before the wallet UI even loads.

This gives them:

• Credential capture at unlock time — the rootkit grabs the password and mnemonic phrase as the user types them into what they think is a normal wallet unlock dialog
• Kernel-level persistence — lives below userland process space, survives reboots, doesn't show up in standard process listings
• EDR evasion — eBPF programs run in kernel space but outside the syscall table modifications that most EDR looks for. It's not hooking via LD_PRELOAD or patching kernel structs the old way. Modern EDRs monitoring for rootkits typically look for syscall table modifications or kernel module loading — eBPF is "legitimate" infrastructure.

The rootkit is delivered as a modified UPX-packed binary with per-call-site string encryption — each string gets its own XOR key at compile time. This isn't someone copy-pasting rootkit code; this is purpose-built distribution methodology.

(2) Tor C2 — Different From the Usual Trash

Most npm supply chain malware either (a) exfiltrates direct to a hardcoded IP over HTTPS, or (b) uses DNS tunneling if they want to be "sophisticated." IronWorm does neither.

It uses Tor hidden services for C2 — this is actually operationally significant. Compare:

• Direct HTTPS: One takedown, campaign gone
• DNS tunneling: Still centralized infrastructure you can sinkhole
• Tor hidden service: Infrastructure lives in the Tor network itself — no single host to seize, no DNS records to block

What makes this stand out: the malware locally proxies to Tor — it doesn't require a system Tor install. It's pulling the full Tor client into the payload. This adds bulk but removes a dependency that defenders could monitor.

(3) Detection for Automated-Identity Commit Tampering

The "claude," "dependabot," "renovate," "github-actions" impersonation is clever social engineering. Detection guidance:

Short-term (immediate):

• Audit your GitHub org's recent commits from these identities — look for accounts that look like bots but aren't part of your org's authorized apps
• Check the email domains — real GitHub Actions commits come from noreply@github.com, real Dependabot from dependabot[bot]@users.noreply.github.com

Medium-term:

• Commit signing enforcement — require GPG/SSH signing for all commits; bot identities can't spoof signed commits without stealing keys
• Branch protection + required status checks — commits from unrecognized "bots" should trigger review requirements
• Monitor for identity collision — a commit claiming to be from dependabot but pushed by an OAuth app you've never authorized

The kill chain here is: compromised developer token → malicious commits under bot identity → package update triggers → victim install.

(4) Comparison to Miasma/Shai-Hulud and TrapDoor

I need to be specific here because the comparisons matter operationally.

The leap here is the kernel rootkit. Shai-Hulud and Miasma are userland threats — good ones, but userland. IronWorm crosses into kernel space, which changes the containment math entirely. You can't just "rebuild the container" when the host kernel is compromised.

Shai-Hulud was fast (600 packages in an hour) and broad. IronWorm is slower, more targeted at Web3 developers specifically, but deeper persistence. Think of Shai-Hulud as a smash-and-grab mob — IronWorm is the crew that gets inside, installs hidden cameras, and stays for months.

That said — and this is important — I still don't see evidence this is nation-state tooling. The Rust + eBPF + Tor stack is competent, but it's all documented open-source techniques. Any motivated criminal group with kernel development skills could build this.

I'll check with James Okafor on defensive response specifics since eBPF rootkits require different containment than typical supply chain incidents.

James, I'm seeing kernel-level eBPF rootkits in an npm supply chain campaign targeting Web3 devs. What's your take on containment when the host kernel is potentially compromised? Standard "wipe and rebuild the container" won't cut it here.

Campaign Timeline:

IronWorm — disclosed June 4. The JFrog research shows 30+ malicious npm packages with a Rust payload, eBPF rootkit, Tor C2 communications, and Web3/crypto wallet targeting. This appears to be a campaign that achieved visibility rapidly, not a drawn-out operation.

Miasma/Shai-Hulud — first detection on May 29, 2026 according to the data I have. That's approximately a 6-day gap between two independent supply chain worm campaigns hitting npm.

Attribution Assessment:

For IronWorm — I find no direct attribution data linking to Lazarus or any specific cluster. The Web3/crypto targeting and wallet mnemonic theft fit the DPRK playbook (Contagious Interview, TraderTraitor families), but that's TTP alignment, not attribution. Here's my ICD 203 read: low confidence for Lazarus nexus. It's possible — DPRK groups have specifically targeted cryptocurrency wallet credentials through developer pipelines — but the Rust implementation and eBPF rootkit are distinct from what I've mapped in Lazarus campaigns. No code overlap indicators, no shared C2 infrastructure, no cert transparency pivot. I'll call this an unnamed cluster pending more data.

For Miasma/Shai-Hulud — the Wiz assessment points toward Iran-nexus, though I cannot confirm the specific MITRE G-code without additional verification. I'll stay at moderate confidence for Iran-nexus based on tradecraft alignment, but the open-sourcing of Shai-Hulud tools lowers attribution confidence.

Coordination or Coincidence?

Coincidental. Different actors (assessed Iran-nexus for Miasma vs. IronWorm unnamed cluster), timeline gap, different payloads (JavaScript vs. Rust), different persistence mechanisms. No shared IOCs in my data. The timing likely reflects broader shift toward supply chain worms — developers are lucrative targets with high-value secrets.

IronWorm Operational Model — What's Distinct:

Three shifts worth noting:

1. Rust-based payload — first npm worm I've tracked with a Rust binary. This evades signature-based detection and complicates analysis.
2. eBPF rootkit — kernel-level persistence through Extended Berkeley Packet Filter. This is above what we see in typical package-install infostealers like Shai-Hulud.
3. Tor C2 over WebSocket — not the usual HTTPS exfil. Harder to intercept, easier to pivot.

Prior npm campaigns — Shai-Hulud, Sonatype's OSS supply chain work — focused on credential harvesting and recursive propagation but stayed in userland. IronWorm is kernel-deep.

On Miasma/Shai-Hulud — Persistence Mechanisms:

From the reporting, Miasma targets CI/CD environments. The article describes credential harvesting, delayed execution via JavaScript timeouts to evade sandboxes, and use of API endpoints for communication. The persistence mechanisms through systemd services on Linux and LaunchAgent on macOS align with prior Shai-Hulud documented behavior. I do not have verified information about Claude Code hooks specifically attributed to Miasma.

Bottom line: IronWorm has no clear attribution signal. The Web3 targeting is thematic but not diagnostic. Keep open to opportunistic actors or copycats.

Right, let me address both items with specific, actionable guidance.

1. Acer Wave 7 — Immediate Actions

CRITICAL (do today):

• Network segmentation NOW. The advisory confirms broken access control on acer_cgi.log and a hardcoded cryptographic key in upload.cgi. Isolate these routers behind a jump host or management VLAN. No direct internet exposure.
• Disable remote administration — at minimum block WAN-side access to the admin interface at your edge firewall.
• Credential rotation — Rotate all passwords stored or transmitted through these routers. Assume exposure risk given the broken access control finding.

HIGH (do this week):

• Log monitoring — Monitor for access to /acer_cgi.log or unusual download.cgi/upload.cgi activity.
• Access control lists — Restrict router management to specific source IPs only.

Replacement consideration: Per Acer's advisory, patches are planned for end-of-June 2026. For production boundaries or sensitive management planes, temporary replacement may be warranted — I've seen low-cost routers cause disproportionate incident response costs when compromised.

2. Jupyter Enterprise Gateway CVE-2026-44182 — Detection & Mitigation

CRITICAL (do today):

• Upgrade to 3.3.0+ immediately. The GitHub advisory confirms this fixes the Jinja2 template injection (SSTI vulnerability in KERNEL_XXX environment variables).

If you cannot patch immediately:

1. OPA/Gatekeeper policy — Deploy constraints to block privileged pods in Jupyter namespaces:

apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPSecurityContext
metadata:
  name: jupyter-non-privileged
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
    namespaces: ["notebooks", "jupyter*", "enterprise-gateway"]
  parameters:
    runAsUser:
      rule: MustRunAsNonRoot
    privileged: false
    allowPrivilegeEscalation: false
    readOnlyRootFilesystem: true

1. Admission control — Consider validating KERNEL_* environment variables to reject template syntax ({{, }}) before pod creation.

2. Detection focus — Monitor for:

   • Pods created with securityContext.runAsUser: 0 or privileged: true in Jupyter namespaces
   • Multiple rapid pod creation events from a single kernel request
   • Environment variables containing Jinja2 template markers in KERNEL_* variables

HIGH (do this week):

• RBAC hardening — The Enterprise Gateway pod's service account is high-value. Scope to least-privilege. The advisory confirms successful exploitation yields the pod's Kubernetes token.

Priority Matrix Summary:

(1) Exploit Mechanism: How Jinja2 Becomes K8s Cluster Compromise

The core issue is in how Jupyter Enterprise Gateway renders Kubernetes pod manifests. When a user requests a kernel, JEG uses Jinja2 templates to generate the actual Kubernetes YAML that will become the pod spec. Environment variables starting with KERNEL_ (like KERNEL_WORKING_DIR, KERNEL_POD_NAME, etc.) get interpolated into the template without YAML-aware escaping.

Here's the attack surface: An authenticated user sends a kernel launch request with a crafted environment variable payload. For example, injecting newlines and YAML structural elements into KERNEL_WORKING_DIR causes the Jinja2 template to render a manifest containing injected Kubernetes spec fields — privileged containers, host network access, host PID namespace, or hostPath volume mounts.

The rendered manifest is syntactically valid YAML with attacker-controlled pod configuration. The K8s API server accepts this as legitimate. According to Endor Labs analysis, multiple container escape vectors exist: privileged pods for kernel module loading, hostPath R/W mounts to write crontab entries to the worker node filesystem, and repeated exploitation compromising all worker nodes.

(2) Affected Versions and Patch Status

The GitHub advisory identifies this as affecting Jupyter Enterprise Gateway with Kubernetes manifest injection via unsafe Jinja2 template rendering. The patched version is 3.3.0 — organizations should verify current version against this fix boundary directly from official Jupyter project sources.

The CVE carries a CVSS 10.0 score and is categorized as "Special Elements Injection" in the Jupyter Enterprise Gateway codebase.

(3) Blast Radius for ML/AI Pipelines

This is particularly dangerous for ML/AI infrastructure. Jupyter Enterprise Gateway is specifically designed for multi-user notebook environments in Kubernetes — the exact architecture used by enterprise ML platforms.

The blast radius is severe because:

• JEG is often deployed with elevated privileges to spawn kernels across namespaces
• ML pipelines frequently run on shared K8s clusters where data scientists have authenticated access but should be sandboxed
• The compromise doesn't require container escape knowledge — it's manifest injection at the orchestration layer
• A single compromised user session becomes cluster-equivalent through privileged pod creation

If you're running MLflow, Kubeflow, or custom notebook platforms on K8s with JEG, this requires immediate attention.

(4) Admission Controller Mitigation: Too Late in the Chain

Admission controllers like OPA or Kyverno cannot reliably stop this attack. The injection happens inside the Enterprise Gateway service during Jinja2 template rendering. The malformed YAML is generated server-side and then submitted to the K8s API server as a syntactically valid pod spec.

By the time the API server receives the manifest, it contains schema-compliant fields like securityContext: {runAsUser: 0} and hostPID: true. Kyverno or OPA would need extremely restrictive policies blocking all privileged pods and hostPath mounts — which often breaks legitimate ML workloads needing GPU access or specific security contexts.

The GitHub advisory confirms the server "interpolates untrusted environment variables into Kubernetes manifests without YAML-aware escaping." The KERNEL_WORKING_DIR vector is ignored unless EG_MIRROR_WORKING_DIRS is truthy — but other KERNEL_XXX variables remain injection vectors regardless.

Bottom line: Upgrade to version 3.3.0 or later. If immediate patching isn't possible, consider disabling EG_MIRROR_WORKING_DIRS and auditing which KERNEL_XXX variables are accepted, though this is incomplete defense-in-depth. Admission controllers are the wrong control point — the injection occurs before they see the request. This is an architectural trust boundary failure requiring fixes at the template rendering layer, not just policy enforcement.