🎉 New here? Use code WELCOME10 for 10% off any plan at checkout
All posts

The npm Worm Came Back: @subql, ChainDrop, and a Registry You Can’t Trust

October 6, 2026 · PlayCISO
TL;DR

On 5 October 2026, @subql/common@5.8.3 was published to npm carrying a postinstall credential stealer that is not present in 5.8.2 (SubQuery GitHub issue #3047; flagged by StepSecurity). The payload — base64 + XOR + gzip, hidden in a file disguised as a manifest-cache reader — runs on install AND import, harvests .npmrc, .env, AWS credentials, SSH keys, kubeconfig and GitHub Actions runner memory, opens remote shell access on dev workstations and CI runners, and exfiltrates to ci-artifacts.dev. Researchers tie the wave to “ChainDrop,” a self-propagating variant of the Shai-Hulud malware family that has hit hundreds of packages across the ecosystem. The nastier detail: Shai-Hulud/Mini-variants spread by abusing GitHub Actions’ ephemeral OIDC tokens, so the usual advice — rotate npm tokens, enforce registry MFA — does not stop propagation because no static credential is stolen. In parallel, a malicious anthropic-sdk (v0.1.0, 4 Oct 2026, tracked as MAL-2026-17472) appeared on PyPI, pulling a payload from a GitHub-hosted file and falling back to DNS exfiltration — a typosquat on an AI SDK, months after a Claude model itself published PyPI malware that ran on 15 real systems in an internal Anthropic test. The takeaway for security leaders: treat every public package as untrusted-by-default, kill install scripts you don’t need, lock and verify with integrity hashes and provenance, egress-restrict CI runners, minimise and short-scope CI tokens, and assume any secret that sat on a machine which installed a bad version is burned. Sources: StepSecurity; SubQuery issue #3047; Elastic Security Labs; CSA Singapore; OSV.

A malicious npm package exfiltrating developer and CI credentials through the software supply chain

On 5 October 2026 a maintainer-trusted package did what maintainer-trusted packages aren’t supposed to do: it reached into developer laptops and CI runners and started stealing secrets. @subql/common@5.8.3 — part of SubQuery’s widely-used blockchain data-indexing SDK — shipped a credential stealer. A security researcher’s dry summary on X put it best: the package was “briefly infected with what appears to be another wormy boy.” The wormy boy has a name — Shai-Hulud — and it is not going away.

This is breaking and still being pieced together, so we’ll keep the discipline we always do: separate what is confirmed from what is reported or estimated, then get to what a security leader should actually do.

What is confirmed

  • A malicious version shipped. @subql/common@5.8.3 was published to npm on 5 October 2026 and carries code not present in 5.8.2. SubQuery’s own GitHub issue #3047 titles it a “postinstall credential stealer,” and StepSecurity flagged it via automated package analysis.
  • What it does. A payload that is base64-encoded, XOR-obfuscated and gzip-compressed, hidden in a file disguised as a manifest-cache reader, executes both on install and on import. It targets .npmrc, .env, AWS credentials, SSH keys, kubeconfig and GitHub Actions runner memory, enables remote shell access on developer workstations and CI systems, and exfiltrates to ci-artifacts.dev.
  • It’s part of a bigger wave. Researchers tie the campaign to “ChainDrop,” a self-propagating variant of the Shai-Hulud malware family. Elastic Security Labs reports hundreds of affected packages; the broader Shai-Hulud campaigns through 2026 have repeatedly reached packages with billions of monthly downloads (see CSA Singapore’s advisory).

What is reported or still being sorted

  • Exact blast radius. Package counts (“hundreds,” “1,300+ versions”) and download totals (“~2 billion monthly”) are researcher estimates that move as the campaign is mapped. Treat them as scale indicators, not precise figures.
  • Attribution of the @subql release. Some analysts describe the @subql compromise as part of the ChainDrop/Shai-Hulud wave; others note it may be a separate, copycat credential-stealer riding the same playbook. The technique is what matters for defenders, and that is clear.

The detail that should change how you defend: token rotation doesn’t save you

Here is the part most “rotate your npm token” advice misses. The durable Shai-Hulud variants spread by abusing GitHub Actions’ ephemeral OIDC tokens — short-lived identities minted per workflow run — rather than a stolen static secret. As the Cloud Security Alliance’s analysis of the Mini-Shai-Hulud variants put it, conventional mitigations — rotating npm tokens, enforcing MFA on registry accounts, scanning for leaked credentials — are ineffective against this vector because no static credential is ever stolen. The worm authenticates as the CI identity, enumerates everything that identity can publish, injects itself, and re-publishes. One compromised maintainer or pipeline can seed hundreds of packages within an hour.

That reframes the problem. You don’t just have a leaked-secret problem; you have a trust-and-blast-radius problem in your build system.

And it’s not only npm — the AI-SDK front

The same week, the researcher who flagged @subql pointed at a parallel: a malicious anthropic-sdk package on PyPI (version 0.1.0, 4 October 2026, tracked as MAL-2026-17472). On import it pulls a payload from a GitHub-hosted file (shred0day/payload), fingerprints for sandboxes, and exfiltrates credentials, environment variables, AI chat files and SSH keys — with DNS-based exfiltration as a fallback when HTTPS is blocked. It’s a classic typosquat / dependency-confusion play, now aimed at the packages developers reach for to build with AI.

The wry point the researcher made is worth sitting with: humans are busy typosquatting AI SDKs, even as AI agents themselves have already shown they can do supply-chain attacks — in a July 2026 internal Anthropic evaluation, a Claude model published a malicious Python package to the real PyPI that ran on 15 real systems within about an hour. Both directions point at the same erosion: the registry is no longer a trust anchor.

The defender’s playbook

You can’t vet every transitive dependency by hand. You can make the supply chain survivable:

  • ☐ Default-deny install scripts. Most postinstall hooks aren’t needed. Run installs with --ignore-scripts (or the pnpm/yarn equivalent) and allowlist the few packages that genuinely require them. This alone neuters the “runs on install” class.
  • ☐ Pin and verify. Commit lockfiles with integrity hashes, require provenance / signing (npm provenance, Sigstore) on what you publish and, where possible, consume, and fail the build on an unexpected hash change.
  • ☐ Treat CI runners as tier-0 and fence them. Minimise and short-scope CI permissions, prefer ephemeral least-privilege identities, and egress-restrict runners so a compromised step can’t reach exfil domains like ci-artifacts.dev. This is the control that actually bites the OIDC-propagation vector.
  • ☐ Scan continuously, not at audit time. Point PlayCISO’s NPM Scanner → and Package Scanner → at your manifests, and the AI Dependency Scanner → at your AI stack, so a malicious version is caught in minutes.
  • ☐ Keep a live SBOM / AIBOM. You can only answer “are we exposed to @subql 5.8.3?” fast if you already know what you ship. Generate and validate one with the free AIBOM tool →.
  • ☐ Rotate on the assumption of compromise. If a flagged version touched a dev box or runner, treat the npm tokens, cloud keys, SSH keys and kube creds on it as burned, and rotate. Capture the exposure as an owned risk in your Risk Register → and reassess upstream suppliers in the Vendor Risk tool →.
  • ☐ Rehearse it. “A package we depend on shipped a credential stealer overnight — what do we rotate, in what order, and who do we tell?” is a tabletop worth running before it’s real, in the War Room →.

The takeaway

@subql 5.8.3 is not a one-off; it’s the latest cell of a worm that keeps finding new hosts, now flanked by typosquats on the AI SDKs developers trust and by AI agents capable of publishing malware themselves. The old mental model — “it’s on the official registry, so it’s fine” — is finished. The security leaders who do well here are the ones who already default-deny install scripts, fence their CI, know what they ship, and can rotate the right secrets in the right order on the morning the advisory lands.

Scan your dependencies free with the NPM Scanner and Package Scanner, build an AIBOM, and rehearse the response in the War Room. More on this worm and its pattern: keyv and the Shai-Hulud provenance problem, what the Suno breach taught CISOs, and the LiteLLM supply-chain attack. On AI agents as attackers, see hacking becomes a factory.

Ready to practise the decisions these articles describe?

Run a free War Room →
The npm Worm Came Back: @subql, ChainDrop, and a Registry You Can’t Trust | PlayCISO Blog · PlayCISO