Refuse pull_request_target invocations in every reusable workflow

[TomHennen]

Summary

Closes #202. Defense-in-depth against the "pwn request" pattern that compromised TanStack/router via Mini Shai-Hulud in May 2026.

Every reusable workflow in .github/workflows/ now declares a guard job at the head of jobs:. The guard fails fast when the calling workflow's trigger is pull_request_target (or workflow_run triggered by pull_request_target). Every other job in each workflow now lists guard in its needs: array, so a refused invocation skips the entire workflow — no OIDC tokens minted, no privileged actions executed, no docker push, no provenance generation.

No legitimate wrangle adoption uses pull_request_target. The guard costs nothing for correctly-configured callers (a sub-second job) and closes a class of adopter-side misconfigurations.

Files touched

• .github/workflows/build_and_publish_npm.yml
• .github/workflows/build_and_publish_python.yml
• .github/workflows/build_and_publish_container.yml
• .github/workflows/build_shell.yml
• .github/workflows/check_source_change.yml
• test/test_refuse_pull_request_target.bats (new)

Guard step design

guard:
  runs-on: ubuntu-latest
  permissions: {}    # reads env only — no workspace, no API, no secrets
  steps:
    - name: Refuse pull_request_target invocations
      shell: bash
      env:
        EVENT_NAME: ${{ github.event_name }}
        OUTER_EVENT: ${{ github.event.workflow_run.event }}
      run: |
        set -euo pipefail
        fail() { ... }
        if [[ "$EVENT_NAME" == "pull_request_target" ]]; then
            fail "pull_request_target invocations"
        fi
        if [[ "$EVENT_NAME" == "workflow_run" && "$OUTER_EVENT" == "pull_request_target" ]]; then
            fail "workflow_run invocations triggered by pull_request_target"
        fi

Security review

• permissions: {} — guard reads only env vars. No workspace, no API access, no secrets, no checkout. The least privileged step in the workflow.
• No ${{ }} interpolation into the script body. github.event_name and github.event.workflow_run.event are passed via the step's env: block as EVENT_NAME and OUTER_EVENT, then referenced as "$EVENT_NAME" / "$OUTER_EVENT". This protects against shell injection if either value ever contains quote characters (currently it can't — GitHub validates event_name strictly — but the env-pass pattern is the wrangle convention everywhere else in the codebase, so let's match it).
• First job in jobs: in every workflow. The bats test enforces this, so a future refactor can't accidentally move the guard below a job that side-effects (build: runs docker push mid-composite, for example).
• Workflow-startup blocking. GitHub validates a called reusable workflow's permissions at workflow startup regardless of if:. The guard sits in the calling reusable workflow, not in a nested call, so its startup is unconditional. The provenance generator (the most sensitive nested call) gates on gate.outputs.should-release AND needs: [guard, ...], so it can't run if guard fails.
• Container workflow's docker push. The container build's docker push happens mid-composite in build/actions/container. The build: job now needs: [guard], so on a refused invocation, the runner never reaches the push step. This closes the worst-case gap for the build type that has a non-rollback-able privileged side effect.

What this doesn't catch

• Compromised adopter who can edit wrangle. This is defense against adopter misconfiguration, not against an attacker who already has commit access to wrangle's main.
• Caller workflows that do with: ref: ${{ github.event.pull_request.head.sha }} from a non-pull_request_target trigger. zizmor's domain (the "untrusted checkout" finding). Wrangle's source-scan composite already runs zizmor.
• Indirect-via-workflow_dispatch. If an attacker triggers an adopter's workflow_dispatch from a workflow that was itself triggered by pull_request_target, GitHub flattens the event chain to workflow_dispatch and the guard sees only that. Out of scope; the workflow_run check is the most-common indirect vector.

Test plan

• bats: test/test_refuse_pull_request_target.bats runs and passes. 7 structural assertions × 5 workflows = 35 checks. I validated the awk/grep logic locally before pushing.
• zizmor / actionlint: should be clean — no new actions, no new permissions widening, no expression injection.
• Reviewer: confirm the env-pass-instead-of-interpolate pattern matches wrangle's existing convention. I matched the python id: names step's pattern.
• Reviewer: gut-check the "First job is guard" invariant. If you'd prefer a pwn_request_guard action under actions/ (mirroring release_gate's shape) instead of inline bash, say so and I'll convert it — the issue's proposed implementation was inline, so I matched that.

Related

• Closes Refuse pull_request_target invocations in every reusable workflow #202
• The error message points adopters at docs/SPEC.md threat model. docs/SPEC.md already has a "Threat Model" section (tool-binary integrity scope); a follow-up doc PR could add a "Trigger model" subsection that the error directly cites. Not done here to keep the PR focused.

https://claude.ai/code/session_01AqkojrFQsx5CgHGndN96E2

---

Generated by Claude Code

[TomHennen]

I bet we do this same thing everywhere and want to use it everywhere, can it be put into some common thing (like an action all these workflows call)?

Maybe something with a somewhat more generic name there might be other things we want to check in the future?