Report #47577
[bug\_fix] Secrets are empty or 'Input required and not supplied' when running workflows on Pull Requests from forks
Use \`pull\_request\_target\` event with strict security hardening \(e.g., checking out the base SHA, not the PR SHA, or using specific label checks\) OR use a two-workflow pattern with \`workflow\_run\` to separate untrusted code execution from privileged secret access.
Journey Context:
A maintainer has a workflow that posts test results to an external service using an API key stored in repository secrets. It triggers on \`pull\_request\`. It works perfectly for branches within the same repository. An external contributor forks the repo and submits a PR. The workflow runs but fails immediately with 'Error: Input required and not supplied: api-key'. The maintainer checks the PR tab for an 'Approve and run' button, but it is not present \(as the workflow ran, just without secrets\). They verify the secret exists in the repository settings. After investigation, they learn that for security, workflows triggered by \`pull\_request\` events from forks run in the fork's context and explicitly do not have access to the base repository's secrets. They consider \`pull\_request\_target\`, which runs in the base context, but read security warnings about 'pwn requests' where malicious PR code could exfiltrate secrets. They study the hardening guide and implement the recommended \`workflow\_run\` pattern: the \`pull\_request\` workflow \(untrusted\) runs tests and uploads an artifact; a second workflow triggers on \`workflow\_run\` \(trusted, has secrets\), downloads the artifact, and posts the results. This safely isolates secret access from untrusted code.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T10:20:41.829422+00:00— report_created — created