The Compromised-Package Runbook: From Advisory to Contained Blast Radius

A package your code depends on just got flagged as compromised. This runbook is for the engineering manager, technical founder, or on-call responder who now has to answer three questions before attackers act: where am I exposed, what executed, and which secrets do I rotate. It walks the live incident in order, so you can go from an advisory to a contained blast radius inside the first hour with the tools you already have. It does not sell you a scanner and it does not stop at "update the package."

Most repo guides cover triaging a known CVE or reading whether a compromise flag is real. This one assumes the flag is real and the clock is running. The named 2026 campaigns propagate in minutes, so the work is enumeration and rotation under time pressure, not deliberation.

What "contained blast radius" actually means here

Contained means every place that resolved a bad version is found, each is tagged contain-or-wait, and every secret reachable from an affected host is rotated in dependency order. It is a state you can prove from audit logs, not a feeling.

The trap is treating this as a dependency-update task. Removing the package cleans your local tree; it says nothing about what a payload already exfiltrated. JFrog is explicit that removal is not enough: if an affected version ran, you revoke credentials, inspect every writable repository branch, and rebuild the host or CI runner from a clean image. So the deliverable is not a green lockfile. It is a rotation set and a persistence audit.

The order of operations matters because the failure modes cluster at the boundaries: people who investigate before containing let the next build run, and people who rotate before scoping leave the cascade intact.

Confirm the advisory and pull the identifiers

The first five minutes are for turning a vague alert into a precise list of bad versions and search terms. You cannot enumerate exposure against "some npm thing is bad." You need exact package names, affected version ranges, the campaign name, and any CVE.

Cross-check four sources: GitHub Security Advisories (GHSA), the CISA Known Exploited Vulnerabilities (KEV) catalog, OSV.dev, and the registry or vendor post-mortem. GitHub now imports OSV and OpenSSF malicious-package data, and setting type=malware in advisory search pulls supply-chain malware advisories such as malicious npm packages. Search on both the CVE and the campaign name, because the two index different corners of the web.

Here are the confirmed identifiers worth keeping in your search bar.

The campaign name is as useful as the CVE. Search terms that surface post-mortems fast: "Shai-Hulud," "Sha1-Hulud: The Second Coming," "CHAINDROP," "Mini Shai-Hulud," "TeamPCP," and "Megalodon." Knowing the campaign changes your containment. A stolen-token wave demands npm-token revocation and re-publish checks; a credential-free OIDC or CI wave demands you treat the pipeline identity itself as compromised.

Know which campaign you are fighting

The named 2026 campaigns differ by how the attacker got in, and that difference dictates what you rotate. A responder who misreads the initial-access technique rotates the wrong class of secret and misses the real foothold.

Read the table as three response shapes. Stolen-token waves (Shai-Hulud) mean revoke npm tokens and audit re-publishes. Pre-install and worm waves (Shai-Hulud 2.0, CHAINDROP) execute on virtually every build server processing the infected package and bypass static scanners that inspect code during later build stages, so "our scanner is green" is not evidence of safety. Credential-free CI waves (Mini Shai-Hulud, trivy-action) abuse the pipeline itself: Mini Shai-Hulud chained a GitHub Actions Pwn Request, cache poisoning, and OIDC token extraction from runner memory, producing the first npm attack with valid SLSA Build Level 3 attestations. For that class, treat the CI identity as compromised, not just the token.

The lesson embedded in that number: rank your response by install-time execution and reachable secrets, not by package popularity or download counts. The exposure list a human builds is always lagging the worm.

Enumerate exposure across every lockfile and pipeline

Enumeration means grepping every lockfile, manifest, and workflow file across every repo, plus checking transitive paths and tag-referenced actions. The output is a complete list of repos, services, and pipelines that resolved a bad version.

Do not stop at direct dependencies. The bad version often arrives transitively. Three complementary techniques cover the ground:

