KobanKoban
← All posts

June 2026 npm Supply Chain Worms Playbook: Miasma and IronWorm Detection with Koban

The first week of June 2026 saw two major npm worm campaigns (Miasma with the Red Hat and binding.gyp variants, plus IronWorm). This playbook explains the attacks, lists IOCs, and provides ready-to-use Koban fleet rules and full sample configurations to protect developer machines.

Koban Team
  • npm
  • supply-chain
  • miasma
  • ironworm
  • koban
  • fleet-rules
  • javascript-packages
  • supply-chain-security

Early June 2026 delivered a one-two punch of npm supply chain worms. The Miasma campaign (starting June 1 with Red Hat packages and continuing with the Phantom Gyp binding.gyp technique) was followed days later by IronWorm disclosures (Rust-based, eBPF rootkit, OIDC propagation through the Arweave ecosystem).

Both campaigns followed familiar patterns — credential theft, self-replication via trusted publish paths, and rapid spread through lockfiles — but each introduced new evasion or stealth elements. For teams running developer workstations and CI, the fastest practical signal often comes from continuous lockfile inventory on the machines where npm install actually happens.

This playbook consolidates the key facts, IOCs, and — most importantly — actionable Koban configurations you can deploy today.

Quick comparison of the two campaigns

Miasma (June 1–4, 2026)

  • Initial vector: Compromised Red Hat GitHub account → malicious commits to RedHatInsights repos → OIDC publish of 32+ @redhat-cloud-services packages.
  • Second wave: "Phantom Gyp" technique using a 157-byte binding.gyp file to abuse node-gyp and bypass traditional pre/postinstall monitoring. Hit @vapi-ai/server-sdk and then spread across dozens of packages (autotel family, awaitly, ai-sdk-ollama, etc.).
  • Payload: Multi-stage credential stealer (GitHub, cloud, CI secrets, runner memory scraping). Self-propagating worm.
  • Downloads: ~80k+ weekly for the Red Hat wave; rapid spread in the follow-on.

IronWorm (reports ~June 3, 2026)

  • Vector: Compromised asteroiddao npm account (Arweave/WeaveDB ecosystem).
  • ~37 packages republished with preinstall hooks pointing to a 976 KB Rust ELF.
  • Advanced features: eBPF rootkit for process/socket hiding, Tor C2, heavy anti-analysis (per-call-site string encryption, modified UPX), OIDC-based propagation without stored tokens, GitHub repo poisoning with backdated spoofed commits.
  • Focus: Credential harvesting (cloud, AI keys, wallets) + self-replication.
  • Scope: ~32k monthly downloads at disclosure; contained before hitting ultra-popular packages.

Both highlight the limits of registry-only defenses and the value of endpoint visibility into what actually resolves in lockfiles on developer and build machines.

Why lockfile monitoring on Macs (and CI-adjacent dev environments) matters

CI runners often have the richest secrets and OIDC federation. Developer laptops run the same commands during local work, reviews, and one-off installs. A poisoned transitive dependency or direct install updates the lockfile immediately. Koban reads those lockfiles as the javascriptPackages surface, diffs snapshots, and evaluates rules locally.

Key advantages for these incidents:

  • Catches both direct and transitive packages.
  • present trigger surfaces packages that were already on disk when you publish new rules.
  • hasInstallScript flag and name matching work even when attackers change execution techniques (preinstall vs binding.gyp vs Rust binary).
  • Runs on the actual machine before any data leaves for central analysis.

Start from the baseline production config in our quickstart docs (all surfaces enabled, built-in rules, sensible sync limits). Then layer targeted rules for the active campaigns.

Here is a practical high-signal bundle focused on the June 2026 activity. Copy the rules section and merge with your existing generation/timing/sync settings. Always bump generation when publishing changes.

generation: "2026-06-07"

watch:
  debounceMilliseconds: 800
  pollIntervalSeconds: 300

sync:
  maxBatchBytes: 524288
  maxBatchEvents: 500

javascript:
  enabled: true

python:
  enabled: true

# Enable other surfaces (claude, cursor, homebrew, etc.) as needed for your fleet

rules:
  # Miasma Red Hat and follow-on names (complements the expanded built-in known-malicious rule)
  - id: packages.miasma.vapi-wave
    surface: javascriptPackages
    triggers: [added, modified, present]
    match: fieldContainsAny
    field: name
    values: ["@vapi-ai/server-sdk", "ai-sdk-ollama"]
    severity: suspicious
    title: Miasma June 2026 package
    rationale: Name matches a package published during the Miasma binding.gyp / Phantom Gyp wave.

  - id: packages.miasma.autotel-family
    surface: javascriptPackages
    triggers: [added, modified, present]
    match: fieldContainsAny
    field: name
    values: ["autotel", "awaitly", "eslint-plugin-executable-stories", "node-env-resolver"]
    severity: suspicious
    title: Miasma spread family package
    rationale: Name matches a maintainer family hit by the self-propagating Miasma worm.

  # IronWorm Arweave/WeaveDB ecosystem coverage
  - 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"
      - "atomic-notes"
    severity: suspicious
    title: IronWorm campaign package (Arweave/WeaveDB ecosystem)
    rationale: Package name matches the IronWorm Rust eBPF worm that hit the Arweave and WeaveDB npm packages in June 2026.

  # General install-hook signal useful during active worm periods
  - 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: Package metadata shows an install, postinstall, or prepare script. Review resolved version during supply chain activity.

  # Provenance reinforcement
  - 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 one.

For even tighter alerting during an active incident, you can create a very narrow critical rule for one or two high-risk names and route it separately.

Test locally first:

  1. Add the rules to ~/.config/koban/koban.yaml on a test Mac.
  2. Restart the agent.
  3. Either wait for the next poll or trigger a change that would match (or use present evaluation against current inventory).

Additional detection and response recommendations

  • Search all lockfiles and node_modules for the package name patterns listed above.
  • Rotate reachable credentials from any machine or CI job that installed affected versions.
  • For IronWorm specifically, audit GitHub repos the compromised account could write to for backdated commits under automation identities.
  • Prefer npm ci / frozen lockfiles in pipelines.
  • Keep the built-in packages.known-malicious-javascript rule active (we continue expanding the name list in defaults as new campaigns are disclosed).
  • Monitor the javascriptPackages surface volume — sudden spikes in new packages or version changes in specific ecosystems can be an early indicator even before name IOCs are published.

Key takeaways for teams and security programs

  • Name-based IOC rules on the javascriptPackages surface remain the highest-confidence signal for known campaigns and work regardless of whether the attacker used preinstall, binding.gyp, or a Rust binary.
  • The hasInstallScript flag and present trigger provide useful breadth when attackers change techniques.
  • Continuous local diffing on developer machines turns "we got hit by the latest worm" into "Koban created a finding on three machines — here are the exact lockfiles and versions."
  • Fleet rules are intentionally simple and bounded. They give you fast, reviewable signals without requiring custom scripting or external data sources at evaluation time.

The 2026 surge in self-propagating npm worms shows no sign of slowing. Structured inventory of what actually lands in lockfiles on the machines where developers work is one of the highest-leverage controls available.

If you maintain a Koban fleet, the sample rules and bundle patterns above (combined with the expanded built-in list) give you immediate coverage for the documented June 2026 activity. Let us know if you want help tailoring a full production bundle for your environment.

Stay safe out there — and keep those lockfiles visible.