Topic starter
11/11/2026 6:00 pm
TL;DR: 48 repositories were confirmed exploitable in Plerion's static and hands-on validation of pull_request_target workflows, with 34 lacking guards and 42 workflows pwned in the test set. CI/CD governance has to treat workflow triggers, checkout refs and token scope as security controls, not implementation details.
Editorial analysis by NHI Mgmt Group, based on content published by Plerion: “Pwn request: scanning GitHub for the vulnerability that took down Trivy”.
Key questions
Q: Why does a forked pull request become dangerous in GitHub Actions?
A: A forked pull request becomes dangerous because the workflow runs with the base repository's context, which can include secrets, write-scoped tokens, and permissions that the attacker-controlled fork should never see.
Q: What is the difference between pull_request and pull_request_target in CI/CD security?
A: pull_request runs workflow logic in the context of a pull request and is generally safer for untrusted contributions.
Q: How do you secure pull_request_target workflows against forked PR abuse?
A: Treat pull_request_target as a privileged automation path and never check out untrusted fork code before secrets, write tokens, or approvals are needed.
Practitioner guidance
- Audit privileged PR workflows for unsafe checkout refs Search for pull_request_target, then confirm whether any job checks out PR head content or executes contributor-controlled scripts before merge.
- Restrict workflow permissions to the minimum viable scope Set permissions: {} by default, then grant only the exact token rights a workflow needs for labels, comments or release steps.
- Split trusted and untrusted pipeline stages Move build and test execution into an unprivileged first stage, then trigger a second trusted stage only after the code path is validated.
Bottom line: The core failure was a trust-boundary collapse in CI, where a privileged workflow could execute forked code under repository credentials.
Glossary terms: pull_request_target, GitHub Action, GITHUB_TOKEN, OIDC Federation
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
11/11/2026 6:06 pm
pull_request_target is a privilege boundary, not a convenience feature: CI systems fail when maintainers treat the trigger as harmless automation instead of a trusted execution path. The repository context, token scope and checkout ref all become part of the access decision. Once those elements are mixed with contributor-controlled code, the workflow is no longer just building software, it is authorising execution. Practitioners should classify privileged workflow triggers as identity-bearing control points.
A question worth separating out:
Q: What should teams do first when a workflow may expose secrets?
A: First, stop the exposure path by disabling the workflow or removing the secret from the job until you know exactly which step can read it. Then inspect the trigger, permission block, checkout step, and any composite or reusable actions that may receive a privileged token, because the leak is usually caused by execution context rather than the secret itself.
👉 Read our full editorial: GitHub Actions pull_request_target can expose secrets to forked PRs