IronWorm npm Supply Chain Attack June 2026: Full Analysis, IOCs, and Koban Detection Rules

IronWorm, a Rust-built eBPF worm, hit 37 npm packages in the Arweave and WeaveDB ecosystem in early June 2026. Details on the attack, affected packages, propagation via OIDC, and practical Koban fleet rules with sample configurations to detect it on developer machines.

June 7, 2026Koban Team

npm
supply-chain
ironworm
koban
fleet-rules
javascript-packages

In early June 2026, security researchers disclosed IronWorm, a sophisticated supply chain worm that compromised around 37 npm packages, primarily from the Arweave and WeaveDB ecosystem. The campaign stands out for its use of a Rust-based implant, an embedded eBPF rootkit for stealth, Tor-based command and control, and propagation that leverages npm's Trusted Publishing OIDC flow without needing stored credentials.

This post breaks down the technical details, lists key indicators of compromise, and shows exactly how to configure Koban to surface these threats on developer Macs through lockfile monitoring and fleet rules.

What happened

Reports surfaced around June 3, 2026. Attackers had access to the asteroiddao npm account (linked to Arweave-related projects). They republished malicious versions of packages the account controlled. Each trojanized package included a preinstall hook that executed a 976 KB Rust ELF binary.

The binary:

Harvests a wide range of credentials (AWS, GCP, Azure, Vault, Kubernetes, npm, GitHub, and multiple AI provider keys).
Includes wallet-stealing logic targeting tools like Exodus.
Self-replicates by using OIDC token exchange on CI runners to publish new malicious versions.
Commits backdated malicious changes to GitHub repositories, often spoofing identities like claude@users.noreply.github.com or common bots.
Uses an embedded eBPF program to hide its processes and network activity.
Communicates over Tor.

The affected packages had a combined total of roughly 32,000 monthly downloads at the time of disclosure. Researchers noted the threat was contained before it reached more popular packages, though cleanup of GitHub commits was incomplete.

This attack shares operational similarities with the Miasma family (see our posts on the Red Hat compromise and the Phantom Gyp binding.gyp variant) but introduces lower-level techniques like Rust and kernel rootkits.

Affected packages and IOCs

The bulk of the packages belong to the WeaveDB/Arweave tooling ecosystem. Here are some of the compromised names (full lists appear in researcher reports from JFrog, OX Security, and others):

weavedb-sdk, weavedb-sdk-base, weavedb-sdk-node, weavedb-client, weavedb-console, weavedb-contracts, weavedb-offchain, weavedb-tools, weavedb-exm-sdk, weavedb-exm-sdk-web, weavedb-warp-contracts-plugin-deploy, weavedb-base
wdb-cli, wdb-core, wdb-sdk
wao, cwao, cwao-tools, cwao-units
arnext, arnext-arkb, atomic-notes, create-arnext-app
ai3, aonote, arjson, fpjson-lang, hbsig, monade, roidjs, zkjson
Various test- and warp-contracts-plugin- packages

Malicious versions were typically minor bumps (e.g., patch or small minor) designed to be pulled in by normal SemVer resolution. The preinstall hook pointed to a bundled binary in a tools/ or similar directory.

Key behavioral IOCs observed:

Preinstall scripts executing binaries from package contents.
Unexpected network activity to Tor hidden services during install.
New GitHub commits authored by automation accounts with backdated timestamps.
Rust ELF binaries appearing in node_modules under affected packages.

Why this matters for developer machines

CI runners were a primary vector for propagation because of OIDC. However, any developer who ran npm install (or had a lockfile resolve an affected version) pulled the implant onto their Mac. The eBPF rootkit component targets Linux primarily for hiding, but the credential theft and self-replication logic affect the broader environment.

Traditional registry takedowns and CVE scanners offer limited help here because there is no assigned CVE and the malicious code ships inside otherwise normal-looking packages.

How Koban detects IronWorm and similar npm worms

