Branch Protection Bypass

What Is Branch Protection Bypass?

Branch protection bypass is a governance and process control failure: when a repository's default branch has no branch protection, anyone with push access can commit straight to it or force-push over its history, sidestepping the pull request review and continuous integration checks the team depends on. Because merges to the default branch often trigger an automatic deploy, one push can put unreviewed code into production. This is distinct from a secrets leak or a forged-authorship attack; nothing here is stolen from the repository or faked at the commit level. The weakness is that the branch simply accepts whatever is pushed to it. This exercise puts you on both sides. As Bob, an attacker holding a phished contributor's credentials for Riftwell's repository, you notice that the main branch has no branch protection, so direct pushes and force-pushes are both allowed. You commit a change and force-push it to main, rewriting history and skipping both review and CI, and because merges to main auto-deploy, your code is live in production immediately. As Alice, a DevOps lead at Riftwell who owns the repository settings, you receive a rewritten-history alert and find that commits you reviewed are gone. You see that main accepted a force-push from a single account with no review and no status checks, and you close the gap by enabling branch protection on main: require a pull request, require reviewers, require passing status checks, block force-pushes, and include administrators so no privileged account can bypass the rule. A re-attempted direct or force push to main is then rejected as a protected branch, and you file the report. The exercise closes on why an unprotected default branch is so dangerous and why branch protection, applied to everyone, is the control that restores review and CI.

What You'll Learn in Branch Protection Bypass

• Recognize what an unprotected default branch allows: direct pushes and force-pushes that rewrite history and bypass pull request review and CI status checks
• Trace how a single compromised contributor account can push unreviewed code straight to production when merges to the default branch auto-deploy
• Understand why a force-push to a shared branch is dangerous, because it rewrites history others reviewed and built on and can erase commits with no record
• Apply branch protection rules that require a pull request, required reviewers, and passing status checks and that block force-pushes on the default branch
• Enable the include-administrators option so the rule cannot be bypassed by privileged accounts, making the control enforceable for everyone

Branch Protection Bypass — Training Steps

1. A stolen contributor seat

   Today Bob is targeting Riftwell, a logistics-software company. He has phished a contributor's credentials for the dispatch-api repository and wants his own code running in production, without a single person reviewing it first. He starts by opening the repository the stolen account can push to.

2. Nothing guards main

   The repository status board tells Bob everything he needs. The default branch is main, its branch protection reads none, and every push to main deploys straight to production. With no rules on the branch, he can push directly to it and force-push over its history, and whatever lands ships to production on its own.

3. Clone the repository

   Bob clones the repository locally with the stolen account, so he can rewrite its history and build his change before pushing it back to main.

4. Rewind past the audit commit

   The most recent reviewed commit on main added audit logging to the authentication service, exactly the record that would flag the change Bob is about to make. So he starts by rewinding his local main one commit, dropping that audit-logging commit entirely. On a protected branch this would be impossible. Here it is a single command.

5. Force-push over main

   Bob force-pushes his rewound history straight to main. Because the branch has no protection, the server accepts it and the reviewed audit-logging commit is gone from the shared branch, as if it had never been merged. Everyone else who pulls main will now silently lose that commit too. That is what a force-push to a shared branch does: it rewrites history other people already reviewed and built on.

6. Open the auth middleware

   Now Bob adds his own code. He opens the authentication middleware, the file every request to the dispatch API passes through, and reads it clean before touching it.

7. Plant the bypass

   Bob adds a short block near the top of the middleware. It reads like a compatibility shim for a legacy relay, but any request carrying one fixed header value is waved through as an administrator, with no token and no signature check. A back door into every route the service protects, disguised as harmless plumbing.

8. Buried in plain sight

   The added block sits among ordinary middleware and reads like something a backend engineer might write. Nothing about it looks alarming at a glance, which is exactly why it would survive a quick review, if a review ever happened.

9. Commit onto main

   Bob commits the change directly onto main with a message about a relay timeout, nothing that mentions authentication. There is no branch and no pull request; the commit is already sitting on the default branch in his clone.

10. Push straight to production

    Bob pushes the commit straight to main. There is no pull request to open, no reviewer to approve it and no status check to pass. The branch accepts it, and because merges to main auto-deploy, his back door is live in production seconds later.