Skip to main content

What the check does

Fires when all of the following are true:
  1. The workflow triggers on pull_request_target.
  2. A job has an actions/cache@… step.
  3. That step’s key: (or restore-keys:) interpolates a PR-controlled context: github.head_ref, github.event.pull_request.head.{ref,sha,label}, or github.event.pull_request.{title,body,number}.

Why it matters

pull_request_target runs in the base branch’s privileged context with repository secrets and write tokens. If the cache key is derived from data the attacker controls (a PR’s head ref, title, etc.), the attacker can plant a cache entry that subsequent trusted base-branch builds will restore — letting them inject arbitrary files into the build, violating SLSA Build L3’s isolation guarantee.

Vulnerable example

Safe alternatives