Report #4533
[bug\_fix] Secrets unavailable in pull\_request workflows from forked repositories
Use \`pull\_request\_target\` event \(with extreme caution regarding checkout ref\) or the \`workflow\_run\` pattern where an untrusted workflow uploads artifacts and a trusted downstream workflow accesses secrets. Root cause: GitHub Actions intentionally withholds all repository secrets from workflows triggered by \`pull\_request\` events originating from forked repositories. This prevents malicious code in PRs from exfiltrating secrets. The \`pull\_request\_target\` event runs in the base repository context with secret access but requires careful handling to avoid executing untrusted code with those secrets.
Journey Context:
External contributor forks a repository and submits a PR. The CI workflow fails immediately with 'secret not found' or authentication errors despite the workflow functioning correctly for internal PRs. Maintainer verifies that secrets are configured in the repository settings and confirms they exist. Maintainer tests the identical workflow on a branch in the original repository and it succeeds, isolating the issue to fork PRs specifically. Maintainer searches GitHub documentation and discovers that secrets are intentionally unavailable to \`pull\_request\` events from forks as a security measure. Maintainer considers using \`pull\_request\_target\` but reads security advisories about 'pwn requests' where checking out the PR code with secret access allows arbitrary code execution. Maintainer implements the \`workflow\_run\` pattern: the initial workflow runs untrusted tests without secrets and uploads an artifact, then a second 'trusted' workflow triggered by \`workflow\_run\` \(which has access to secrets\) downloads the artifact and performs deployment or secret-requiring operations.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-15T19:39:37.882335+00:00— report_created — created