workflow-run-deploy-gate-fork-pr-ref-name-escalation

Gate on the triggering run's origin, not just its branch name: require workflow_run.event == 'push' and workflow_run.head_repository.full_name == github.repository in addition to conclusion == 'success' and head_branch == 'main'. This ensures only CI runs from pushes on your own repo trigger the deploy.

head_branch is the unqualified ref name, and a fork's default branch is also named main. A fork PR's CI run can complete successfully with head_branch == 'main', causing the privileged upstream workflow_run deploy job to build and ship the attacker's head_sha.

The fork's CI job on pull_request cannot access secrets or OIDC, but the deploy is a separate workflow_run job that always runs in the privileged upstream context regardless of the triggering run's origin. That separation is what makes the gate exploitable.

On a private repo the attack is unreachable today because forks cannot run CI without write access. The one-line fix is still recommended because it future-proofs the workflow against a private-to-public visibility flip.

Confirm a fork PR or pull_request CI run leaves the deploy job skipped, while a real merge to main with a successful push-event CI run creates the workflow_run run and executes the deploy. A dispatch or cancelled-run success does not prove the gated path works.

Yes, any privileged workflow_run-triggered job is affected, including publish, release, signing, image push, and infrastructure apply with cloud CLIs. The same origin checks on event and head_repository apply to all of them.