IronWorm Commits as “claude.” It Steals Your Anthropic and OpenAI Keys.

37 npm packages. A Rust binary with an eBPF kernel rootkit. Tor-based command and control. Self-propagation through npm’s Trusted Publishing. And the commit author on every malicious push: [email protected].

On June 4, 2026, JFrog Security Research published their analysis of IronWorm—a supply chain attack that compromised 37 npm packages through the asteroiddao account. The malware is a 976KB Rust ELF binary triggered by a preinstall hook. It was caught early, before spreading to high-download packages. But the techniques it introduced are a step change.

Three things make IronWorm different from what came before.


1. It commits as “claude”

Every malicious commit pushed to victim repositories uses the author identity [email protected]—a plausible-looking GitHub noreply address. The commit messages are routine: “fix: resolve lint warnings,” “test: add missing edge case,” “ci: update workflow configuration.”

The timestamps are forged. Some are backdated 13 years. In a repo where AI-generated commits are common and legitimate, these blend in. A developer scanning git log wouldn’t notice. A code reviewer seeing a commit from “claude” might assume it came from an AI coding assistant doing its job.

This is social engineering adapted to the AI era. The attacker isn’t pretending to be a human—they’re pretending to be an AI tool that the team already trusts.


2. It steals AI credentials specifically

IronWorm targets 86 environment variables and more than 20 credential files. The list includes the standard targets—AWS keys, SSH keys, Docker configs—but it also goes after a new category:

  • OpenAI API keys (OPENAI_API_KEY)
  • Anthropic API keys (ANTHROPIC_API_KEY)
  • Claude authentication files (Claude Code session tokens)
  • Cursor authentication files
  • npm publish tokens (including Trusted Publishing OIDC tokens)

Stolen AI credentials have immediate value. An OpenAI API key with no spend cap can run thousands of dollars in compute before anyone notices. An Anthropic key can be used to run agents that escalate the attack. And an npm publish token turns one compromised developer into a vector for compromising every package they maintain.

The dedicated Exodus wallet module goes further—injecting JavaScript to capture the wallet password and seed mnemonic at login. This isn’t a generic credential scraper. It’s targeted theft with custom modules per high-value target.


3. It propagates through Trusted Publishing

This is the part that should concern infrastructure teams.

npm’s Trusted Publishing lets packages publish via GitHub Actions OIDC tokens instead of stored npm credentials. It’s designed to be more secure: no long-lived tokens to steal. But IronWorm doesn’t need stored credentials. It modifies GitHub Actions workflows to request OIDC tokens at runtime, then publishes trojanized versions of the victim’s packages with valid provenance attestations.

The result: malicious packages that pass npm audit signatures. Provenance says “this was published through a verified CI pipeline.” It doesn’t say “the CI pipeline was hijacked.”

This is the same fundamental gap Miasma exploited with Red Hat’s SLSA provenance a week earlier. Two independent attacks, one week apart, both defeating provenance—through different mechanisms. The signal is clear: provenance is a chain-of-custody stamp, not a trust signal.


What the behavioral scores show

I ran every IronWorm package through Commit’s behavioral audit. The pattern is the same one we’ve seen in every supply chain attack this year:

Package Score Publishers Downloads/wk Age
weavedb-sdk low 1 <500 ~2 yr
ai3 low 1 <100 <1 yr
atomic-notes low 1 <100 <1 yr
cwao low 1 <100 <1 yr
zkjson low 1 <100 <1 yr

Single publisher. Low downloads. Limited history. Every IronWorm package fits the profile that behavioral scoring catches before the first install completes.

This isn’t hindsight bias. The pattern is structural: supply chain attacks require accounts with publish access, and most use either fresh accounts or hijacked accounts with narrow publishing history. Both produce the same behavioral signature—a package with no depth of commitment from its publisher ecosystem.


The escalation timeline

Put IronWorm in context with what’s happened in the last 90 days:

Date Attack What was new
Mar 5 LiteLLM Single-package PyPI credential theft
Mar 30 axios 99M downloads/week, stolen token
May 11 Shai-Hulud Self-propagating worm, 637 packages in 39 minutes
May 22 TrapDoor Cross-ecosystem + AI assistant poisoning
Jun 1 Miasma Forged SLSA provenance on Red Hat packages
Jun 4 IronWorm Rust + eBPF rootkit + AI credential theft + Trusted Publishing propagation

Each attack introduces a capability the previous one didn’t have. IronWorm is the first npm supply chain malware written in Rust, the first to use an eBPF kernel rootkit for process hiding, and the first to self-propagate through Trusted Publishing’s OIDC flow.

Also notable: it specifically targets the credentials of AI coding assistants. The attack vector has come full circle—AI tools accelerate development, but their credentials are now high-value targets, and the tools themselves are being impersonated in commit history.


What to do

Gate your AI assistant’s installs. One command adds a behavioral check to Cursor and Claude Code:

npx proof-of-commitment hook

Every npm install, pip install, cargo add, and go get runs through a behavioral check before execution. Packages with no history get blocked.

Audit your current dependencies:

npx proof-of-commitment --file package-lock.json

Rotate AI credentials. If any of the 37 IronWorm packages were installed in your environment at any point, rotate your OpenAI, Anthropic, and npm tokens immediately. Check for modified GitHub Actions workflows (.github/workflows/) that may have been altered to exfiltrate OIDC tokens.

Don’t trust provenance alone. Both Miasma and IronWorm demonstrate that valid provenance attestations can come from compromised pipelines. Provenance answers “where did this come from?” Behavioral scoring answers “should I trust it?” You need both.