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

> A malicious @subql/common@5.8.3 shipped to npm on 5 October 2026 — a postinstall credential stealer that loots .npmrc, .env, AWS keys, SSH keys, kubeconfig and GitHub Actions runner memory and exfiltrates to ci-artifacts.dev. It’s part of ChainDrop, a self-propagating Shai-Hulud-family worm hitting hundreds of packages. In parallel, a malicious anthropic-sdk landed on PyPI. The common thread: the “trust the registry” assumption is gone. What’s confirmed, the real mechanism (why rotating npm tokens doesn’t save you), and the defender’s playbook.

Source: https://playciso.com/blog/subql-shai-hulud-chaindrop-npm-worm-supply-chain-2026 · Published: 2026-10-06 · Publisher: PlayCISO (https://playciso.com)

Primary source: https://www.stepsecurity.io/blog/subql-ecosystem-compromised

---

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](https://osv.dev/vulnerability/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](https://www.stepsecurity.io/blog/anthropic-incident-ai-agent-malicious-package-pypi). 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](/tools/npm-scanner) and [Package Scanner](/tools/package-scanner), build an [AIBOM](/tools/aibom), and rehearse the response in the [War Room](/warroom). More on this worm and its pattern: [keyv and the Shai-Hulud provenance problem](/blog/keyv-shai-hulud-npm-compromise-provenance), [what the Suno breach taught CISOs](/blog/suno-shai-hulud-breach-what-cisos-should-learn), and [the LiteLLM supply-chain attack](/blog/litellm-supply-chain-attack-teampcp-what-to-do). On AI agents as attackers, see [hacking becomes a factory](/blog/apex-flash-1-offensive-security-model-economics-of-hacking)._