The fork that runs in your trusted context: how pull_request_target poisoned 172 packages

On May 11, in a six-minute window, a worm now tracked as Mini Shai-Hulud (CVE-2026-45321, CVSS 9.6) published 84 malicious versions across 42 packages in one popular npm namespace. Within forty-eight hours it had spread to 172 packages and 403 malicious versions across npm and PyPI, sweeping up well-known frameworks and several AI tooling libraries on the way. It stole cloud credentials, harvested developer tokens, and in some installs dropped a destructive daemon. The interesting part is not the payload. It is the door. The worm did not exploit a memory bug or a parser flaw. It walked through a single, common, badly understood GitHub Actions configuration: a pull_request_target workflow that checked out and ran code from an untrusted fork inside the base repository's trusted context.

That is a configuration thousands of repositories ship today without a second thought. This is a defender's breakdown of why the pattern is dangerous, how the cache-poisoning chain actually worked, and how you confirm and close the trust boundary in your own pipeline without firing anything.

Why pull_request_target exists, and why it is a trap

GitHub Actions runs most pull-request automation under the pull_request trigger. That trigger is deliberately starved of power: a workflow fired by a fork's pull request gets a read-only token and no access to repository secrets, because the code in that pull request is, by definition, written by someone you do not trust. This is the safe default and it works.

The friction is that some legitimate automation genuinely needs secrets while still reacting to a fork's pull request. Labeling a contribution, posting a coverage comment, or running a deploy preview all want a real token. To serve that case, GitHub added pull_request_target. The crucial and frequently-missed difference is the context it runs in. A pull_request_target workflow executes with the configuration and the secrets of the base repository, the trusted side, while the pull request that triggered it still comes from an untrusted fork.

That split is fine as long as the workflow never executes the fork's code. The moment a pull_request_target workflow does an explicit checkout of the pull-request head and then runs a build, a test, or a setup script from that checkout, the untrusted code is now running with the trusted side's token and secrets. The contributor you do not trust is executing inside your privileged pipeline. GitHub's own documentation warns about this in bold. The warning is widely ignored because the dangerous line, a checkout of github.event.pull_request.head.sha, looks completely ordinary.

The chain: from a renamed fork to a poisoned cache

CVE-2026-45321 is the chaining of three weaknesses in one project's CI configuration, and the structure generalizes. Walk the steps the way the worm did.

First, the attacker created a fork of the target repository under a renamed account so the pull request would not look like it came from an obviously hostile source. Forks are public and cheap, and a renamed account defeats the lazy heuristic of "block known-bad usernames."

Second, the attacker opened a pull request that triggered the project's pull_request_target workflow. Because that workflow checked out and ran the fork's code, the attacker's script now executed in the base repository's trusted context with whatever the runner could reach: the workflow token, environment secrets, and the shared Actions cache.

Third, and this is the elegant part, the attacker did not need to exfiltrate a publishing token directly. The workflow poisoned the GitHub Actions cache with malicious binaries. The Actions cache is keyed and scoped, but a write from a privileged run on a feature branch can land entries that a later trusted build, the one that actually publishes the package, will restore and use. The legitimate release pipeline then pulled poisoned artifacts out of its own cache and shipped them under a valid name with valid provenance. Downstream installs trusted the signature because the signature was real. The compromise happened upstream of the signature.

The worm closed the loop by using the credentials it harvested on each newly-infected build to authenticate to npm and publish the next round of poisoned packages, which is what turned a single bad pull request into a self-propagating event across two ecosystems.

Who is exposed

Two populations are exposed, and most organizations are in both.

You are exposed as a producer if you maintain any public repository with a pull_request_target workflow that checks out and runs pull-request code. That is the door the worm used. It does not matter how popular the package is; the worm spreads opportunistically.

