In this article
Build systems remain an attractive target because a compromised runner can inherit the permissions and secrets available to the job. In May 2026, the TanStack project reported that an attacker used a GitHub Actions workflow and cache-poisoning path to publish 84 malicious versions across 42 packages. The maintainers said no npm credentials were stolen and later confirmed the affected versions were removed. Separate reports described other npm supply-chain activity that month. The incidents differ, but both make pipeline permissions and dependency execution current security priorities.
The TanStack Attack: When Your CI Pipeline Trusts the Wrong Thing
On May 11, 2026, an attacker abused a GitHub Actions workflow in the TanStack Router repository. TanStack’s postmortem says the chain involved a pull_request_target workflow, cache poisoning across the fork and base boundary, and extraction of an OIDC token from the runner process. The token enabled publication of malicious package versions. The maintainers report no npm publishing tokens were stolen. This incident shows why workflow context and short-lived cloud identities still need strict permissions and isolation.
The malicious packages executed during installation and attempted to collect credentials available on the affected host. TanStack’s postmortem says the attacker did not steal npm tokens; the attack instead abused workflow context and an OIDC token from a GitHub Actions runner. The project reported 42 affected packages and 84 versions, later deprecated and removed. Anyone who installed an affected version should use the project’s current incident guidance to assess and rotate credentials that were reachable from that environment.
Mini Shai-Hulud: A Separate npm Campaign
Separate research published in May described a second npm campaign involving typosquatted packages. Keep its attribution, scope, and indicators distinct from the TanStack incident.
A package compromise can affect organizations that consume dependencies even if they never publish packages themselves. Build jobs often have access to source code, cloud identities, and deployment secrets. Limit each job’s permissions and make install-time execution and outbound behavior observable.
The Common Thread
The shared lesson is implicit trust. A workflow can use legitimate identities and produce artifacts that carry valid provenance while its inputs or runner context have been compromised. Provenance helps answer where and how an artifact was built; it does not by itself prove that every input and build step was safe.
Why This Matters Beyond Developers
It's tempting to file this under “a problem for open-source maintainers.” It isn't. Every organization that runs npm install, pip install, or their equivalent as part of a build is a consumer of this same trust chain, whether or not they publish a single package themselves. A compromised transitive dependency executes with your build system's privileges — which, as May demonstrated, often extends to your cloud credentials, your secrets manager, and your source control tokens. The blast radius of a single bad dependency is frequently the same as the blast radius of your entire CI/CD environment.
What Security Testing Would Catch
Each stage of both attacks maps to a testing discipline that's still treated as optional at too many organizations:
- CI/CD pipeline security review. Auditing workflow configurations for risky trigger patterns like pull_request_target, reviewing what permissions and token scopes are handed to runners, and checking whether a forked pull request can influence a privileged build step are all things a dedicated pipeline assessment is built to find — and a conventional web app pentest never touches.
- Software composition and dependency review. Typosquatted package names, unpinned version ranges, and unverified lockfile integrity are detectable before install, not just after a breach.
- Secrets and blast-radius assessment. A compromised build runner should never have simultaneous reach into AWS, Vault, npm publishing, and GitHub in one credential set. Segmenting what a single compromised job can access limits exactly this kind of cascading failure.
- Build-system red teaming. Treating the pipeline itself as a target — attempting to poison a cache, escalate a fork's permissions, or exfiltrate a runner's token — surfaces these gaps under realistic conditions rather than waiting for a real attacker to demonstrate them.
What This Means for Your Organization
- Treat your CI/CD pipeline as a production system, not internal tooling. It holds the same credentials and blast radius as anything you'd normally scope into a security assessment — scope it in.
- Audit workflow permissions and trigger types. pull_request_target and similar high-privilege triggers should be reviewed specifically for whether external, untrusted input can influence a privileged step.
- Pin dependencies and verify provenance, not just version ranges. A signed package is only as trustworthy as the identity that signed it — and that identity can be stolen.
- Segment secrets by job and need. No single compromised runner should be able to reach your cloud provider, secrets vault, source control, and package registry all at once.
- Don't rely on signatures alone. Behavioral monitoring for unusual publish activity, unexpected outbound connections during install, and anomalous runner behavior catches what cryptographic provenance, by itself, cannot.
The 2026 incidents make the build pipeline part of the production attack surface. Review workflow triggers and token permissions, isolate secrets by job, pin and verify dependencies, and alert on unexpected package publishing or install-time network activity. Reassess these controls when repositories, runners, actions, or release processes change.
Sources and further reading
TanStack postmortem on the npm supply-chain compromise
Cloud Security Alliance research note on May 2026 npm attacks