Malicious Pull Requests

A pull request that claims to fix a flaky test hides a backdoor in an unrelated deploy script. See how skimming the description misses it, then catch it by reading the full diff and harden review with CODEOWNERS, multiple reviewers, and fork limits.

What Is Malicious Pull Requests?

Malicious pull requests are a supply-chain risk that targets the human review step rather than any single line of code. A contributor opens a change that looks small and helpful, then hides an out-of-scope edit in a file the description never mentions, betting that the reviewer will trust the summary and approve without reading the full diff. This exercise puts you on both sides. As Bob, an attacker posing as a friendly open-source contributor, you fork Fennroot's public Harrow repository and open a pull request that claims to fix a flaky test, then quietly plant one line in an unrelated deploy script that ships every CI environment variable to a server you control, bury it among legitimate diff hunks, write a description that talks only about the test, and nudge for a quick merge. As Alice, a senior engineer and maintainer at Fennroot, you are auto-requested as a reviewer because the pull request touches a path your team owns. Instead of trusting the description you open the full diff and read every changed file, spot the deploy-script edit that has nothing to do with a test fix, and request changes rather than merge, flagging the contributor. You then harden the project's review policy: add CODEOWNERS so the deploy and CI scripts require a designated reviewer, and turn on branch protection rules that require review from code owners, require more than one approval, and restrict what pull requests from forks are allowed to run. Reopening the same pull request shows the merge is now blocked until the deploy-script's code owner reviews it. The exercise is about human review discipline, a person carefully reading a diff, not any automated tool, and its quiz reinforces the red flag of an out-of-scope edit, why a genuine fix can be cover, why the description is not enough, how CODEOWNERS and required reviewers help, and why fork pull requests deserve extra caution.

What You'll Learn in Malicious Pull Requests

Malicious Pull Requests — Training Steps

  1. Size up the project

    Today Bob is targeting Fennroot, an open-source developer-tools project that takes pull requests from anyone. He starts where any contributor would, on the public repository for Harrow, the project's build tool. An open project is an open door: anyone can fork it, change it, and open a pull request. Bob is not here to help. He wants his code merged, and a busy maintainer's review is the only thing in his way.

  2. Fork and clone

    Bob forks the repository to his own account and clones the fork locally, so he can make his changes and push them back as a pull request. His plan is simple: include one genuinely useful change as cover, and hide a second, unrelated one alongside it.

  3. The cover and the target

    Bob's cover is real: he fixes a genuinely flaky retry test, the kind of small contribution a project welcomes. That change is honest and helpful, and it is the whole point. It makes the pull request look routine. His actual target is a different file entirely. He opens the deploy script, which has nothing to do with any test, and reads it clean.

  4. Plant the backdoor

    Bob adds a single line to the deploy script. It looks like a harmless bit of build telemetry, but it ships every environment variable to a server he controls. The deploy script runs in the project's CI, where those variables include deploy keys and registry tokens. One line, in a file the pull request never mentions. That is the entire attack.

  5. Buried in plain sight

    The line reads like something a build engineer might add, and it sits among ordinary deploy steps. Nothing about it screams attack, which is exactly why it survives a quick skim.

  6. Commit both changes

    Bob stages and commits both edits together: the real test fix and the deploy-script line, in one commit. Bundled together, the malicious change rides in on the back of the honest one.

  7. Push to the fork

    Bob pushes the branch up to his fork. The push goes to his own copy of the repository, and the platform answers with a link to open a pull request against Fennroot.

  8. Open the pull request

    Bob opens the pull request against Fennroot's repository. He writes a title and description that talk only about the flaky test, and never mention the deploy script. The test fix is the story he wants the reviewer to read. The backdoor is left out of it entirely.

  9. Nudge for a merge

    With the pull request open, Bob adds a friendly comment nudging for a quick merge. He leaves it on the test line, so the reviewer's eye lands there and not on the deploy script. A little social pressure to approve fast, before anyone reads too closely.

  10. Knowledge check

    You just watched a backdoor ride into a pull request behind a genuine fix. Lock in why it is dangerous.