Five days ago, I published a guide on auditing your dependencies after finding 47 vulnerabilities in a project I was managing. I thought that was a wake-up call. Then IronWorm happened — and it’s everything I warned about, turned up to eleven.
A new supply-chain attack has infected 36 packages on the Node Package Manager (npm) index with infostealer malware called IronWorm. But this isn’t your typical “compromised maintainer account” story. IronWorm is written in Rust, hides behind an eBPF kernel rootkit, communicates over Tor, and — here’s the part that should keep you up at night — self-propagates by publishing trojanized versions of packages using stolen credentials.

Researchers at JFrog, the devops and supply-chain security company, discovered the attack and published their findings this week. OX Security confirmed the attack was caught early, before it could spread to more popular packages. But the sophistication of IronWorm suggests this is just the opening move.
What IronWorm Actually Does
When a developer installs a compromised package, the malware executes via a preinstall script — a hook that runs before the package is even fully installed. That’s the entry point. From there, IronWorm does three things that make it particularly dangerous:
It Steals Everything
The malware targets 86 environment variables and 20 credential files. We’re not talking about just npm tokens. It goes after OpenAI API keys, AWS credentials, Anthropic keys, SSH keys, vault configuration files, and even Exodus cryptocurrency wallet files. If you’ve got secrets on your machine, IronWorm wants them.
It Hides Where You Can’t See It
IronWorm uses an eBPF kernel rootkit to conceal its presence. For the non-security folks: eBPF is a Linux kernel technology that lets programs run inside the kernel itself. Using it as a rootkit means the malware operates at a level below where most security tools can detect it. Traditional antivirus won’t catch this. Even many EDR solutions struggle with eBPF-based rootkits because they’re operating in the kernel’s blind spot.
It Spreads Itself
This is the part that separates IronWorm from previous npm attacks. The malware uses stolen npm publishing credentials — including secrets from npm’s Trusted Publishing workflow — to publish trojanized versions of packages the victim maintains. So if you’re a package maintainer and you get infected, IronWorm will silently push malicious versions of your packages to npm. Your downstream users get infected. Their packages get compromised. The cycle continues.
The Shai Hulud Connection
If the name Shai Hulud rings a bell, it should. That malware had its code published on GitHub recently, and it followed a similar self-propagation pattern through npm. JFrog’s researchers found the same commit names appearing in both IronWorm and Shai Hulud attacks, though they haven’t confirmed a direct link.
Their assessment: IronWorm appears to be “a custom, carefully built implant from an operation with its own infrastructure.” In other words, this isn’t a script kiddie reusing leaked code. Someone built this from scratch, and they built it to last.
The attack reportedly started from a compromised account called asteroiddao, which published package versions containing the Rust ELF binary. The commit author shows up as “claude” with timestamps backdated by up to 13 years — a deliberate move to make forensic investigation harder.
A Second Attack Unfolding in Parallel
As if IronWorm weren’t enough, security firms Endor Labs and StepSecurity spotted a separate but similar attack happening at the same time. This one uses a JavaScript-based malware called binding.gyp that performs registry poisoning and GitHub Actions infection.
Two distinct supply-chain attacks hitting npm simultaneously isn’t a coincidence. It suggests coordinated activity — whether by the same group testing different approaches, or multiple threat actors who see npm’s ecosystem as an easy target right now.
Why This Matters Beyond npm
I manage an ICT division where half our development workflow depends on npm packages. If you’re reading this and thinking “this only affects JavaScript developers,” you’re wrong. Supply-chain attacks like IronWorm affect every layer of the stack:
- CI/CD pipelines are prime targets because they have elevated credentials by design. A compromised package in your build pipeline can inject malware into every artifact you produce.
- Cloud credentials stored in environment variables are the holy grail for attackers. One leaked AWS key can cost thousands in compute charges before anyone notices.
- AI API keys are increasingly valuable. OpenAI and Anthropic credentials can be used to generate content, exfiltrate data, or run up massive bills. And with shadow AI usage surging in workplaces, the number of exposed API keys is growing faster than most security teams can track.
What You Should Do Right Now
OX Security provided a full list of impacted packages and their versions. If you’re using npm in any capacity, here’s your immediate checklist:
- Check if you’re affected. Review your
package-lock.jsonoryarn.lockfor the compromised package versions. OX Security’s report lists all 36 packages by name. - Rotate your keys. If there’s any chance you installed a compromised version, assume your environment variables are exposed. Rotate npm tokens, AWS keys, SSH keys, and any AI API keys on the machine.
- Enable 2FA everywhere. npm supports two-factor authentication for publishing. If you maintain packages and haven’t enabled it, do it today. It’s the single most effective defense against self-propagation attacks.
- Audit your dependencies. I covered this in detail in my software supply chain security guide. Tools like
npm audit, Snyk, and Socket.dev can catch known vulnerabilities before they reach production. - Lock your dependencies. Use
package-lock.jsonwith integrity hashes. If a package version gets silently replaced on npm, the hash mismatch will flag it during install.
The Bigger Picture
IronWorm is a preview of where supply-chain attacks are heading. The combination of Rust (harder to reverse-engineer), eBPF rootkits (invisible to most tools), Tor C2 (untraceable), and self-propagation (exponential spread) represents a significant step up in sophistication from the npm attacks we’ve seen before.
The fact that it targets AI credentials alongside traditional cloud and SSH keys shows that attackers are adapting to how developers work in 2026. We’re integrating AI into everything — coding assistants, deployment pipelines, monitoring tools. Every integration is a new credential to steal.
I’ve said it before and I’ll say it again: security isn’t something you bolt on after the fact. It has to be part of how you build from the start. Dependency auditing, locked versions, minimal credentials, and 2FA aren’t optional anymore. They’re survival skills.
The npm ecosystem has over 2 million packages. Most developers install them without a second thought. IronWorm is proof that every npm install is a trust decision — and trust, once broken, spreads faster than any malware.
Sources: BleepingComputer, JFrog Security Research, OX Security, Endor Labs & StepSecurity