IronWorm npm Worm Spreads via WeaveDB Crypto Packages

A Rust-based npm worm called IronWorm is still moving through the JavaScript ecosystem, and on 2026-07-14 our catalog flagged fresh malicious releases in the WeaveDB package family, including weavedb-contracts and weavedb-client. IronWorm is a self-replicating supply chain attack that steals developer, cloud and cryptocurrency wallet secrets, and it aims squarely at crypto and Web3 teams. Security researchers at JFrog first documented the campaign in early June 2026 after the malware surfaced in packages tied to Arweave's WeaveDB decentralized database project. More than a month later it keeps appearing in new packages, which is why it is worth walking through again with current data.

The short version: if you installed a WeaveDB, Arweave, or asteroid-dao npm package on a Linux machine at any point since early June, treat that host as compromised and rotate every credential it could reach.

What happened

The attackers took over an npm publishing account named asteroiddao, which belongs to the asteroid-dao GitHub group behind the Arweave/WeaveDB project. From that account they republished a set of packages, each carrying an identical payload. According to Cryptopolitan, the campaign compromised 36 packages, all tied to the Arweave/WeaveDB ecosystem. OX Security put the combined install count for the affected packages at 32,177 downloads, so this is a targeted operation rather than a mass typosquat.

Each poisoned release dropped a roughly 976 KB Linux ELF binary into a tools/ directory and wired it to an install hook in package.json. SafeDep, Cryptopolitan and Crypto Times describe it as a preinstall hook, while Snyk logs it as a postinstall script. Either way, the binary ran automatically during npm install, before most developers had a chance to inspect anything. A normal install on a normal workstation was enough to trigger it. The flagship example was weavedb-sdk@0.45.3.

This is not the same event as the jscrambler npm compromise from earlier in the week, and it is separate from the Red Hat Miasma worm. IronWorm is its own campaign, first seen on 2026-06-03, and it is still producing new packages.

Timeline

• 2026-06-03: First malicious WeaveDB packages published from the asteroiddao account and detected by supply chain scanners.
• 2026-06-04: JFrog publishes analysis. SlowMist issues a threat intelligence alert. Dark Reading, Crypto Times and others cover the campaign.
• Early June: Snyk and SafeDep catalog the individual packages (weavedb-sdk, weavedb-tools and others) as malware.
• 2026-07-13: Startup Fortune reports that crypto projects have taken repeated npm hits, describing two npm attacks in four days.
• 2026-07-14: Our catalog records new WeaveDB-family malware, including weavedb-contracts and weavedb-client, alongside a cluster of other crypto-related npm packages flagged the same day.

Who is affected

The most direct victims are anyone who pulled a package published by the asteroiddao account. Cryptopolitan reports the malicious activity touched several organizations and identities: asteroid-dao, weavedb, ArweaveOasis, and personal accounts linked to the developer known as ocrybit.

Because IronWorm targets developer machines and CI/CD systems, the blast radius is wider than the direct package consumers. Snyk and SafeDep describe a stealer that scrapes over 80 kinds of secrets, and Cryptopolitan counts 86 environment variables and 20 credential files in scope. The stolen material includes cloud provider tokens, AI service API keys, npm and GitHub tokens, SSH keys, and cryptocurrency wallet material. SafeDep notes it also hunts through Kubernetes pods, so a single infected build agent can leak cluster secrets.

Separate from WeaveDB, our catalog logged a broader run of crypto-focused npm malware on 2026-07-14, including @rockawayx/utils and the @emcd-vue/auth scope. We have not confirmed those packages share IronWorm's binary, and we are not asserting a single operator. What we can say is that crypto engineering teams are the recurring target this week.

How the attack works

IronWorm has two jobs: steal secrets and spread itself.

