The npm package registry is under attack again — and this time the malware is built to spread itself. Security researchers at JFrog have uncovered a campaign they’ve named IronWorm, a Rust-based information stealer that doesn’t just steal credentials. It uses them to keep moving, infecting new machines by publishing trojanized packages to npm under stolen maintainer accounts.
How IronWorm Works
The attack starts with poisoned versions of more than 50 legitimate npm packages. These aren’t lookalikes or typosquats — they’re actual published versions of real packages, injected with a malicious Rust ELF binary that executes through a preinstall hook. That means the moment a developer runs npm install, the payload fires.
Once active on a machine, IronWorm goes after everything. It scrapes 86 different environment variables, hunts down credential files associated with OpenAI Codex, Anthropic Claude, Google Gemini, and other AI development tools. It also deploys an eBPF kernel rootkit to hide its presence from monitoring tools — a technique that’s become increasingly common in sophisticated malware but is still relatively rare in supply chain attacks. The stolen data gets exfiltrated over Tor, making attribution and tracking significantly harder.
The Self-Replicating Problem
What makes IronWorm particularly dangerous is its propagation mechanism. After harvesting credentials from an infected developer’s machine, it uses those credentials to publish new trojanized packages to npm. The compromised account identified so far belongs to “asteroiddao,” but there’s no reason to believe it’s the only one. This creates a chain reaction: one infected machine leads to poisoned packages, which infect more machines, which steal more credentials, which poison more packages.
It’s a pattern that echoes the Shai-Hulud worm from 2023, which also self-replicated through npm. But IronWorm is more technically capable — the Rust binary, the eBPF rootkit, and the breadth of credential targeting all represent a step up in sophistication.
Who’s at Risk
Any developer or CI/CD pipeline pulling packages from npm is potentially in the blast radius. The 50+ compromised packages span multiple ecosystems and use cases, and because the malicious versions are published under legitimate package names, standard dependency auditing tools may not flag them immediately. Organizations that pin exact versions are somewhat protected, but anyone using caret or tilde version ranges could pull in the trojanized releases without realizing it.
What You Should Do
First, audit your recent npm installs against the known compromised package list (JFrog published indicators of compromise in their report). If you develop software that gets published to npm, rotate your tokens and enable hardware-backed 2FA on your npm account — SMS-based 2FA won’t cut it. Check your environment variables and credential files for signs of exfiltration. And if you’re running CI/CD pipelines, make sure they’re not automatically installing dependencies from unpinned versions in production environments.
What’s Next
Supply chain attacks on package registries aren’t going away — they’re too effective. The npm ecosystem’s openness is both its greatest strength and its biggest liability. Expect to see more campaigns that combine credential theft with self-replication, and watch for similar tactics targeting PyPI, RubyGems, and other registries. The security community is pushing for better signing and provenance verification (Sigstore, SLSA frameworks), but adoption is still patchy. Until it’s universal, assume your dependency tree is a threat surface.
