Why do malicious pull requests create higher identity risk than ordinary code review?

Why a malicious pull request is more dangerous than an ordinary review issue

A normal review failure usually exposes bad code. A malicious pull request can expose the reviewer’s trust boundary itself. If the review happens inside an authenticated developer session, the attacker may benefit from cached credentials, local tokens, signed-in browser state, and any tooling the reviewer uses to inspect or validate the change.

That is why the question is not just “was the code approved?”, but “what execution context was available while the review was being processed?”. Once the review surface overlaps with reusable secrets or write-capable tooling, the pull request becomes a potential identity compromise path, not only a code quality problem.

There is a useful distinction here between review fraud and context abuse. Review fraud tries to get unsafe code merged. Context abuse tries to make the reviewer’s active environment do the attacker’s work, including downstream writes, token reuse, repository manipulation, or secret extraction.

How trust in the reviewer session turns into downstream access

The danger rises when the review environment can reach systems that the PR author cannot directly reach. That can include CI/CD credentials, API tokens, package publishing rights, or repository permissions available through the maintainer’s session. In those cases the malicious PR may be less about the diff itself and more about triggering a privileged action in a trusted context.

This is closely related to how poisoned workflows, fork handling, and token exposure create blast-radius expansion. A PR that only “looks like code” can still be a delivery mechanism for secret access or write actions, especially when the review or test path runs with more privilege than the contributor should have. For examples of how exposed tokens and review-time trust can be abused, see JetBrains GitHub plugin token exposure and reviewdog Action compromise 2025.

When that pattern appears in open source and automation-heavy environments, the attacker’s objective is often to turn review trust into laterally useful access. The malicious PR is then a foothold into the maintainer’s authenticated state, not just a bad contribution request.

What defenders should look for in pull request review paths

The practical question is whether the review process ever places secrets, tokens, or write permissions within reach of untrusted content. If the answer is yes, then the review path needs to be treated like a privilege-bearing workflow with explicit isolation. That includes fork safety, short-lived credentials, and separation between code inspection and any action that can mutate state.

In supply-chain cases, a malicious PR can become the front door to broader compromise if the review path also touches CI, release, or bot credentials. The same structural weakness appears across workflows that assume “read-only review” while still running in an environment that can sign, publish, or authenticate. Background on those failure patterns appears in Top 10 NHI Issues and Ultimate Guide to NHIs, What are Non-Human Identities.

Once the environment can authenticate on the reviewer’s behalf, the PR is no longer only a content-review object. It is a vehicle for inheritance of session context, and that context can be more valuable than the code change itself.

Risk and Threat Considerations

Malicious pull requests are risky because they can exploit trusted review workflows, not just code acceptance decisions. The highest-impact failure mode is when untrusted content is processed in a session that already has reusable authentication material or downstream write authority.

Failure mechanism: The attacker uses the review path to reach cached tokens, signed-in browser state, CI credentials, or other privileged context, then pivots from read-like review into authenticated write or secret access.

Impact: The compromise can extend beyond one unsafe merge to secret theft, repository tampering, release poisoning, or broader supply-chain abuse.

Practitioner Guidance

What to verify: Confirm that review, testing, and merge paths are isolated from any credentialed action. If a maintainer can inspect untrusted code while logged into systems that can publish, sign, or administer, treat that as a privilege boundary problem, not a code-review preference.

What to prioritise: Reduce the reviewer’s available blast radius first. The key control objective is not perfect review hygiene, but making sure a malicious PR cannot inherit reusable secrets or privileged execution context.

Practitioner takeaway: The real risk is not that a malicious PR is approved, it is that the review session itself becomes an authenticated attack surface.

Related resources from NHI Mgmt Group

• Why do malicious npm packages create more risk than ordinary code defects?
• Why do malicious skills create a bigger risk than ordinary code dependencies?
• Why do exposed access gateways create higher identity risk than ordinary perimeter devices?
• Why do malicious extensions that impersonate compiler or code runner tools create a higher trust risk in developer environments?