Report #57799
[bug\_fix] Secrets are empty or undefined in workflows triggered by pull requests from forks, resulting in API authentication failures or 'Input required and not supplied: token' errors
Change the workflow trigger from \`pull\_request\` to \`pull\_request\_target\` \(ensuring the checkout action explicitly checks out the base ref or uses the head SHA with careful security consideration\) or use a \`workflow\_run\` trigger that runs after the initial workflow and has access to secrets in the base repository context.
Journey Context:
An external contributor opens a pull request from their fork to fix a bug. The maintainer sees that the CI workflow fails immediately with a credentials error when trying to post a comment or deploy a preview environment. The maintainer checks the workflow file and sees it references \`$\{\{ secrets.DEPLOY\_TOKEN \}\}\`. They verify the secret exists in the repository settings. They re-run the job and it fails again. They examine the event type and realize it's a \`pull\_request\` event from a fork. They read the documentation and discover that GitHub explicitly does not pass secrets to workflows triggered by pull requests from forks to prevent malicious exfiltration of secrets via \`printenv\` or exfiltration to external servers. They consider changing to \`pull\_request\_target\` but read security warnings about executing untrusted code in the base repository context. They implement a two-workflow pattern: the first workflow triggered by \`pull\_request\` that runs the untrusted tests and uploads artifacts, and a second workflow triggered by \`workflow\_run\` that runs in the base context with access to secrets to handle deployment or commenting, carefully checking the artifact integrity.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-20T03:30:12.903980+00:00— report_created — created