GitHub Flaw Exploitable with a Simple git push (CVE-2026-3854)

A simple git push command to compromise a GitHub server? It is now possible thanks to the exploitation of a new security flaw discovered by a team of researchers. Here is what we know about this new vulnerability (CVE-2026-3854).

CVE-2026-3854: A Flaw in GitHub

A new major security flaw, tracked as CVE-2026-3854 and assigned a CVSS score of 8.7 out of 10, has been identified by security researchers at Wiz. The issue lies in babeld, the proxy that acts as the entry point for Git operations. This component inserts user-supplied options directly into an internal header (called X-Stat), but without sanitizing semicolons (;), which are used as delimiters to separate security fields.

This weakness allows an authenticated user to forge their request in a way that injects and overwrites configuration variables. The research team was therefore able to chain several actions together:

• Break out of the sandbox by altering the rails_env parameter.
• Redirect the execution path to a location containing custom scripts.
• Achieve direct remote code execution on the servers, with the privileges of the git service account.

"Thanks to code execution outside the sandbox as the 'git' user, we had full control over the GHES instance, including read/write access to the filesystem and visibility into internal service configuration," the researchers explain in their report.

The researchers were able to exploit this vulnerability directly on GitHub.com (where authenticated access is easy to obtain), which provided access to shared storage nodes. Millions of public and private repositories belonging to various organizations were accessible through the takeover of the Git user.

On this topic, here are the details provided by the researchers that clearly illustrate the impact of this vulnerability: "The git user exists for a reason: it handles all repository operations within the node. By design, it has broad filesystem access to every repository hosted on that node. Compromising this user allowed us to read any repository on the node, regardless of the organization or user that owned it. We enumerated repository index entries accessible from two compromised nodes and found millions of entries on each, belonging to other users and organizations."

On GitHub.com, this vulnerability was patched within 6 hours of Wiz reporting it. The security issue was in fact reported on March 6, 2026. If you use this SaaS platform to host your code, you do not need to take any action. However, another solution is also affected by CVE-2026-3854: GitHub Enterprise Server.

88% of GHES Instances Are Still Vulnerable

Although everything has been fixed on the GitHub.com side, the situation is different for companies hosting their own servers with GitHub Enterprise Server. In Wiz's report published on April 28, 2026, the following statement appears: "GitHub Enterprise Server customers must update without delay: as of this writing, our data indicates that 88% of instances are still vulnerable."

GHES version 3.19.1 and all earlier versions are vulnerable to CVE-2026-3854. You must therefore migrate to one of the versions that include the security fix, at a minimum:

• 3.14.24
• 3.15.19
• 3.16.15
• 3.17.12
• 3.18.6
• 3.19.3

Newer versions have since been released; for example, version 3.14.24 dates from March 10, 2026, while the current version is 3.14.26. So use the versions listed above as the minimum version to deploy on your GHES instance.

Florian Burnel Co-founder of IT-Connect

Systems and network engineer, co-founder of IT-Connect and Microsoft MVP "Cloud and Datacenter Management". I'd like to share my experience and discoveries through my articles. I'm a generalist with a particular interest in Microsoft solutions and scripting. Enjoy your reading.

See Full Bio