A Supply-Chain Attack Built to Stay Quiet

Most malware gets caught because it makes noise — outbound connections, anomalous process behavior, obvious payload names. IronWorm was designed around the opposite philosophy. The Rust-based infostealer that recently infected 36 packages on the npm registry used an eBPF kernel rootkit to conceal itself, routed operator communication over the Tor network, and in at least one documented mechanism, avoided external command-and-control entirely by abusing GitHub Actions build artifacts. The result was an attack that moved through developer environments with very little to flag.

JFrog, the supply-chain and DevOps security company that analyzed the malware, describes IronWorm as “a custom, carefully built implant from an operation with its own infrastructure.” That framing matters. This is not a script-kiddie repackaging of a known tool. The level of operational planning — from the Rust implementation to the rootkit to the Tor relay — points to a threat actor investing real resources into staying undetected inside developer pipelines.

The attack was ultimately stopped before it reached the more widely downloaded packages on npm, according to application security company Ox Security, which detected it early.

What IronWorm Actually Steals

The target list is specific and deliberate. IronWorm goes after 86 environment variables and 20 credential files, covering a range of high-value secrets: OpenAI API keys, AWS credentials, Anthropic tokens, npm authentication data, SSH private keys, vault configuration files, and Exodus cryptocurrency wallet files. That combination — cloud infrastructure access, AI platform credentials, and crypto wallet data — reflects what’s actually valuable in modern developer environments, where a single compromised CI system can expose production services, model access, and financial accounts simultaneously.

Self-propagation is where IronWorm becomes particularly dangerous. Once it has stolen npm credentials, it uses them to publish malicious versions of packages the victim owns. This includes secrets associated with npm’s Trusted Publishing workflow, a mechanism intended to make publishing more secure by tying package releases to verified CI environments. IronWorm co-opts that trust relationship to push trojanized versions to the registry, which then execute on any developer or CI system that installs those packages. The infection doesn’t need to be planted manually again — it rides the existing distribution infrastructure.

This propagation model is functionally similar to Shai Hulud, another supply-chain tool whose code appeared on GitHub recently. JFrog found no direct link between the two, but the same commit naming conventions appeared in both attacks. That overlap raises the possibility that IronWorm is an evolution of code previously associated with a group tracked as TeamPCP, though that connection remains unconfirmed.

How the Attack Was Staged

The initial entry point was a compromised npm account named ‘asteroiddao.’ From there, malicious package versions were published containing a Rust ELF binary, triggered via the preinstall lifecycle hook — a standard npm mechanism that runs code before a package is installed. That hook gives attackers a reliable execution window that many developers don’t scrutinize closely.

Commit timestamps were deliberately falsified to obstruct forensic timelines. The commit author shown is “claude,” and the associated timestamps suggest commits made years ago — in some cases up to 13 years in the past — even though they were actually pushed within the last few days. Git’s architecture allows timestamps to be set arbitrarily, and this technique exploits that to make the malicious commits harder to sequence accurately when investigators try to reconstruct what happened and when.

One of the more technically inventive elements JFrog documented involves a GitHub Actions-based exfiltration path. Rather than sending stolen secrets to a traditional C2 server, the malware serializes credentials into a single value and writes them to a file with an innocuous name — formatted to look like lint output or a build formatter result. That file is then uploaded as a build artifact, downloadable by anyone with access to the repository. The threat actor retrieves the secrets without ever initiating a suspicious outbound connection. JFrog notes this specific mechanism was not observed in active use during the analyzed attack, but its presence in the code shows the operator had thought through multiple exfiltration paths.

The Wallet Recovery Phrase Left Inside

Perhaps the strangest detail in JFrog’s analysis is this: the threat actor hardcoded their own cryptocurrency wallet recovery phrase inside the malware. The only plausible explanation, and the one JFrog offers, is that the operator wanted to ensure IronWorm would not steal the wallet during internal testing. A recovery phrase embedded in the binary itself would be recognized as belonging to the operator and excluded from exfiltration during test runs.

It’s an operational security lapse that also reveals something about how the malware was developed — there was a testing phase, the operator ran it against their own environment, and they needed a workaround to protect their own assets while doing so. The phrase, once identified, could potentially be used to track or attribute the wallet activity, though JFrog did not publish the phrase itself.

A Second Attack Running in Parallel

While IronWorm was spreading through npm, Endor Labs and StepSecurity identified a separate but closely timed attack using entirely different tooling. This campaign involved JavaScript-based malware named binding.gyp and focused on registry poisoning alongside GitHub Actions infection. The two attacks — IronWorm and the binding.gyp campaign — are described as distinct, not coordinated, but their overlapping timeframes suggest either coincidence or opportunistic timing by different actors who identified the same vulnerabilities in npm’s ecosystem simultaneously.

The binding.gyp attack hasn’t received the same level of detailed technical analysis as IronWorm publicly, but its presence in the same window underscores a broader pattern: npm remains an attractive target precisely because of the trust developers extend to packages and the automation that consumes them without inspection.

What Developers Should Do Now

Ox Security published a full list of the 36 affected packages and their compromised versions. Developers using any of those packages should upgrade to the fixed releases immediately. Beyond that, rotating API keys and authentication tokens is necessary for anyone who ran affected versions in CI or local environments — environment variables pulled during installation would have been accessible to the malware’s collection routine.

Enabling two-factor authentication across all npm accounts is the third recommendation, and the most forward-looking one. IronWorm’s propagation through Trusted Publishing credentials shows that automation-friendly authentication mechanisms can be turned against the ecosystem that relies on them. 2FA doesn’t solve that entirely, but it raises the cost of initial account compromise.

The 36 packages IronWorm infected were not among npm’s most popular, which limited the blast radius. Had the attack reached higher-download packages before detection, the number of exposed developer and CI environments would have been substantially larger. The difference between an incident and a widespread breach here came down to how early Ox Security caught the initial activity — and how quickly the community responded once the campaign was flagged.

The hardcoded wallet recovery phrase is still sitting inside the analyzed binary.