For most of the npm worm era, the malicious payload lived in userland. It read your environment variables, swept your credential files, phoned a command-and-control server, and tried to publish itself onward. Annoying, dangerous, but observable. You could watch the process. You could read its network connections. Your EDR could see it.
IronWorm changes the assumption. Disclosed by JFrog Security Research on June 3, 2026, it is a Rust-built npm worm that shipped a kernel-level eBPF rootkit alongside the usual credential theft. The rootkit's entire job is to hide the malware from the same tools you would use to find it. When the thing you are hunting can edit the kernel's answers to your questions, the game is different. This post breaks down what IronWorm actually did, why eBPF is the natural next move for supply chain malware, and what detection looks like when you can no longer trust the process list.
What IronWorm Actually Shipped
IronWorm was distributed through malicious npm packages published from the asteroiddao account. JFrog identified roughly 40 malicious package versions, with weavedb-sdk@0.45.3 as the primary analyzed sample, alongside packages like roidjs@0.1.7, ai3@0.3.5, and aonote@0.11.1. The compromise touched nine GitHub organizations including ocrybit, asteroid-dao, weavedb, and ArweaveOasis. Malicious versions were deprecated within roughly a day of the attack starting, and several malicious commits were quietly removed from GitHub afterward.
The payload itself is a large Rust release build with an async runtime and thousands of functions, which makes reverse engineering meaningfully slower than the typical C implant. JFrog described it as a custom, carefully built implant rather than a kit assembled from off-the-shelf parts.
The credential theft is broad and very 2026. The implant sweeps 86 environment variables and more than 20 credential file paths covering AWS, GCP, Azure, Vault, Kubernetes, npm, Docker, and GitHub, plus the current generation of AI provider keys: Anthropic, OpenAI, Gemini, Cohere, Mistral, Groq, and Perplexity. It reads paths like ~/.claude/.credentials.json, ~/.aws/credentials, and ~/.kube/config directly. A separate module targets Exodus cryptocurrency wallets, injecting JavaScript to disable Electron security protections and capture the wallet password and seed phrase.
Exfiltration runs over Tor. The malware downloads the Tor expert bundle, writes its own torrc, starts the daemon, waits for a circuit, and then tunnels its HTTP command channel through it: upload stolen secrets, download files, or open a remote shell.
The Self-Propagation Trick Worth Noting
The worm part is the supply chain part. IronWorm self-propagates by abusing npm's Trusted Publishing flow. In a CI environment it requests an OIDC identity token, then submits that token to npm's OIDC token-exchange endpoint, which hands back a short-lived, package-scoped automation token. With that token it publishes itself into more packages.
This is the detail that should worry anyone who moved to Trusted Publishing thinking it closed the door on stolen long-lived npm tokens. It did close that door. But a worm running inside your CI job inherits the same trust your pipeline was granted, and short-lived OIDC tokens are still tokens. The malicious packages also carried backdated commit timestamps, some reportedly reaching years into the past, to make freshly injected code look like long-established, trusted history. Provenance you do not verify is just a story the attacker tells you.
Why eBPF Is the Logical Next Move
eBPF lets code run in the kernel safely and without a kernel module, which is exactly why defenders love it. Most modern Linux runtime security and observability tooling is built on eBPF. That popularity is precisely what makes it attractive to attackers: if your monitoring lives in the kernel's eBPF event pipeline, malware that also lives there can sit upstream of you.
IronWorm's rootkit was compiled as a BPF object and implements process hiding by rewriting /proc results in-kernel, removing the hidden PIDs before userland ever sees them. So ps, top, and a plain ls of /proc return a curated reality. It does the same to network state, filtering /proc/net/tcp and netlink interfaces so the Tor connections do not show up. It maintains a watchlist of process names and automatically adds matching execve calls to the hidden set, and it kills ptrace attempts with SIGKILL to frustrate debuggers.
This is the broader trend, and IronWorm is not alone in it. Security researchers have spent 2026 documenting how modern Linux rootkits target the eBPF event pipeline directly, intercepting and dropping records before they reach the ring buffer that security tools read from. The uncomfortable part: most eBPF-based security tools have no built-in way to notice that another BPF program is editing the event stream underneath them. They report the filtered data faithfully, and faithfully is the problem.
The One Big Weakness
Here is the honest counterweight, because the headline overstates the threat if you stop reading at "kernel rootkit." IronWorm's stealth degrades sharply on hardened systems. JFrog notes that with kernel lockdown in integrity mode, the memory-rewriting helpers the rootkit depends on fail silently. Modern distributions increasingly ship lockdown enabled by default and block bpf_probe_write_user in that mode, which is exactly the primitive this class of rootkit leans on.
So the rootkit is not magic. It is a userland infostealer with a kernel cloak that only works where the kernel lets it. On a locked-down host, the cloak slips and you are back to detecting a noisy credential thief. That does not make IronWorm harmless. It makes hardening the cheapest defense you are probably not fully using.
Detecting Kernel-Level Supply Chain Malware
Detection splits into two problems: catching the malware before it runs, and catching it after it has loaded a rootkit. Both matter, because no single layer is sufficient.
Stop it at install time. The cleanest win is never executing the payload. eBPF rootkits ship inside packages, and those packages enter through npm install and CI. Treat dependency installation as an untrusted, isolated operation: no ambient cloud credentials, no long-lived secrets in the environment, no broad network egress, and disabled or sandboxed lifecycle scripts. IronWorm reads 86 environment variables; an install step that runs with none of them worth stealing is an install step that fails the attacker quietly. This is also where verifying provenance and screening packages against known-malicious intelligence pays off, before the backdated timestamps get a chance to fool a human reviewer.
Audit the eBPF surface itself. On running hosts, the strongest signal is the eBPF program inventory. Unexpected BPF programs attached to tracepoints or LSM hooks are a high-quality indicator of compromise; legitimate workloads have a known, small set. Enumerate loaded programs out-of-band rather than trusting a tool that itself runs through the kernel pipeline. Cross-check process and network state from multiple independent vantage points: if /proc disagrees with what the scheduler or a memory-forensics view reports, something is rewriting answers.
Harden so the cloak fails. Enable kernel lockdown in integrity mode and confirm bpf_probe_write_user is blocked. Use BPF LSM to constrain who can load eBPF programs at all. These controls turn IronWorm's kernel stealth into a non-event and force the malware to operate in the open, where your existing detection works.
How Safeguard Helps
Safeguard treats dependency installation as the untrusted operation it is. Our policy gates and vendor policy registry screen packages against malicious-package intelligence before they reach a build, and provenance and attestation checks catch the backdated-commit and supply chain-injection tricks IronWorm relied on rather than taking the package's history at face value. Because reliability lives in the verification and orchestration layer above any single model, our Multi-Agent TAOR Deep Think AI Engine and Griffin AI corroborate suspicious findings across signals instead of trusting one process list, which is exactly the trust that a kernel rootkit is built to poison. If you want to pressure-test your npm and CI/CD supply chain against this class of attack, reach out.