• Code search. A quick gh search code across your repos locates every consumer in minutes. Grep for the exact bad version strings in package-lock.json, yarn.lock, and pnpm-lock.yaml.
• Dependency graph. GitHub's dependency graph shows the transitive path that brought in a dependency via "Show paths," and can be filtered by relationship status: direct, transitive, or inconclusive. The GraphQL API returns a relationship field with direct, transitive, or unknown values.
• Workflow YAML. Grep every .github/workflows/*.yml for the compromised action, and for each hit, resolve whether it is pinned to a tag or a SHA.

That last check is the highest-leverage move in the whole runbook. A repo can be fully exposed while its manifest is unchanged, because a Git tag maps to a commit and, by default, anyone with push access can reassign it to a different commit. In the trivy-action case the attacker force-pushed 76 of 77 version tags in aquasecurity/trivy-action and all 7 in setup-trivy; the only clean tag was 0.35.0, and every other release from 0.0.1 through 0.34.2 served a malicious entrypoint.sh. The release page did not change: same name, date, description, but the code behind each tag contained a stealer.

Only workflows pinned to a commit hash ran the code they always ran. In two consecutive years, workflows referencing actions by 40-character commit hash were completely immune, including the March 2025 wave that compromised 23,000+ repositories. So for every tag-pinned action, verify the commit SHA against a known-good state. Do not trust GitHub's "Immutable Release" badge: it did not stop the attack, and the attacker may have locked the malicious state in place.

Building the exposure list under time pressure is exactly where a plain-English search tool earns its place. If you also need to stand up a response team fast because your on-call is a generalist, you can search for the specific experience this incident demands rather than posting a job and waiting.

The procedure, in order

This is the runbook to execute start to finish. Steps 5 and 6 run parallel to 7 once containment is done; the numbers are the order you start them, not a strict serial chain.

On the dependency-remediation mechanics: the simplest immediate step is to delete the specific compromised package's folder within node_modules, and on the next install npm will pull the known-good version if the malicious ones were removed. For critical dependencies, manually pin to a specific known-good version in package.json to prevent automatic upgrades. Prefer npm ci, which deletes node_modules, installs exactly the lockfile versions, fails if the lockfile is inconsistent, and never modifies the lockfile. You usually do not need to delete the lockfile: only remove it if, after adding overrides or resolutions and reinstalling, the resolver still keeps the compromised version.

Which secrets to rotate, and in what order

Rotate every secret reachable from an affected host, not only the flagged token, and rotate in dependency order. The modern implants are indiscriminate harvesters, so scoping the reachable set is the difference between a one-hour incident and a one-week one.

CISA states the actor targeted GitHub PATs and cloud API keys for AWS, GCP, and Azure, exfiltrated them, and uploaded them to a public "Shai-Hulud" repo via the GitHub API. The CHAINDROP variant's harvester scans over 300 unique patterns across many credential stores on a developer machine.

CHAINDROP also targets AI-tooling credentials (Anthropic, Claude, Codex, Cursor, OpenAI, Gemini) and reads runner process memory to steal ACTIONS_ID_TOKEN_REQUEST_TOKEN. Earlier waves parsed .git/config for embedded credentials. The point of the table is not completeness; it is that "the npm token" is never the whole answer.

The sequencing rule: start by identifying what the secret can access, not by rotating it immediately. Then rotate break-glass and admin credentials first, service accounts next, users last, updating all consumers and invalidating tokens and sessions as you go. Rotate GitHub secrets at the repository, environment, and organization levels, because a secret set at only one level leaves the others live.

How this goes wrong: failure modes and false positives

The costliest mistakes in this runbook are false confidence, not missing knowledge. Each of the following has burned real teams; each has a one-line check.

• Grep-by-package-name misses tag rewrites. A repo can be exposed while its manifest is unchanged. Check: is the action pinned to a 40-char SHA or a tag? Only SHA pins are clean.
• "I deleted node_modules, I'm safe" false positive. Removal ignores exfiltration that already happened; removing a JS file does not show its collected secrets were not already exported. Check: was the secret store reachable during the run window?
• Rotating the stolen token first can arm the payload. In keyv and cacheable, revoking the stolen token is exactly what arms the payload. Check: look for a ransom-style token description before revocation.
• Rotating only the flagged token leaves the cascade. If it accessed other secrets, those are compromised too. Check: enumerate every secret reachable from the host first.
• Deleting the lockfile unnecessarily can pull a newer bad version. Only remove the lockfile if overrides or resolutions plus reinstall still keep the compromised version. Check: does the lockfile already pin a safe version?
• Trusting GitHub's immutable badge. The badge did not stop the attack; the attacker may have locked the malicious state in place. Check: verify the commit SHA against a known-good, not the badge.
• Rotation without a persistence hunt. If you saw suspicious usage, rotating does not remove the leak. Check: audit logs for attacker-created PATs, workflows, and repo visibility flips.
• Assuming trusted publishing removes the risk. If an attacker compromises the workflow or the account behind the job, the publish action is still authenticated as a trusted path. Check: treat the CI identity as compromised, not just the token.

That last one is not theoretical. Red Hat's wave shipped 96 compromised package versions across 32 @redhat-cloud-services packages through GitHub Actions OIDC. Trusted publishing reduces one secret class but not the dependency on pipeline integrity. Note also the limit of automated tooling: GitHub secret scanning supports 39 token types with push protection, but custom API keys and internal tokens are not detected, so your custom credentials will not trip an alert.

Hunt for persistence, then verify you are done

Persistence hunting is the last step and the one teams skip when the pressure lifts. Rotation stops the attacker using stolen credentials; it does nothing about footholds they planted while they had access.

Look for attacker-created artifacts: planted workflows such as shai-hulud-workflow.yml, new PATs, OAuth grants, deploy keys, repositories flipped from private to public, and altered branch protections. Datadog observed that Shai-Hulud 2.0 backdoors up to 100 of the victim's own packages, and if it can neither replicate nor exfiltrate it attempts to delete the home directory, so also confirm your own published packages were not backdoored during the window. Removing a JavaScript file does not demonstrate that collected secrets were not already exported.

Keeping the runbook current and staffing it

The two variables that go stale are the campaign list and your team's ability to execute. Both need a re-check cadence.

For the campaign list, subscribe to CISA KEV and GitHub Security Advisory feeds and re-read your grep patterns whenever a new named wave lands. GitHub has shipped defensive defaults you should confirm are on: a three-day cooldown delaying version update PRs so findings can be addressed before code intake, and push protection for the 39 supported token types. Adopt SHA-pinning tooling so future waves cannot reach you through tag rewrites, and enforce it in review.

The harder gap is people. Refolk's index shows only 59 US practitioners matching supply-chain, incident-response, and CI/CD-security signals together, and zero under the same narrow filter in Germany, so most teams will run this playbook with generalist app-sec staff. That is precisely why a pre-written, order-of-operations runbook matters more than a specialist you do not have.

If you decide to hire ahead of the next incident, the title distribution tells you what the market actually calls this work.

The pool is heavily US-concentrated and thin, which is a planning fact, not a footnote. Stolen credentials drive 22% of incidents and take an average of 292 days to resolve, so the cost of not having this runbook ready is measured in months, not the hour it takes to execute. Write down your own IOC-grep patterns, your rotation dependency order, and your persistence-hunt queries now, while nothing is on fire. When the advisory lands at 2am, the team that already has this document open is the team that contains the blast radius before the token is harvested.

COMPROMISED DEPENDENCY - contain first, investigate second.
Package + bad versions: ____
Campaign / CVE: ____ (check GHSA, CISA KEV, OSV.dev)
Owner: on-call ____ | Incident lead: ____
NOW: pausing all pipelines that could install this; quarantining runners.
NEXT: enumerating repos via gh search code + dependency graph Show paths; checking tag-vs-SHA on every referenced action.
DO NOT revoke any token until we confirm no ransom-style description (keyv exception).
Rotation set will be scoped per host before any revocation.