A pull request that appears to be a normal contribution but contains code or workflow changes designed to steal data, alter builds, or persist access. In practice, it abuses repository review processes and CI execution to turn collaboration mechanics into an attack path.
How Malicious Pull Requests Work
A malicious pull request is not just a bad code change, it is an abuse of normal collaboration flow. The attacker hides harmful logic, workflow changes, or dependency updates inside a contribution that looks reviewable and legitimate, then relies on trust in the review process and CI execution to get the payload run.
The key security property being exploited is that pull requests often trigger automated checks, previews, tests, or build jobs before the change is merged. That makes the pull request a delivery path for secrets theft, build tampering, and persistence if reviewers do not inspect code, workflow files, and dependency behaviour with enough care.
Where the Attack Surface Appears
The attack surface is wider than the visible application code. In many repositories, a pull request can affect CI pipelines, release scripts, package manifests, infrastructure-as-code, and test fixtures, all of which may execute with access to secrets or trusted build systems.
That matters because the attacker does not need to win a direct login prompt if they can get a trusted automation path to execute on their behalf. In the worst cases, a malicious change can exfiltrate tokens, alter build outputs, poison released artifacts, or create a durable foothold through modified workflow logic.
Recent supply-chain incidents show the same pattern in different forms, from token theft to build tampering. NHIMG’s Ultimate Guide to Non-Human Identities notes that 96% of organisations store secrets outside secrets managers in vulnerable locations, and 97% of NHIs carry excessive privileges, which is exactly the kind of exposure malicious pull requests try to reach.
Why Review and CI Controls Matter
Malicious pull requests succeed when organisations treat review as a formality instead of a control. A human reviewer may focus on functional correctness while missing small workflow edits, subtle dependency swaps, or test-step changes that only matter because they run inside a trusted pipeline.
CI systems also change the risk profile. If pull request jobs can read secrets, write artifacts, or reach internal services, then a contribution becomes an execution environment. The safer model is to assume every untrusted branch is hostile until the pipeline proves otherwise.
For a useful defensive reference point, the OWASP API Security Top 10 helps frame how overly broad access and weak authorization assumptions create abuse paths, while SLSA is a strong supply-chain benchmark for build integrity and provenance. The practical lesson is that code review alone is not enough when the pipeline itself is part of the attack surface.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK 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 4 — Secure Configuration of Enterprise Assets and Software | Pull request abuse often targets workflow and build configuration changes. |
| CIS 6 — Access Control Management | Malicious PRs seek excessive repository, pipeline, and release privileges. | |
| CIS 16 — Application Software Security | Reviewing code and workflow changes is a software assurance control problem. | |
| Recommendation — Harden CI and repo settings so untrusted pull requests cannot alter trusted execution paths. Limit repository and pipeline privileges to the minimum needed for each role. Apply code-review and security testing controls to catch malicious changes before merge. | ||
| NIST CSF 2.0 | PR.AC — Identity Management, Authentication and Access Control | Trusted CI execution depends on controlling who and what can act in the repository. |
| PR.IP — Information Protection Processes and Procedures | Malicious pull requests exploit weak review and release procedures. | |
| DE.CM — Security Continuous Monitoring | CI and repo telemetry is needed to detect suspicious pull request behaviour. | |
| Recommendation — Restrict privileged repository and pipeline access to approved actors only. Define and enforce review, merge, and release procedures that treat workflow changes as high risk. Monitor pull request, workflow, and build activity for anomalous execution or secret access. | ||
| MITRE ATT&CK | T1195 — Supply Chain Compromise | The term describes abusing trusted contribution and build paths to compromise software delivery. |
| T1552 — Unsecured Credentials | These attacks often try to steal tokens, keys, or other secrets from CI and repo context. | |
| Recommendation — Model malicious pull requests as supply-chain compromise and hunt for tampering in the delivery chain. Assume pull request execution may expose credentials and protect secrets accordingly. | ||
Practitioner Guidance
What to watch for: The highest-risk pull requests are often the smallest ones, especially changes to workflow files, dependency definitions, release steps, test harnesses, or script logic that looks routine at a glance. Reviewers should treat any change that can influence execution, secrets exposure, or artifact creation as materially more sensitive than ordinary application code.
Governance implication: Ownership for pull request risk should sit with both repository maintainers and platform owners, because the failure is usually shared between code review quality and pipeline trust design. If a repository can execute untrusted contributions with privileged access, the process is already too permissive.
Practitioner takeaway: Reduce trust in pull request execution paths, not just in reviewers, because malicious contributions are designed to exploit the gap between “looks normal” and “runs with privilege.”
Risk and Threat Considerations
Malicious pull requests create direct exposure to source tampering, secret theft, and supply-chain compromise. The danger is not only that a bad change gets merged, but that it can execute inside trusted CI before merge, which gives the attacker a path to exfiltrate credentials or alter build outputs without needing long-term access to the repository.
Failure mechanism: The attacker hides harmful logic in a legitimate-looking contribution, then relies on automated review, test, or build jobs to run that code in an environment that has access to secrets, release tooling, or internal trust relationships.
Impact: The result can be credential exposure, unauthorized repository changes, poisoned artifacts, persistence through workflow modification, or downstream compromise of software consumers who trust the release process.
Related resources from NHI Mgmt Group
- Why does malicious dependency classification matter in pull request workflows?
- What happens when a malicious pull request is merged into an overprivileged GitHub Actions workflow?
- How should security teams reduce the blast radius of malicious GitHub Actions when workflows process untrusted pull request inputs?
- Should organisations allow pull_request_target for automated dependency workflows?
