By default, no. GitHub does not pass secrets to workflows triggered from a forked repository, apart from a read-only GITHUB_TOKEN. The danger comes from triggers and settings that run in the base repository's context, mainly pull_request_target and workflow_run, when they check out untrusted code.
The default behaviour
GitHub's documentation on secrets says that, with the exception of the GITHUB_TOKEN, secrets are not passed to the runner when a workflow is triggered from a forked repository. Secrets are also not available to workflows triggered by Dependabot events.
For pull requests from forks, the ordinary pull_request trigger therefore runs your tests without credentials. That is the safe path, and it is why most test and lint workflows should use it.
Where the exceptions come from
| Trigger or setting | Why it is riskier |
|---|---|
| pull_request_target | Runs in the context of the base branch, so it can have secrets and write access |
| workflow_run | Privileged, shares the main branch cache, may use artifacts from other runs |
| Private repo setting: send secrets to workflows from pull requests | Makes all secrets available to the pull request |
| Private repo setting: send write tokens | Gives fork pull requests a write capable token |
GitHub's secure use reference says plainly that pull_request_target and workflow_run, combined with checking out an untrusted pull request, expose the repository to compromise, and that such vulnerabilities can be used to take over a repository. Its good practice list is short: avoid these triggers unless the workflow needs the privileged context, and never explicitly check out untrusted code in them.
A quick audit in four steps
- Search your workflow files for
pull_request_targetandworkflow_run. Each hit needs a reason. - For each hit, look for a checkout of the pull request head. If you find one, the workflow runs outside code with your privileges. Redesign it.
- In repository settings, look at the fork pull request options. If your private repository is allowed to send secrets or write tokens to fork pull requests, ask who needs that.
- Treat artifacts from earlier workflow runs as untrusted input. GitHub specifically advises caution with artifacts consumed by workflow_run.
A safer pattern
Split the work. Let an unprivileged pull_request workflow build and test the change, then upload results as an artifact. A second privileged workflow reads only data it validates, such as a pull request number, and does the labelling or commenting. It never executes code from the artifact.
Also review approval settings. For public repositories, GitHub requires approval for first-time contributors by default, and you can require approval for all outside contributors. The docs add that pull_request_target workflows always run, because the base branch is considered trusted, so approval settings do not cover them.
What this does not protect against
Secrets withheld from forks do not help when a trusted contributor's branch is compromised, or when a malicious dependency runs during install. Limit what each secret can do, and keep deploy credentials in environments that need review.
Where Safeguard fits
Safeguard's dependency scanning and policy gates look at what a pull request changes in your dependency tree, which is a different layer from trigger design. Use both.
Quick check
Does pull_request_target ever make sense?
Yes, for tasks like labelling or commenting on fork pull requests, as long as it never checks out or runs the fork's code.
Is the read-only token on fork pull requests harmless?
It is limited, but it is still a credential. Keep permissions minimal and avoid running untrusted scripts that could misuse it.
Sources
- Using secrets in GitHub Actions, GitHub Docs
- Secure use reference, GitHub Docs
- Managing GitHub Actions settings for a repository, GitHub Docs
Last reviewed: 19 October 2026.
