IronWorm: The npm Malware Stealing Your AI API Keys

A Rust-based infostealer called IronWorm has compromised 36 packages on the npm registry. It's specifically targeting developer credentials — OpenAI keys, Anthropic keys, AWS tokens, SSH keys, vault configs, and Exodus wallet files. If you've run npm install recently without pinning versions, it's worth checking what landed on your machine.

IronWorm is part of a broader supply chain campaign that's been escalating since early June. It's not an isolated incident.

What IronWorm Actually Does

According to researchers at JFrog, IronWorm is written in Rust and designed to stay invisible. It hides behind an eBPF kernel rootkit, which lets it intercept system calls at the kernel level — below most endpoint security tools. Communication with the attacker's C2 server routes over Tor.

The malware targets 86 environment variables and 20 credential files specifically. The hit list includes:

• OpenAI API keys
• Anthropic API keys
• AWS credentials
• npm auth tokens
• Vault configuration files
• SSH private keys
• Exodus cryptocurrency wallet files

If you keep your API keys in .env files or your shell profile — which most developers do — IronWorm knows exactly where to look.

How It's Connected to Miasma

IronWorm didn't arrive in a vacuum. It's the latest variant in a wave that started June 1, when a compromised Red Hat employee GitHub account was used to push malicious code into 32 packages under the @redhat-cloud-services npm namespace. That payload was the Miasma worm.

By June 3, Miasma had spread to 57 more packages in a campaign that lasted under two hours. The largest victim was @vapi-ai/server-sdk — the official Vapi.ai voice AI SDK with 408,000+ monthly downloads. Also hit: ai-sdk-ollama, wrangler-deploy, and dozens of packages from the autotel family.

The Miasma variant in that second wave used a technique researchers at StepSecurity called "Phantom Gyp" — abusing a 157-byte binding.gyp file to trigger code execution during npm install without touching preinstall or postinstall lifecycle scripts. That's the specific hook most security tools watch. Phantom Gyp bypasses them entirely.

The attacker's GitHub account hosted 236 repositories used as credential dead-drops. Stolen credentials were uploaded as encrypted JSON files. And yes, the attackers left a message: 195 repo descriptions contained the string "Shai-Hulud: Here We Go Again" — a taunt referencing earlier research coverage of the Red Hat attack. These are not amateurs.

If you've been following the Miasma worm's earlier rampage through developer IDEs, this is the same malware family getting more aggressive.

On June 11: AUR Gets Hit Too

The campaign expanded again on June 11, this time hitting the Arch User Repository. Attackers hijacked more than 400 community AUR packages and turned them into a malware delivery network running the same worm variants. If you're an Arch user pulling from AUR — and nearly every Arch dev does — your machine may have already been compromised.

This is now a multi-ecosystem attack. npm. PyPI. AUR. The same worm family, spreading across the open-source dependency graph.

What to Check Right Now

Audit your npm installs. Run npm audit and check your node_modules for any of the affected packages. The full package list is in JFrog's advisory and the StepSecurity disclosure.

Rotate your credentials. If you installed any affected packages — even in a test environment — rotate everything: OpenAI keys, Anthropic keys, AWS tokens, npm tokens, SSH keys. All of it. Don't wait.

Check for suspicious GitHub activity. IronWorm exfiltrates credentials to attacker-controlled GitHub repos. If any of your credentials were stolen, you may be able to find evidence in GitHub audit logs.

Pin your dependencies. Use exact versions in package.json and lock files. Consider tools like Socket.dev or StepSecurity's OSS Package Security for supply chain monitoring in CI.

Audit your .env files. If you store API keys in .env or shell profiles on a machine that ran a compromised install, assume those keys are burned.

Why This Keeps Happening

npm's trust model is the problem. Package maintainer accounts get compromised, and malicious versions get published before anyone notices. The registry has no mandatory 2FA for publishing (it's opt-in), and install-time script execution is still allowed by default.

The Shai-Hulud/Miasma campaign has now run for months across multiple waves — March, April, May, June — each wave more sophisticated than the last. The attacker clearly knows the ecosystem well and is iterating on evasion techniques with each new release.

The Red Hat breach via GitHub Actions OIDC is a good reminder that it's not just individual maintainers at risk. Compromised CI/CD pipelines can push malicious packages at scale without ever touching an npm token directly.

This isn't going to slow down. Lock your deps, rotate your keys, and treat npm install on unverified packages with the same caution you'd give running a random binary.

Sources: BleepingComputer, StepSecurity, Wiz Research, Red Hat Security Advisory RHSB-2026-006, Unit 42 / Palo Alto Networks