TanStack Reveals Novel Supply Chain Attack Using GitHub Actions Cache Poisoning and OIDC Token Theft

Executive Summary

On May 11, 2026, the TanStack open-source project was the target of a brief but highly sophisticated supply chain attack that resulted in the malicious modification of 42 popular npm packages. The attackers demonstrated a deep understanding of modern CI/CD practices, bypassing traditional security controls like credential protection. They leveraged a novel chain of exploits involving a malicious pull request, poisoning the GitHub Actions cache, and stealing a short-lived OpenID Connect (OIDC) token from within the build environment to publish malicious package versions. The payload was a potent credential-stealing malware aimed at developer environments. The incident serves as a critical wake-up call about the security of automated CI/CD pipelines and the evolving tactics of supply chain attackers.

Threat Overview

The attack, which occurred between 19:20 and 19:26 UTC, was remarkable for its speed and sophistication. It did not rely on phishing or stealing long-lived API keys. Instead, it manipulated the trusted automation that powers modern software development.

Attack Chain:

1. Initial Access via Pull Request: The attacker submitted a pull request from a forked repository. This PR targeted a GitHub Actions workflow that was insecurely configured with the pull_request_target trigger, allowing code from the fork to run with elevated permissions. (T1195.001 - Compromise Software Development Tools)
2. Cache Poisoning: The malicious script in the PR executed within the trusted context and wrote a malicious payload to the shared GitHub Actions cache. This cache is used to speed up subsequent builds.
3. Triggering the Payload: A legitimate TanStack maintainer, unaware of the poisoned cache, merged a separate, benign pull request. This action triggered the standard release workflow.
4. Token Theft: The release workflow restored the poisoned cache, which then executed the malicious code. This code ran within the trusted GitHub Actions runner and was able to access the runner's environment to steal the short-lived OIDC token provided by GitHub for passwordless publishing to npm. (T1552.006 - Stored Accounts)
5. Malicious Publication: The stolen OIDC token was immediately used by the attacker to authenticate to npm and publish malicious versions of 42 different TanStack packages. (T1553 - Subvert Trust Controls)

Technical Analysis

The attack's brilliance lies in its abuse of trusted, ephemeral mechanisms. OIDC tokens are designed to be a more secure alternative to static secrets, but this attack shows that if an attacker can gain execution within the CI/CD environment, even for a moment, they can steal and misuse these tokens.

The payload itself was a comprehensive credential harvester designed to compromise developer workstations and CI/CD environments. Its capabilities included stealing:

• Cloud credentials (AWS, GCP)
• Kubernetes tokens
• GitHub tokens
• SSH keys
• npm configurations (.npmrc)

It also contained a self-propagation mechanism, meaning that any developer who installed the malicious package and then worked on their own npm package could inadvertently spread the infection further. The rapid detection by external researchers (within 20 minutes) was crucial in limiting the downstream impact.

This attack demonstrates that CI/CD pipelines are not just build tools; they are high-privilege environments and a primary target for attackers. Securing the pipeline itself is as important as securing the code.

Impact Assessment

The potential impact of this attack was enormous. TanStack tools are used by countless developers and organizations worldwide. A successful, widespread compromise could have led to a catastrophic wave of secondary breaches as developer credentials from thousands of companies were stolen. The payload's ability to steal cloud and Kubernetes credentials means attackers could have gained access to production infrastructure, not just source code. The self-propagation feature could have created a worm-like event within the npm ecosystem. While the quick detection mitigated the worst-case scenario, the incident exposes a systemic risk in the open-source software supply chain.

Detection & Response

• Dependency Monitoring: Use tools like npm audit or third-party Software Composition Analysis (SCA) tools to detect when a malicious or deprecated version of a dependency is being used.
• CI/CD Log Analysis: Monitor CI/CD logs for anomalous behavior, such as unexpected script executions, network connections to unusual domains, or changes in build artifacts. This is an application of D3FEND's Dynamic Analysis.
• OIDC Token Auditing: In GitHub, use audit logs to review OIDC token requests and their associated claims to detect suspicious publishing activity.

Mitigation Recommendations

1. Secure CI/CD Workflows (M1054 - Software Configuration):

   • Avoid pull_request_target: Never use the pull_request_target trigger for workflows that build, test, or publish code. Use pull_request and workflow_run instead, which run code from forks in a properly isolated context.
   • Harden Actions: Pin GitHub Actions to a specific commit hash (uses: actions/checkout@a12a3943b43c672646b4de65223a8ba24118e134) instead of a floating tag (@v3) to prevent upstream compromises.

2. Isolate Build Environments (M1048 - Application Isolation and Sandboxing):

   • Ensure that build steps that handle untrusted code (like from a PR) run in isolated, ephemeral environments with no access to secrets or the shared cache.
   • Protect the release process. Use protected environments in GitHub Actions that require manual approval before a workflow with access to publishing secrets can run.

3. Implement Publishing Safeguards:

   • Token Permissions: Configure your npm OIDC provider in GitHub to be highly specific. Restrict which repositories, branches, and workflows are allowed to request a token for publishing.
   • Provenance: Generate and publish SLSA provenance with your packages. This provides consumers with a verifiable record of how a package was built and published, allowing them to detect packages that were not published through the legitimate CI/CD pipeline.

4. Developer Environment Security:

   • Encourage the use of the npm command-line tool over direct script execution to benefit from its built-in security features. Discourage running arbitrary scripts from dependencies during installation.