The Dangerous-Workflow check in OpenSSF Scorecard looks for GitHub Actions patterns that let untrusted input run with trusted permissions. It is rated Critical. Fix it by never checking out pull request code under pull_request_target or workflow_run, and by keeping untrusted values out of script contexts.
What the check tests
According to the Scorecard checks documentation, the check flags workflows that:
- Check out untrusted pull request code in a workflow triggered by pull_request_target or workflow_run.
- Inject untrusted context values into scripts.
The risk level is Critical, the top of the four levels Scorecard uses, so a failure drags the aggregate score down hard.
Why those patterns are dangerous
Workflows triggered by pull_request_target run in the context of the base repository. That context can carry access to secrets and a more privileged token than a fork pull request normally gets, so check GitHub's own Actions documentation for the exact rules. If the same workflow then checks out and runs code from the pull request, the author of the pull request is effectively running code with those privileges.
The second pattern is injection. Values such as a pull request title or branch name are controlled by whoever opens the pull request. If a workflow pastes one into a shell step, a crafted value can become a command.
How to fix the first pattern
You have three options, from safest to most involved.
- Use pull_request instead. It is the usual safer default for tests and linting, because it does not run in the privileged base repository context.
- Split the workflow. Run untrusted code in a pull_request workflow that uploads results as an artifact, then use a separate privileged workflow that only reads that artifact as data and never executes it.
- Do not check out the pull request head in a privileged workflow. If you only need labels or comments, you rarely need the code at all.
How to fix the second pattern
Do not interpolate untrusted values directly into a run step. Pass them through an environment variable and reference the variable in the script. The shell then treats the value as data instead of code.
steps:
- name: Print title safely
env:
PR_TITLE: ${{ github.event.pull_request.title }}
run: echo "$PR_TITLE"
Related hardening
Pair this with the Token-Permissions check, which wants top level workflow permissions set to read-only with write access granted per job. A workflow that is later found to be injectable then has far less to steal.
Verify any change by rerunning the Scorecard CLI with the show-details option and confirming the check passes. Safeguard policies and gates can also block pull requests that introduce risky workflow files, if you want a second layer.
Quick check
Is pull_request_target always wrong?
No. It is flagged when combined with checking out untrusted pull request code. Used for labeling or commenting without running that code, it can be fine.
Sources
Last reviewed: 19 October 2026.