Koban inventories the javascriptPackages surface by reading lockfiles (npm, pnpm, Yarn, Bun) from projects on enrolled Macs. It builds snapshots, diffs changes, and evaluates YAML rules locally before syncing findings to Fleet.

Relevant capabilities for this campaign:

Name-based matching on package names (catches the specific ecosystem packages).
The hasInstallScript flag (IronWorm used preinstall hooks).
present trigger (surfaces already-installed bad packages when you deploy a new rule).
Registry and source URL fields for additional provenance checks.
Direct integration with fleet rules that run on every snapshot or change.

We already expanded the built-in packages.known-malicious-javascript rule for the Miasma campaign. The same pattern applies here.

Sample Koban fleet rules and configs

Here is a focused set of rules you can add to your org bundle (or test locally in ~/.config/koban/koban.yaml). These complement the defaults.

rules:
  # Specific ecosystem coverage for IronWorm
  - id: packages.ironworm.weavedb-ecosystem
    surface: javascriptPackages
    triggers: [added, modified, present]
    match: fieldContainsAny
    field: name
    values:
      - "weavedb"
      - "wdb-"
      - "wao"
      - "cwao"
      - "arnext"
      - "arweave"
      - "ai3"
      - "aonote"
      - "fpjson-lang"
      - "zkjson"
    severity: suspicious
    title: IronWorm campaign package (Arweave/WeaveDB ecosystem)
    rationale: Package name matches the IronWorm Rust eBPF worm that compromised Arweave and WeaveDB npm packages in June 2026.

  # Catch packages declaring install hooks during active campaigns
  - id: packages.javascript.has-install-script
    surface: javascriptPackages
    triggers: [added, modified, present]
    match: flagEquals
    flag: hasInstallScript
    expected: true
    severity: notable
    title: JavaScript package with install hook
    rationale: The resolved package declares an install, postinstall, or prepare script. Review in the context of recent supply chain activity.

  # Reinforce untrusted registry detection
  - id: packages.javascript.untrusted-registry
    surface: javascriptPackages
    triggers: [added, modified, present]
    match: fieldNotInList
    field: registry
    allowed: ["registry.npmjs.org"]
    severity: notable
    title: Non-default JavaScript package registry
    rationale: Package resolved from a registry other than the public npm registry.

For a complete high-signal bundle during periods of elevated npm worm activity, combine the above with the baseline production config from our quickstart docs and the Miasma-specific rules from our earlier posts. Bump the generation field every time you update.

Example minimal high-signal addition (merge into your existing bundle):

generation: "2026-06-07"

javascript:
  enabled: true

rules:
  # ... (include the IronWorm rules above plus Miasma rules)
  # Keep or extend the built-in known-malicious list in defaults for ongoing coverage

Test on a single machine by editing the local config, restarting the agent, and either forcing a rescan or simulating an install of a test package name.

What teams should do right now

Search lockfiles and node_modules across developer machines and CI for the affected package names and versions.
Rotate credentials (npm, GitHub, cloud, AI provider keys) from any environment that resolved a bad version.
Audit GitHub organizations the compromised account could reach for suspicious backdated commits.
Deploy or update Koban rules for name patterns in the WeaveDB/Arweave ecosystem (and keep the hasInstallScript signal active).
Prefer frozen lockfiles and explicit pins where possible.
Monitor for future waves — these attacks are increasing in frequency and sophistication.

Key takeaways

IronWorm demonstrates that supply chain worms are evolving beyond simple JavaScript droppers into compiled implants with kernel-level stealth.
Lockfile visibility on developer endpoints catches the symptom (the bad package landing) faster than waiting for registry or vendor advisories.
Koban’s rule system (name matching + flags + present trigger) gives teams precise, low-noise detection that runs locally before data leaves the machine.
Combining name IOCs for specific campaigns with broader behavioral signals (install hooks, untrusted registries) provides defense in depth.

The June 2026 period highlighted two major npm worm campaigns in quick succession. Continuous, structured inventory diffing remains one of the most practical controls available to development teams.