You are exposed as a consumer if your build pulls dependencies from npm or PyPI without pinning to exact, verified versions, because a poisoned release published under a trusted name with valid provenance will install cleanly. "Just update to the latest" is exactly the wrong reflex during an active worm, because the latest version may be the malicious one. Provenance attestation did not save anyone here, because the artifact was poisoned before it was signed.

How to confirm your exposure, evidence-first

You can determine producer-side exposure entirely from served, public artifacts. Read your own workflow files. The finding is the intersection of three facts, and a scanner that alerts on the trigger name alone is manufacturing noise.

# Passive: which workflows use the dangerous trigger AND check out PR code?
# Read-only inspection of files you already published.
grep -rl "pull_request_target" .github/workflows/
# For each hit, the finding is real only if the workflow ALSO does:
#   - actions/checkout with ref: ${{ github.event.pull_request.head.sha }}
#   - and then runs build/test/setup steps from that checkout
grep -rEn "head\.(sha|ref)|pull_request\.head" .github/workflows/

A pull_request_target workflow that never checks out the head, or that only reads the pull-request metadata, is a PASS. The dangerous combination is the trigger plus an explicit head checkout plus execution. Confirm all three before you call it a finding.

For consumer-side exposure, the check is whether your lockfile pins exact versions and whether any installed version falls inside a known-compromised range. This too is passive: it reads your lockfile and your dependency tree, runs nothing.

# Passive: is any installed package version in a compromised band?
# Cross-reference the lockfile against the published advisory ranges.
npm ls --all --json 2>/dev/null | 
pip freeze | 
# FINDING posture: an installed version inside a published malicious range,
# OR a floating range that could resolve to one on the next install.

How we validate it, and why the validation is the product

We track this as a CI-trust-boundary scenario, not a single-CVE check. The catalog entry reads a customer's public workflow files, identifies pull_request_target workflows that execute fork-supplied code, and separately cross-references the dependency manifest against the compromised-package lists from this campaign and its siblings. When a public workflow runs untrusted code in the trusted context, we mint a Proof Capsule that names the exact workflow file, the offending checkout line, and the privilege it exposes, with the remediation attached. When the workflow guards itself, or there is no head checkout, we record a PASS and raise nothing, because a configuration that holds the boundary is not a finding. Anyone can grep for a trigger string. The value is proving, with evidence, whether the boundary actually holds.

How to fix it, in priority order

1. Stop running fork code in the trusted context. If a workflow uses pull_request_target, it must not check out and execute the pull-request head. Move build-and-test of untrusted contributions to a plain pull_request workflow that has no secrets and a read-only token.
2. Split the work. Use the privileged pull_request_target job only for the narrow trusted action (label, comment, gate) and run untrusted code in a separate unprivileged job. Never let secrets and fork code touch the same runner.
3. Require approval to run workflows on fork pull requests. Set the repository to require a maintainer's explicit approval before any workflow runs on a contribution from a first-time or outside contributor.
4. Scope and distrust the Actions cache. Treat cache entries as untrusted input to the publish pipeline. Do not let a feature-branch run write cache that a release run will restore. Pin and verify build inputs at publish time.
5. Pin dependencies to exact, attested versions and review the diff on every bump. A floating range is a standing invitation to install whatever got published last, including a worm's output. During an active campaign, freeze rather than chase the latest.

What this class says about the next year of supply-chain bugs

The pattern that drove Mini Shai-Hulud is not exotic and it is not going away, because the trust mistake is structural. We give continuous-integration runners real authority, then we let them execute code we did not write, and we assume a valid signature at the end of the line means the artifact upstream was clean. It does not. The defensible posture is to treat the pipeline itself as an attack surface and to keep the trust boundary between authored-by-us and authored-by-a-stranger sharp at every stage, especially the stage where a fork's pull request meets your secrets. The fix is not a scanner that watches the registry after the fact. It is a build that never let the stranger's code touch the trusted token in the first place. We test that boundary by reading the workflow, every week, and we prove which pipelines actually hold it, with the offending line and the fix attached.