Branch Protection Bypass

What Is Branch Protection Bypass?

A default branch with no protection accepts whatever is pushed to it. Anyone with push access can commit straight to main or force-push over its history. Review and status checks only work if something forces changes through them. You'll push directly to main with a phished contributor's credentials, then force-push over the history and watch CI get skipped. You'll add branch protection: require a pull request, reviewers, passing checks, and no force-pushes, with the include-administrators setting on, because a rule privileged accounts can step around is not a control.

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.