GitHub Actions Cache Poisoning:
CI/CD Security Guide 2026

Introduction

In May 2026, the TanStack ecosystem was compromised through a sophisticated attack that combined two vulnerabilities: a pull_request_target Pwn Request and GitHub Actions cache poisoning. The attacker published 84 malicious npm package versions without ever stealing npm credentials — they exploited GitHub Actions' own caching mechanism and an OIDC trust relationship to publish as an authorized maintainer.

This was not an isolated incident. The Mini Shai-Hulud worm campaign (April–May 2026) used similar cache poisoning techniques to compromise over 170 npm and PyPI packages. The Grafana Labs breach also exploited the Pwn Request vector. GitHub's own 2026 Actions security roadmap directly acknowledges cache poisoning as a critical threat requiring new platform-level protections.

But platform-level protections are months away. Right now, the security of your CI/CD pipeline depends on your workflow configurations. This guide covers how cache poisoning works, how the TanStack attack unfolded in detail, and — most importantly — how to audit and harden your own GitHub Actions workflows.

How GitHub Actions Caching Works

GitHub Actions provides a built-in caching mechanism through the actions/cache action. It lets workflows save and restore directories (like node_modules, ~/.cache/pip, or .next/cache) across workflow runs to avoid re-downloading dependencies.

Cache Key Structure

Each cache entry is identified by a key, typically composed of runner OS, dependency hash, and the branch name. The key determines which cache is restored:

actions/cache@v4
  with:
    path: ~/.npm
    key: ${{ runner.os }}-npm-${{ hashFiles('**/package-lock.json') }}
    restore-keys: |
      ${{ runner.os }}-npm-

The Trust Model Problem

Here's the critical detail: cache scopes are determined by branch hierarchy. Feature branches created off main can access caches from main. This means if a workflow running in a fork's PR context writes to a cache that the base branch can restore, the cache entry becomes a cross-trust-boundary weapon.

The actions/cache action, by default, writes cache entries scoped to the branch where the workflow runs. But the restore-keys fallback logic can pull cache entries from parent branches — including main. When an attacker controls what gets cached from a fork PR workflow, they can poison the cache that the base branch's release workflow will restore.

The Cache Poisoning Attack Mechanism

The attack requires three ingredients to succeed:

1. A misconfigured trigger — A pull_request_target workflow that checks out and executes code from the forked PR.
2. Cache write access to a shared scope — The workflow caches files (e.g., node_modules, pnpm store) using actions/cache with keys that overlap with the default branch.
3. A privileged consumer — A release or deployment workflow that restores the poisoned cache and executes its contents.

Step 1: The Pwn Request

The attacker submits a pull request to a public repository from a fork. The repository has a workflow triggered by pull_request_target that checks out the PR head and runs scripts from it. Because pull_request_target runs in the context of the base repository, the workflow has access to GITHUB_TOKEN, secrets, and the cache API.

# Simplified attack workflow
name: PR Check
on:
  pull_request_target:
    types: [opened, synchronize]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          ref: ${{ github.event.pull_request.head.sha }}
      
      - uses: actions/setup-node@v4
      
      # Attacker-controlled: npm install fetches malicious deps
      - run: npm ci
      
      # Cache upload with base-branch scope
      - uses: actions/cache@v4
        with:
          path: node_modules
          key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }}

Step 2: Cache Cross-Contamination

Once the malicious cache entry exists in the base branch's scope, any workflow that uses actions/cache with overlapping restore keys can pull the poisoned data. The release workflow — which typically has contents: write, id-token: write, and access to npm/publishing secrets — becomes the victim.

Step 3: OIDC Token Extraction

In the TanStack attack specifically, the cache poisoning was the entry point. Once the poisoned dependencies were restored in the release workflow, the attacker's code could inspect the runner's process memory space. GitHub Actions runners expose environment variables and process information to the running workflow, including:

• ACTIONS_ID_TOKEN_REQUEST_TOKEN — A token that can be exchanged for an OIDC JWT (if id-token: write is set).
• ACTIONS_ID_TOKEN_REQUEST_URL — The endpoint to exchange the request token for an OIDC token.
• Environment variables — Including GITHUB_TOKEN, secrets, and other sensitive configuration.

Case Study: The TanStack Attack Timeline

The TanStack postmortem provides a minute-by-minute account of the attack.

Pre-Attack Phase (Cache Poisoning)

• 2026-05-10 17:16 UTC — Attacker creates a fork of TanStack Router/Start.
• 17:19–17:43 — Two PRs with malicious CI modifications targeting pull_request_target.
• 17:19 — First PR poisons the pnpm store cache on the base branch.
• 17:43 — Second PR ensures the poisoned cache is stored.

Trigger Phase (OIDC Extraction)

• 2026-05-10 17:46 UTC — Dependabot/legitimate PR triggers the workflow with poisoned cache.
• 17:46–18:07 — Attacker code calls OIDC endpoint, extracts JWT, exchanges for AWS credentials.
• 18:07 UTC — AWS role assumed with npm publishing permissions for @tanstack/*.

Distribution Phase (npm Publishing)

• 2026-05-11 19:20–19:26 UTC — 84 malicious versions across 42 @tanstack/* packages published.
• 19:26 UTC — Packages include worm with dead man's switch and credential harvesting.

Detection & Response

• 19:46 UTC — StepSecurity detects suspicious npm publishing.
• 19:52 UTC — TanStack team begins response: deprecating versions, revoking AWS OIDC, rotating credentials.
• 20:12 UTC — npm Security removes malicious packages.

GitHub Actions Security Hardening Checklist

Critical — Do These First

Secure Defaults

FAQ

Need Help Securing Your CI/CD Pipeline?

I provide CI/CD security consultation as part of my web development services. Let's discuss your project.