Hit by the Chaindrop npm worm? How Hyground helps you contain and disinfect it

The npm worm known as Chaindrop, the latest strain in the Shai-Hulud family, does not just add a bad dependency. It runs code the moment you install, steals every credential the build can reach, and republishes itself through your stolen npm token. So the first job is not to patch a version. It is to prove whether it executed, and if it did, to rotate everything it could touch. If you already run Hyground in your cluster, you can answer both questions today: a read-only investigation across GitHub, CI, Kubernetes, logs, and cloud audit finds the exposure and the blast radius, and every destructive fix stays behind human approval.

Last updated: 11 August 2026.

This post is for the on-call engineer or platform lead who just read the advisory, checked a lockfile, and found a match. It walks through how a team that already runs Hyground scopes the exposure, proves whether it executed, contains it, and rotates what it touched.

What is the Chaindrop worm, and why is it worse than a normal CVE?

A normal CVE is a vulnerable version you upgrade past. This is different. A compromised npm package runs a malicious preinstall script, which executes node setup.mjs before your application ever imports the dependency. That loader stages a second-stage payload on the Bun runtime (using an existing bun or downloading v1.3.13), reads every credential it can find (environment variables, CI secrets, cloud credentials, Kubernetes secrets, Vault data, SSH keys), exfiltrates them over encrypted HTTPS, and then uses any valid npm publish token it finds to inject the same preinstall into more packages. Chaindrop is the current strain. The family is Shai-Hulud, and it signs its work the same way: the exfiltration repositories carry the description "Shai-Hulud: Here We Go Again."

There is a limit on how far it spreads. The worm can only republish through a stolen credential that is actually allowed to push: an npm token or a GitHub identity with write access, on an account that does not enforce two-factor authentication. Where publishing requires 2FA or a hardware key, the automated republish step stalls. That is one reason the blast radius is uneven across an org, and one of the first things worth checking.

The distinction that shapes the whole incident:

A match in a lockfile is an exposure signal. A completed install or CI run is a potential credential-compromise event.

So the question is never just whether you have the package. It is whether the install script ran, and if it did, what it could reach.

Meet Arrakis Retail, mid-incident

To make this concrete, take a fictional customer, Arrakis Retail: around forty services on Kubernetes, GitHub Actions for CI, workloads on Azure, and Hyground deployed read-only inside the cluster. Their dependency bot opened a routine update PR overnight. By morning the advisory is out and one of the pinned versions is on the malicious list. The lockfile match is confirmed. Nobody knows yet whether it ran. We will follow Arrakis Retail through each phase.

Hour zero: are we even affected?

Before touching anything, turn the advisory into a hunt. Paste the affected package list, the file names (setup.mjs, math_init.js, Math_Symbol.js), and the publication window into a session, and ask the agent to search the estate it can already see.

Hyground's read-only GitHub adapter can inspect repositories, pull requests, releases, workflow runs, check suites, and Actions logs. Point it at the whole org and have it find:

• the package name and known-bad versions in package.json, and the resolved versions in package-lock.json, pnpm-lock.yaml, yarn.lock, and Bun lockfiles;
• preinstall additions and any setup.mjs in the tree;
• the dependency-update PR that introduced the version, and who or what merged it;
• Actions runs that executed npm install, npm ci, pnpm install, or bun inside the exposure window;
• bot-authored commits, unexpected releases, or the same change spreading across repositories.

For Arrakis Retail this narrows "forty services" to "three repos resolved the bad version, and only one of them ran an install in CI last night." That single distinction, resolved versus actually installed, is what turns a day of manual grep into a scoped investigation.

Did it actually execute?

A lockfile hit does not prove execution. Proving it is where the read-only Kubernetes and observability adapters earn their place. Have the agent investigate the build namespace and correlate:

• pod or Job creation during the exposure window;
• log lines containing preinstall, setup.mjs, or bun, across OpenSearch or Loki;
• an unexpected bun process, the lock file tmp.dpkg_14527.lock, or the marker _NODE_RUNTIME_INIT=1;
• which ServiceAccount, workload identity, and mounted secrets that pod actually had.

The value is the chain, followed in one investigation rather than across four teams:

a dependency resolved, then a CI workflow executed it, then the build pod had an identity and secrets mounted, then the process and log evidence shows the install ran, so specific credentials and downstream repositories enter the blast radius.

For Arrakis Retail, the logs show setup.mjs executed in one build pod, and that pod mounted an Azure workload identity and a shared npm publish token. Exposure just became an incident.

