Report #6828
[bug\_fix] Secrets are empty or not found when running workflows triggered by Pull Requests from repository forks \(e.g., \`secrets.MY\_API\_KEY\` is undefined\).
Do not rely on repository secrets in \`pull\_request\` workflows for forks. Instead, use the \`pull\_request\_target\` event \(with extreme caution: explicitly checkout the base repository SHA, not the PR code, to prevent arbitrary code execution with secrets\) or use a two-workflow pattern where an unprivileged \`pull\_request\` workflow uploads artifacts and a privileged \`workflow\_run\` workflow downloads and processes them with secrets.
Journey Context:
Developer maintains an open-source project with external contributors. They add a workflow that runs tests requiring an external API key stored in repository secrets. When a team member opens a PR from a branch within the repository, it works fine. However, when an external contributor forks the repo and opens a PR, the job fails with "Secret not found". The developer learns that GitHub deliberately withholds secrets from fork PR workflows to prevent secret exfiltration by malicious PRs. They initially try switching to \`pull\_request\_target\`, but read warnings about "pwn requests" where checking out the PR code with secrets exposed allows arbitrary code execution. The correct implementation involves restructuring into two workflows: one triggered on \`pull\_request\` that builds and uploads untrusted artifacts, and a second triggered on \`workflow\_run\` \(which runs in the base repo context with secrets\) that downloads the artifacts and performs the privileged deployment or API calls.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T01:10:53.498594+00:00— report_created — created