A malicious pull request can cause the workflow to execute attacker-supplied commands inside the runner, then use that access to exfiltrate secrets or tamper with build steps. Without egress controls, the compromised job can call out to an external endpoint, turning a normal automation task into a delivery path for credential theft and supply chain compromise.
How the exploit path unfolds
An untrusted pull request changes the trust boundary from “reviewed code path” to “code supplied by an external party.” If that pull request can trigger a workflow that invokes a vulnerable GitHub Action, the action’s runtime becomes the attacker’s execution surface. The job may run with repository context, build credentials, or automation permissions that were never meant to be exposed to an outside contributor.
The key issue is not just that the workflow runs, but that it runs with access to the same build environment the pipeline uses for normal delivery. When the action is vulnerable, attacker-controlled input can turn into shell execution, command injection, dependency abuse, or unsafe artifact handling. That is why CI/CD compromise is often a supply chain problem rather than a simple build failure.
Two specific conditions make the scenario worse. First, the pull request is untrusted, so its trigger should be treated as hostile until proven otherwise. Second, the GitHub Action itself is vulnerable, so even a workflow that appears routine can inherit unsafe behavior from the action package or container. For a concrete example of this class of failure, see GitHub Action tj-actions Supply Chain Attack and Reviewdog GitHub Action supply chain attack.
Why missing egress controls changes the blast radius
Egress controls are the difference between local compromise and reachable compromise. If the workflow runner cannot make outbound connections except to approved destinations, stolen secrets, build metadata, and temporary tokens are much harder to exfiltrate. Without those controls, the attacker can immediately send data to an external endpoint, fetch second-stage payloads, or relay results into a broader intrusion path.
That means the impact is not limited to “a bad job ran.” The compromised job can become a delivery channel for credential theft, repository tampering, artifact poisoning, or staging for later access. In practice, unrestricted egress often turns a short-lived workflow compromise into a clean exfiltration path with very little defender visibility. The same pattern appears in real-world secret exposure and repository compromise cases such as GitLocker GitHub extortion campaign and GitHub Repo Breach, Heroku and Travis CI OAuth Tokens.
This is also why secret hygiene matters inside build systems. NHIMG’s Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, which makes a compromised runner especially dangerous when outbound access is unrestricted.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK, OWASP Agentic AI Top 10 and OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Controls workflow permissions and limits exposure from untrusted CI/CD execution. |
| CIS 13 — Network Monitoring and Defense | Egress control and outbound visibility are central to stopping exfiltration from runners. | |
| CIS 16 — Application Software Security | Vulnerable GitHub Actions are software supply chain dependencies inside delivery pipelines. | |
| Recommendation — Restrict workflow permissions and revoke unnecessary access paths for untrusted pull request jobs. Allowlist runner destinations and monitor outbound connections from CI/CD environments. Pin and review third-party actions before allowing them in release workflows. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication, and Access Control | Workflow trust boundaries depend on least privilege and restricted access. |
| PR.PT — Protective Technology | Egress controls are protective technology that limits exfiltration paths. | |
| Recommendation — Apply least-privilege access to untrusted workflow executions and their tokens. Use network restrictions to confine what workflow runners can reach externally. | ||
| MITRE ATT&CK | T1190 — Exploit Public-Facing Application | Untrusted PR-triggered workflows can expose exploitable automation surfaces. |
| T1021 — Remote Services | Compromised runners may reach external services to stage or exfiltrate data. | |
| T1041 — Exfiltration Over C2 Channel | Without egress controls, stolen data can be sent directly from the runner. | |
| Recommendation — Model exposed CI/CD workflow entry points as attack surfaces and reduce reachable trust. Hunt for unexpected external service use from build runners during workflow execution. Detect and block outbound exfiltration paths from CI/CD jobs and runners. | ||
| OWASP Agentic AI Top 10 | A3 — Tool Misuse and Unauthorized Actions | A vulnerable action can be coerced into performing unintended operations in pipeline context. |
| Recommendation — Constrain tool execution so untrusted inputs cannot drive unintended workflow actions. | ||
| OWASP Non-Human Identity Top 10 | NHI-01 — Secrets and Credential Exposure | The scenario directly risks leaking CI/CD secrets from a compromised non-human execution path. |
| Recommendation — Keep pipeline secrets out of untrusted jobs and rotate any secret exposed to a runner. | ||
Practitioner Guidance
What to verify: Confirm whether untrusted pull requests are allowed to trigger any job that can read secrets, publish artifacts, or reach external networks. If they can, treat that as a pipeline design defect, not a minor permission issue.
Implementation sequence: Split PR validation from trusted release workflows, run untrusted jobs with the smallest possible token scope, and enforce outbound allowlisting so the runner cannot freely call arbitrary endpoints. If the workflow must access the network, make the destination set explicit and auditable.
Common mistake: Teams often harden the Action version or review the workflow YAML, but leave the runner’s network path open. That still allows data theft if the action is compromised or if the PR payload can induce unsafe behavior in the job.
Practitioner takeaway: The real control objective is to ensure that untrusted automation can neither inherit powerful credentials nor use outbound connectivity as an exfiltration channel.
Related resources from NHI Mgmt Group
- What happens when a malicious pull request is merged into an overprivileged GitHub Actions workflow?
- What should security teams do first after a GitHub Actions workflow in a public repository is found vulnerable to pull request abuse?
- What breaks when untrusted pull request content is executed in a workflow?
- What breaks when pull_request_target is used to run untrusted code in GitHub Actions?