What is in the blast radius?

Once execution is confirmed on a privileged runner, the worm is after your spice: the credentials that let it move. Assume everything the job could reach is compromised until proven otherwise. The agent enumerates what that runner could touch (npm publisher tokens, GitHub PATs and Actions credentials, cloud service principals and managed identities, Kubernetes ServiceAccount tokens and in-cluster secrets, Vault tokens, SSH keys and deploy keys), and then uses log and cloud-audit sources to separate possible exposure from evidence of use:

• anomalous Key Vault or secret reads from the runner identity;
• npm publish activity outside the normal release pipeline;
• GitHub token or workflow activity that does not match a known job;
• pushes from a CI identity into unrelated repositories;
• new public repositories matching the exfiltration pattern.

That list is the difference between "rotate one token" and "rotate the token, the workload identity, and audit every repo that identity could publish to." Hyground produces it as evidence, with timestamps you can hand to a security reviewer.

Disinfect and rotate, without making it worse

Here is the deliberate part. Hyground writes nothing destructive on its own. Write actions trip a signed, human-in-the-loop approval gate, so the agent's job is to assemble a precise incident packet and the exact remediation list, and a human approves each action. The packet for Arrakis Retail reads:

1. affected repositories, resolved package versions, and the installation runs that executed them;
2. the build pod, its timeline, and the process and log evidence;
3. the identities and secrets that were reachable from that execution context;
4. the suspected propagation targets;
5. the recommended containment and rotation actions, ordered by risk.

The humans then act on it in order: contain first (halt affected builds, isolate the workload), rotate second (npm, GitHub, cloud, Kubernetes, and SSH credentials the job could reach, publish tokens first because that is how the worm spreads), and eradicate last (remove the bad versions, rebuild from a trusted lockfile, and confirm the malicious preinstall is gone). Rotate based on execution, not just package presence. A lockfile hit with no install does not need a credential rotation. A confirmed install on a runner with a publish token needs all of them.

The principle underneath it: evidence collection should be fast, and irreversible remediation should be slow, explicit, and auditable.

Stop the next spore

Disinfecting once is not the same as staying clean. The durable controls are ordinary supply-chain hygiene, and Hyground's role is to verify they actually rolled out and to keep hunting for residual hits:

• Enforce two-factor authentication on publish. The worm can only republish through a stolen token that has write access on an account without 2FA. Require 2FA for npm and GitHub, and prefer hardware-backed publishing, so a compromised install has nothing to push with.
• Block the known-bad versions at your registry proxy, so a bad release cannot resolve again.
• Reduce lifecycle-script risk. Install untrusted dependencies with --ignore-scripts where you can, and keep build-only installs away from any context that holds a publish token. As Arrakis Retail's lead put it, walk without rhythm and you do not summon the worm: predictable install scripts running with production credentials are exactly the footfall it listens for.
• Split build and publish credentials, and make publish tokens short-lived and scoped, so a compromised install cannot immediately republish.
• Give CI runners least privilege. The agent can audit which runner identities carry which permissions and mounted secrets, and flag the over-scoped ones from audit evidence.
• Freeze automated dependency merges during the incident window, and require human review for lockfile changes.

None of these are novel. The worm succeeds because they are unevenly applied. Hyground's contribution is turning "we think that is enforced everywhere" into "here are the three clusters where it is not."

Where Hyground stops

Hyground is the investigation and response layer for this incident, not an npm security product. It does not ingest npm advisories or score package reputation. It does not keep an org-wide dependency inventory out of the box, diff lockfiles, or map packages to running workloads. It does not generate SBOMs by default; the shipped scanner leaves that off. It has no universal process or EDR agent, and it does not inspect outbound network traffic. So whether the install actually ran depends on the process and application logs you already ship. If nothing recorded the execution, the agent can confirm exposure but not compromise.

Pair it accordingly. Put a package firewall or curated registry in front of installs to stop known-bad versions before they run, and keep an SCA tool for advisory ingestion. Hyground then connects the package to the CI run that installed it, the identity that executed it, the secrets that were reachable, and the systems those secrets could change, in one read-only investigation, with every fix behind human approval.

What to take from this

The install step is now part of your production attack surface. Scanning dependencies more often does not change that on its own. What matters during an incident is moving from "are we affected" to "which exact assets, identities, and releases are at risk, and here is the approved plan to rotate and rebuild them," inside a single investigation. To see that loop run against a real cluster, book a demo.