IronWorm, a Rust-based infostealer, has infected 36 packages on the npm registry and is designed to harvest a broad set of credentials and secrets, according to a technical analysis by JFrog and reporting aggregated by other security firms.
How IronWorm operates: theft, stealth, and self-publishing
JFrog researchers report IronWorm targets 86 environment variables and 20 credential files that may contain OpenAI, AWS, Anthropic, and npm credentials, vault configuration files, SSH keys, and Exodus cryptocurrency wallet files. The malware is written in Rust, hides behind an eBPF kernel rootkit, and uses the Tor network for operator communications.
Once installed in a developer or continuous-integration (CI) environment, IronWorm self-propagates by using stolen credentials to publish trojanized package versions onto npm. That includes secrets associated with npm's Trusted Publishing workflow. Packages can be published under the victim’s ownership so subsequent developers and CI systems that consume those packages will be exposed.
Delivery methods and an unusual artifact exfiltration technique
JFrog found the campaign started from a compromised npm account named “asteroiddao,” which published package versions containing a Rust ELF binary executed via the package lifecycle script 'preinstall.' Malicious commits were pushed into repositories with the commit author set as “claude,” and timestamps on those commits were altered to appear as if authored several years — in some cases up to 13 years — earlier, a tactic JFrog says is likely intended to hinder investigation.
JFrog also documented a separate mechanism the malware can use to deliver stolen secrets via GitHub Actions: the malware serializes secrets into a single value, writes that value to a file with a harmless-looking name (for example, mimicking lint or formatting output), and uploads it as a build artifact. Anyone with access to the artifact can then download the file, allowing exfiltration without an external command-and-control (C2) server. JFrog notes this artifact-delivery path exists in the malware, but that it was not used in the analyzed IronWorm supply-chain attack.
Technical hallmarks: Rust, eBPF rootkit, and Tor
JFrog’s description emphasizes three technical hallmarks: the implant is Rust-based, it uses an eBPF kernel rootkit to hide on compromised hosts, and it communicates over Tor. Those capabilities support both resilience and stealth — the eBPF component conceals the implant at the kernel level, while Tor hides operator infrastructure.
JFrog also reported a curious operational detail: the operator hardcoded the recovery phrase of their own cryptocurrency wallet into the malware. Researchers interpret that as deliberate, to ensure the malware would not exfiltrate the operator’s own wallet phrase during testing.
Parallel activity: binding.gyp and a separate JavaScript-based campaign
At the same time, Endor Labs and StepSecurity reported a similar but distinct supply-chain attack in the same time-frame involving a JavaScript-based malware named binding.gyp. That campaign performed registry poisoning and GitHub Actions infection, indicating multiple actors or concurrent efforts exploiting npm and CI tooling around the same period.
What this means for developers, CI teams, and security teams
- Developers: Ox Security says the IronWorm attack was detected very early and stopped before it spread to more popular npm packages. Ox provides a list of all impacted package names and versions and recommends developers upgrade to fixed releases, rotate their keys, and enable two-factor authentication (2FA) on all accounts.
- CI teams and repository maintainers: JFrog’s findings underscore that GitHub Actions artifacts can be abused to move secrets without an external C2; teams should audit artifact access policies and the use of lifecycle scripts like 'preinstall' that can execute binaries during package installation.
- Security operations and incident responders: IronWorm’s use of stolen npm Trusted Publishing secrets to self-publish trojanized packages, combined with eBPF stealth and Tor communications, suggests detection and response will need to correlate package publishing events, CI artifacts, and host-kernel indicators to identify a spread pattern.
JFrog noted a superficial overlap with a recently publicized implant called Shai Hulud — the teams observed identical commit names in both campaigns — but researchers did not find a definitive connection. The presence of shared commit names opens the possibility that IronWorm is an evolution of prior payloads, or that multiple operations are reusing tooling or conventions.
Early intervention appears to have limited damage: Ox Security reports the campaign was stopped before reaching more widely used npm packages, and Ox and JFrog have published technical details and remediation guidance. Still, the simultaneous sighting of a JavaScript-based campaign (binding.gyp) and the artifact-exfiltration technique JFrog documented highlight that supply-chain attacks continue to evolve along multiple vectors.
Security teams and maintainers now face a concrete question left by the record: will offsetting controls — rotating keys, enforcing 2FA, tightening artifact permissions and lifecycle-script policies — be enough to blunt actors who combine kernel-level stealth, Tor-hidden infrastructure, and credential-driven self-publishing? The immediate answer from vendors is practical: apply fixes, rotate secrets, and harden accounts — and watch for further analysis from JFrog, Ox Security, Endor Labs, and StepSecurity as investigations continue.
