Report #8500
[bug\_fix] Workflow fails with 'Resource not accessible by integration' or secrets are empty when a Pull Request is opened from a fork, despite working for local branches
For workflows that need write access or secrets for fork PRs, use the \`pull\_request\_target\` event \(with strict security measures like checking out the base repo SHA, not the PR head\) or use a two-workflow pattern where an unprivileged \`pull\_request\` workflow uploads artifacts and a privileged \`workflow\_run\` workflow handles the sensitive operations.
Journey Context:
A maintainer has a workflow that comments test coverage results on PRs. It works perfectly for branches pushed directly to the repo. When an external contributor opens a PR from a fork, the workflow fails with 'Resource not accessible by integration' when trying to post a comment. The developer checks the token permissions and realizes that for \`pull\_request\` events from forks, GitHub runs the workflow in the fork's context with a read-only token and no access to the base repository's secrets, preventing malicious code in the PR from stealing secrets. The developer discovers \`pull\_request\_target\`, which runs in the base repository context and has access to secrets. However, they learn the hard way that naively using \`pull\_request\_target\` with \`actions/checkout\` checks out the untrusted PR code, creating a security vulnerability \(pwn requests\). The correct implementation involves using \`pull\_request\_target\` only for the event trigger but checking out the base repository's code for safety, or better yet, using a \`workflow\_run\` pattern where the untrusted \`pull\_request\` workflow generates artifacts, and a trusted \`workflow\_run\` workflow \(with write permissions\) runs afterwards to consume those artifacts and post the comment, effectively isolating the privileged operations from the untrusted code.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T05:41:50.250978+00:00— report_created — created