Git push option injection enables GitHub server RCE

TL;DR - A crafted git push with malicious push options can inject trusted internal metadata and reach arbitrary command execution on the server handling the push. GitHub.com is already patched; GHES admins need to upgrade and review audit logs for suspicious push options containing ;.

What happened

GitHub’s git push pipeline routes user pushes through multiple internal services, passing push metadata between them.

GitHub disclosed a critical RCE (CVE-2026-3854) where attacker-controlled git push options were incorporated into internal metadata without sufficient sanitization. Because the internal metadata format uses a delimiter character that can also appear in user input, a malicious user can craft push option values that inject additional fields that downstream services treat as trusted internal values.

In GitHub’s description, chaining injected values can (1) override the environment used to process the push, (2) bypass sandboxing protections that normally constrain hook execution, and (3) execute arbitrary commands on the GitHub server handling the git push.

Timeline highlights from GitHub: the report was received via bug bounty on March 4, 2026; GitHub validated and deployed a fix to GitHub.com within about two hours; and GitHub states its forensic investigation found no exploitation beyond the reporting researchers’ testing.

This is high-impact because it turns “any user with push access” into server-side code execution on a core developer workflow surface. Git transport features like push options are routinely exposed in internal automation and enterprise self-hosted setups, so subtle sanitization gaps can become full CI/CD and source-control platform compromise paths.

Who is impacted

• GitHub.com and GitHub Enterprise Cloud (including Data Residency and EMU): GitHub states these were patched on March 4, 2026 and require no customer action.
• GitHub Enterprise Server (GHES): Instances running versions prior to the patched releases listed below.
• Exploitation on GHES requires an authenticated user with push access on the instance.

Note: GitHub also states it published CVE-2026-3854 and prepared patches across all supported releases.

What to do now

• Follow GitHub remediation guidance and apply the latest patched GHES release available at the time of writing.

  "These are available today and we strongly recommend that all GHES customers upgrade immediately."

• Hunt for exploitation attempts using GitHub’s recommended log review.

  "We recommend that you review /var/log/github-audit.log for push operations containing ; in push options."

• Scope blast radius like an internal RCE:
  • identify which users and automation identities have push access to any repositories on the GHES instance
  • review recent administrative changes and repository settings changes made around the time window you see suspicious pushes
• Reduce exposure while rolling out the upgrade:
  • temporarily tighten who can push to repositories (especially where untrusted contributors can obtain push access)
  • monitor for unexpected process execution and anomalous hook behavior on GHES hosts (whatever telemetry you already run for host-level detection)