Most npm malware is a few lines of obfuscated JavaScript stapled to a postinstall hook. You can read it, you can deobfuscate it, and your scanner can fingerprint it. IronWorm is none of those things. It is a roughly 976 KB compiled Rust binary that ships a kernel-level eBPF rootkit, talks to its operator over Tor, and republishes itself across npm using the same Trusted Publishing flow that the ecosystem rolled out to make publishing safer. It carries no CVE, and at the moment of compromise, CVE-based scanners had nothing to match against.
JFrog's research team flagged it on June 3, 2026, and called it "Shai-Hulud's rustier cousin." That framing is fair, and it is also the point: the technique is not new, but the engineering investment is a step-change. This is what the ceiling of supply-chain malware looks like in 2026, and it is worth understanding in detail because the defensive posture it demands is different from what most teams have built.
What Was Actually Compromised
The campaign rode in through a compromised npm account associated with asteroiddao, republishing trojanized versions of packages tied to the Arweave / WeaveDB decentralized-database ecosystem and the broader Web3 developer community. Reporting on the exact blast radius varies by source and by the moment it was measured — BleepingComputer counted 36 packages, Phoenix Security and several others cite 37, and SC Media reported 57 affected projects across 9 organizations. The nine organizations named in the disclosures include ocrybit, asteroid-dao, alisista, warashibe, weavedb, and ArweaveOasis, among others.
The spread in the numbers is itself a lesson. A self-propagating worm does not have a fixed footprint. The count you get depends on when you looked, because the thing was actively republishing itself the entire time researchers were trying to enumerate it.
The Binary: Built To Resist You
Here is where IronWorm departs from the genre. The install hook drops a Rust ELF binary of roughly 976 KB. Rust alone makes reverse engineering meaningfully harder than the usual minified JavaScript — there is no source to read, and the compiler's output is dense. The authors then layered on three more obstacles:
- A modified UPX packer. Standard UPX-packed binaries unpack with a single command. The IronWorm authors tampered with the stub specifically to break signature-based unpackers, so the off-the-shelf tooling an analyst would reach for first does not work.
- Per-call-site string encryption. Every internal string is encrypted with a unique key tied to the location where it is used. You cannot dump the binary's strings to learn its capabilities, and you cannot decrypt one string and pivot to the rest. Each one is its own small puzzle.
- An embedded eBPF rootkit. This is the part that should make defenders sit up.
None of these techniques is exotic on its own. Seeing all three in a package that arrived through npm install is what makes IronWorm notable. The cost of analysis is deliberately driven up, which buys the operator dwell time.
The eBPF Rootkit: Hiding In The Kernel
eBPF lets code run inside the Linux kernel's execution context. It is a legitimate, powerful technology used for observability, networking, and security tooling. IronWorm weaponizes it to hide.
When any tool on the host enumerates /proc — which is how ps, top, and friends learn what is running — the rootkit rewrites the results in place before userland ever sees them, stripping out the worm's own process IDs. The malicious processes simply do not appear. Your monitoring agent, your ps aux, your incident responder's first instinct all return clean output while the implant runs underneath.
This is the detail that breaks a lot of assumptions. Most supply-chain detection lives at the package or process layer. A rootkit that lies to the process layer means the artifacts your tooling depends on are no longer trustworthy on a compromised host. Detection has to move earlier — to what entered the build — or lower, to kernel-level telemetry the rootkit cannot rewrite.
Credential Theft And Tor C2
Once resident, the implant does what supply-chain infostealers do, but with unusual breadth. Reporting indicates it sweeps 86 environment variables and more than 20 credential file paths, covering AWS, GCP, Azure, HashiCorp Vault, Kubernetes, npm, Docker, and GitHub. Notably, it also targets the full 2026 generation of AI provider keys — Anthropic, OpenAI, Gemini, Cohere, Mistral, Groq, Perplexity, and xAI — which is a clear signal of where attackers now expect to find high-value, under-rotated secrets. There is also a dedicated Exodus desktop wallet hook that reportedly weakens Electron sandboxing to capture the seed mnemonic at unlock time, consistent with the campaign's Web3 targeting.
Command and control runs over Tor. The implant downloads the Tor expert bundle, writes its own torrc, and beacons to a hidden service. That means there is no clean IP or domain to block at the egress firewall, and the C2 endpoint does not resolve in DNS. Network-based indicators, the other thing defenders reach for, are largely off the table by design.
Self-Propagation Through Trusted Publishing
The most uncomfortable part of IronWorm is how it spreads, because it abuses a security feature. npm's Trusted Publishing uses short-lived OIDC tokens so that CI pipelines can publish without long-lived credentials sitting in a secret store — a genuine improvement over the API tokens that earlier worms like Shai-Hulud harvested.
IronWorm turns that flow against itself. On any CI runner with active OIDC federation, the worm exchanges the runner's identity token for a short-lived, package-scoped publish token and republishes itself under whatever maintainer namespace that runner can reach. No stored secret is stolen, because there is no stored secret — the runner's ephemeral identity is the credential. This is OAuth token theft adapted to a world that thought it had moved past stored tokens, and it is exactly the kind of CI/CD attack path that does not show up in a dependency audit.
A worm that propagates this way does not need to phish maintainers or guess passwords. It just needs to land on one CI runner that is allowed to publish, and the trust relationship does the rest.
What This Means For Your Defenses
A few honest takeaways. First, CVE-based scanning was structurally blind here — there is no CVE, and there was no signature at time of compromise. If your supply-chain program is mostly known-CVE matching, IronWorm is the class of threat it will miss. Second, install-time script execution remains the entry point; disabling install scripts by default and gating on provenance matters more than ever. Third, the OIDC propagation path means CI runner identity is now an attack surface — scope publish permissions tightly, and treat a runner that can publish to many namespaces as a critical asset.
If a host is already compromised, assume its process-level telemetry is lying to you. Trust what entered the build and what the kernel sees, not what ps reports.
How Safeguard Helps
Safeguard treats the build, not the CVE database, as the unit of trust. Our Multi-Agent TAOR Deep Think AI Engine reasons about packages behaviorally — flagging a compiled binary dropped by an install hook, anomalous postinstall activity, and provenance that does not match a package's history — rather than waiting for a CVE that, in IronWorm's case, never came. Our AIBOM/ML-BOM and provenance and attestation tracking surface exactly the AI-provider and cloud credentials IronWorm hunts for, and policy gates can block a publish or deploy when a package fails provenance or introduces an unexpected native binary. Because the platform is model-agnostic and the verification logic lives above any single model, multi-agent cross-checking keeps false positives low while catching the novel, unsignatured threats that single-pass scanners miss. If you want to see how your dependency tree and CI publish paths would hold up against a worm like IronWorm, reach out and we will walk through it with you.