The stealer side is a large Rust program. Researchers at GBHackers and Crypto Times report the sample was packed with a modified UPX stub, so standard upx -d fails until the altered signature is repaired. On top of that, the strings were encrypted with a unique key per call site, which slows manual analysis considerably. Once unpacked, the binary walks the filesystem and environment for the secret types listed above, then exfiltrates. SafeDep lists command and control over the Tor network (a tor://api/agent endpoint), a local agent listening on http://127.0.0.1:8738, and exfiltration to https://temp.sh. The same profile references a hardcoded wallet address, 0x7e28D9889f414B06c19a22A9Bd316f0AC279a4d6.

For persistence and stealth, IronWorm deploys an eBPF kernel rootkit. SafeDep records an artifact named q2.bpf.c, consistent with an eBPF component used to hide processes and network activity from ordinary tooling.

The worm side is what makes this campaign keep growing. Crypto Times, citing JFrog, reports 57 fake commits spread across nine organizations, disguised as routine maintenance and attributed to trusted automation identities such as claude, dependabot, and github-actions. SafeDep also flags communication with npm's OIDC token exchange endpoint (https://registry.npmjs.org/-/npm/v1/oidc/token/exchange/package), which points to abuse of trusted-publishing flows to push new package versions automatically. In practice, one compromised developer or CI token lets IronWorm inject its payload into more repositories and publish more poisoned packages, which is how weavedb-contracts and weavedb-client end up on the list weeks after the first wave. The technique maps to MITRE ATT&CK T1195.002, Compromise Software Supply Chain.

How to check if you are affected

Start with your lockfiles. Search every repository and build image for the known-bad package names and any package sourced from the asteroiddao publisher.

# grep lockfiles for WeaveDB-family packages
grep -R -nE "weavedb-sdk|weavedb-tools|weavedb-contracts|weavedb-client|asteroiddao" \
  package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

# list the packages in your installed tree
npm ls weavedb-sdk weavedb-tools weavedb-contracts weavedb-client 2>/dev/null

Look for the dropped binary and the install hook that launches it.

# the payload lives under a tools/ directory in the package
find node_modules -type f \( -path "*/tools/setup" -o -name "q2.bpf.c" \) 2>/dev/null

# print any lifecycle scripts your dependencies declare
find node_modules -name package.json -maxdepth 3 -exec \
  sh -c 'grep -l "\"preinstall\"\|\"postinstall\"" "$1"' _ {} \; 2>/dev/null

Then check the host for runtime indicators: outbound Tor connections, any process talking to temp.sh, and a local listener on port 8738.

# local agent listener and odd egress
ss -ltnp | grep 8738
ss -tnp | grep -i "temp.sh"

On the source-control side, review recent commit history for changes you did not make, especially anything attributed to claude, dependabot, or github-actions that touches tools/setup or .github/scripts/precheck.

Remediation

Treat any Linux host or CI runner that installed an affected package as fully compromised. Cleaning node_modules is not enough, because the payload ran with the developer's privileges and dropped a rootkit.

1. Isolate the machine or runner and rebuild it from a known-good image. Do not trust a running system that may host an eBPF rootkit.
2. Remove the malicious packages and reinstall a clean, pinned dependency set from a verified source.
3. Rotate every secret the host could reach: npm tokens, GitHub PATs and OAuth tokens, cloud provider keys, AI API keys, SSH keys, and any crypto wallet seed phrases or private keys. Assume all of them leaked.
4. Rotate Kubernetes service account tokens and any secrets mounted into build pods.
5. Revoke and reissue npm trusted-publishing (OIDC) configuration for affected packages, since the worm abuses the token exchange flow to publish.
6. Going forward, install with scripts disabled by default and vet lifecycle hooks before enabling them.

# block lifecycle scripts during install
npm install --ignore-scripts

# or set it permanently for the project/user
npm config set ignore-scripts true

npm v12 now blocks install scripts by default, which removes the automatic-execution path IronWorm relies on. That helps for new installs, but it does nothing for machines already infected, so the rotation steps above are not optional.

FAQ

Is WeaveDB safe to use?

The WeaveDB source project is a legitimate Arweave database, but the npm packages published under the compromised asteroiddao account were trojanized. Do not install weavedb-sdk, weavedb-tools, weavedb-contracts, weavedb-client, or other asteroid-dao packages until maintainers confirm clean, re-signed releases. Pin to a specific reviewed version rather than a range.

How do I know if I am affected by IronWorm?

Grep your lockfiles for the package names above, then check hosts for the tools/setup binary, the q2.bpf.c eBPF artifact, a listener on 127.0.0.1:8738, and outbound Tor or temp.sh traffic. If any of those are present, or if you ran npm install on a project that pulled an affected package, assume compromise and rotate credentials.

What credentials should I rotate after an IronWorm infection?

All of them that the host could see. Cryptopolitan and SafeDep report the stealer targets 86 environment variables and more than 20 credential files, covering cloud tokens, AI API keys, npm and GitHub tokens, SSH keys, and crypto wallet material. Kubernetes service account tokens on build agents are included.

Does npm v12 stop IronWorm?

It closes the main door. IronWorm executes through an install lifecycle hook, and npm v12 blocks those scripts by default. That prevents fresh infections during install, but it cannot undo an existing compromise or remove the eBPF rootkit, so already-affected systems still need to be rebuilt and re-keyed.