By default, no. On GitHub, when a workflow is triggered from a forked repository, secrets are not passed to the runner, with the exception of GITHUB_TOKEN, and that token has read-only permissions in pull requests from forks. The exceptions are triggers you choose to configure, such as pull_request_target.
The short version in a table
| Trigger | Runs workflow code from | Secrets available | Token permissions |
|---|---|---|---|
| pull_request from a fork | The pull request merge ref | No (GITHUB_TOKEN alone) | Read-only |
| pull_request_target | The base branch | Yes | Can be write |
| workflow_run | The default branch | Yes | Can be write |
The first row is the safe default. The second and third rows are privileged triggers, and GitHub's own security guidance warns that using them together with a checkout of untrusted pull request code exposes the repository to compromise.
Why the default is safe
A fork pull request is code from someone you may not know. If that code could read your deploy key, a one-line change to a test script would send it to an attacker. GitHub removes the secrets from the runner for fork pull requests so that a malicious change cannot read them. A first-time contributor's workflows may also wait for a maintainer to approve them before anything runs.
Two related facts help here. Workflows do not run in a forked repository until its owner enables Actions. And Dependabot pull requests are treated as though they come from a fork, so they get the same restrictions.
Where teams lose the protection
The default breaks when someone wants a fork pull request to do something that needs a secret. Typical examples are posting a comment, uploading a scan result to a service, or running an integration test against a cloud account.
The shortcut is to switch the trigger to pull_request_target and check out the pull request head so the tests still run. That combination runs attacker-controlled code with your secrets in reach. Do not do it. The safer options are:
- Run tests on pull_request with no secrets, and accept that integration tests needing credentials run after merge or after a maintainer approval.
- Split the work into two workflows. The first builds and tests with no secrets and uploads results as an artifact. The second, triggered by workflow_run, reads the results alone and does the privileged step. Treat the artifact as untrusted data and never execute it.
- Put credentials in an environment with required reviewers, so a person approves before a job can read them.
A quick audit you can do today
- List every workflow that uses pull_request_target or workflow_run.
- For each, search for a checkout step that names the pull request head ref or SHA. If it exists, treat it as a finding.
- Check that the default GITHUB_TOKEN permission is read-only for repository contents, and raise it per job.
- Look at what secrets exist at repository and organization level, and remove any that no workflow needs.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a gate runs on the pull request itself and decides before merge, with no credentials passed to the contributor's code.
Where Safeguard fits
Safeguard applies policies and gates to pull requests, so a dependency or finding policy is decided on the change itself. You can also run a free scan of a project to see what a gate would flag.
Quick check
Does a fork pull request ever get secrets by default?
No. Apart from GITHUB_TOKEN, which is read-only for fork pull requests, secrets are not passed to the runner.
Is pull_request_target always unsafe?
No. It is safe when the workflow does not check out or run untrusted pull request code. The risk comes from combining it with that checkout.
Do Dependabot pull requests get repository secrets?
They are treated like fork pull requests. GitHub Actions secrets are not available, and Dependabot secrets are used instead.
Sources
Last reviewed: 19 October 2026.
