A technique where someone with reviewer permissions modifies an existing pull request, approves the changed code, and helps it merge without a truly independent review. The core issue is not the pull request itself, but the overlap between edit rights and approval rights.
How Pull Request Hijacking Works
Pull request hijacking is a review-process abuse pattern, not a code vulnerability in the narrow sense. The attacker or insider exploits the fact that edit rights and approval rights can overlap, then changes the pull request after the original author’s intent is no longer the only version under review.
That distinction matters because the merge decision may be based on trust in the reviewer workflow rather than a fresh, independent examination of the final diff. In practice, the weakness often sits in repository permission design, review policy, branch protection, and the timing of edits versus approvals.
When the process is healthy, the person judging the change set cannot also silently reshape the change set in a way that invalidates the review. When those duties are not separated, approval can become a procedural stamp rather than a genuine control.
Where The Control Breaks Down
The core failure is separation of duties. If a reviewer can modify the code, comment on it, and approve it without forcing a new independent review, the process no longer guarantees that the approved content is the content that ships.
This usually appears in environments where repository permissions are broad, branch protections are weak, or the platform does not require re-review after substantive edits. The issue can also show up in fast-moving teams where social trust substitutes for technical enforcement.
The control objective is simple: the entity that changes the pull request should not be the same entity that gives the final approval unless the workflow explicitly revalidates independence after every material edit. That is why this technique is best understood as a governance failure in code review integrity, not merely a social-engineering trick.
Why It Matters For Software Supply Chain Trust
Pull request hijacking undermines the reliability of code review as a safeguard. If reviewers can alter the change after others have inspected it, the review no longer provides strong assurance about provenance, intent, or final content.
This matters most in repositories that feed production releases, infrastructure-as-code, security-sensitive libraries, or build pipelines. In those contexts, a compromised review path can introduce malicious logic, weaken controls, or quietly slip in dependencies and configuration changes that are hard to spot later.
It also erodes auditability. A merge history may show that a change was “approved,” but not that the approval was based on the exact code that entered the branch. That gap makes incident review, accountability, and change management materially harder.
For supply-chain-aware teams, the practical question is not only whether the code was reviewed, but whether the review was still valid at merge time. SLSA is relevant here because it treats build and provenance integrity as first-class concerns, and that same mindset applies to preserving the integrity of the review path.
How Teams Reduce The Risk
The best defenses focus on workflow separation, not reviewer heroics. Require fresh approval after meaningful edits, limit who can push to protected branches, and ensure that approval cannot be reused after the reviewed diff changes.
Teams should also define what counts as a material change. Even a small-looking edit can be enough to alter logic, permissions, or dependency behavior, so the policy should be based on review impact rather than file size alone.
Repository rules, branch protection, and mandatory review freshness should be aligned so the platform enforces the policy automatically. That reduces reliance on memory, etiquette, or manual policing when the release process is moving quickly.
Where the codebase is part of a larger delivery chain, review integrity should be paired with provenance and trust controls. OWASP API Security Top 10 is not about pull requests directly, but its authorization-focused mindset is useful when change approval can affect exposed interfaces, and NIST Cybersecurity Framework 2.0 provides a broader governance lens for controlling, detecting, and recovering from process weaknesses.
Risk and Threat Considerations
Pull request hijacking creates a trust-break problem: the approval signal no longer proves independent review of the final change. That can let a malicious or careless actor sneak in a risky edit after scrutiny has already happened, especially where branch protection and review freshness are weak.
Failure mechanism: Review permission and edit permission overlap, so a single actor can change the diff after review comments are resolved or after approval has been granted, without forcing a new independent judgment.
Impact: The repository may merge code that was never independently reviewed in its final form, increasing the chance of unauthorized logic, security regressions, or hard-to-trace supply-chain compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
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 | 5 — Account Management | Controls who can edit and approve repository changes. |
| 16 — Application Software Security | Secures code review and release workflow integrity for software changes. | |
| Recommendation — Restrict repository write and approval rights to separate trusted roles. Enforce protected branches and mandatory re-review after material pull request edits. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Addresses authorization boundaries for who may modify and approve code changes. |
| PR.DS — Data Security | Supports integrity protection for code and change artifacts moving through review. | |
| DE.CM — Continuous Monitoring | Helps detect anomalous review and merge behavior in source control workflows. | |
| Recommendation — Define and enforce distinct permissions for editing, reviewing, and merging changes. Protect reviewed code artifacts so approval applies only to the final approved diff. Monitor pull request activity for approval reuse, late edits, and bypass patterns. | ||
Practitioner Guidance
Governance implication: Treat approval as a time-sensitive control, not a permanent endorsement. If the reviewed content changes, the platform should invalidate the approval or require a new reviewer who was not involved in editing the final version.
What to watch for: Repeated late edits after approval, reviewer self-approval patterns, and repository settings that allow broad write access on branches that are supposed to be review-gated. Those signals usually indicate the workflow can be bypassed without much effort.
Related resources from NHI Mgmt Group
- How should security teams harden GitHub branch protections against pull request hijacking?
- Should organisations allow pull_request_target for automated dependency workflows?
- What breaks when untrusted pull request content is executed in a workflow?
- What do security teams get wrong about pull_request_target workflows?
