- Seqrite reports that CVE-2026-3854, scored 8.7, let a user with push access inject internal settings and run commands on GitHub Enterprise Server.
- The cause was a semicolon that Git allowed in push options but GHES used as a separator, plus parsing where the last duplicate value wins.
- GHES administrators should install a patched build, search the audit log for semicolons in push options, and rotate secrets if anything looks suspicious.
Software parts pass notes to each other, and each part trusts the notes it gets. CVE-2026-3854 shows what happens when an outsider can write on one of those notes. The flaw sat in GitHub Enterprise Server (GHES), the edition of GitHub that organisations use to host private code. It turned permission to push code into permission to run commands on the server.
What Seqrite found
Seqrite's analysis calls CVE-2026-3854 a high-severity remote code execution flaw. That means an attacker can run their own commands on a machine they do not own. The bug sat in the part of GitHub that handles incoming pushes.
The attacker needed a login with push access to one repository. Seqrite says no administrator rights were needed. Nor was a booby-trapped commit or any action by a victim.
How one semicolon crossed a trust boundary
Three services handle a push over SSH. A service called babeld takes the connection. Another, gitauth, checks who the user is and what they may touch. A third, gitrpcd, then prepares the checks that run before the server accepts the push.
These services pass along an internal note called X-Stat. It is a list of key=value settings split by semicolons. Gitrpcd treated every entry as if the server itself had written it.
Users can attach a small value to a push, called a push option, using the -o flag. Git blocks some characters in that value. It does not block the semicolon.
GHES copied the user's value into X-Stat without escaping the semicolon. So a semicolon ended the user's entry and started a new setting. The attacker was now writing the server's own notes.
One more behaviour made it worse. If a setting appeared twice, the parser kept the last one. User text could therefore replace a value the server had set earlier.
Seqrite calls this a metadata-injection primitive, not direct command injection. The danger depended on which settings an attacker could replace.
Think of a hotel order form. Guests may write in the comments box. If the kitchen reads the whole sheet as official, a guest can add their own orders.
Three settings that reached the hook
A pre-receive hook is a script that runs before the server accepts a push. Seqrite traced the attack to three X-Stat settings that steer it.
The first, rails_env, picks the execution path. Swapping its production value sent hooks down a path where they ran directly, outside the normal sandbox. A second setting, custom_hooks_dir, fixed the starting folder for finding hooks. A third, repo_pre_receive_hooks, influenced the final path the server settled on. With all three replaced, hooks ran in a different mode and from a location outside the intended folder.
The result was that the server could launch a program already on the machine. It ran outside the sandbox, as the git service user.
Why "not root" is a thin comfort
The attacker ran as the git service account, not as root. That account is still powerful. It can read repository data, configuration files and the secrets GHES uses.
Seqrite's conclusion is plain. Someone allowed to push to one repository could move past it and compromise the wider server. Organisations host private source code, deployment credentials and links to internal development systems on GHES.
Wiz Research published its own findings. It reported that GitHub.com had the same underlying weakness. Code would run on infrastructure shared by many customers, so Wiz described a risk across tenants.
GitHub's response says the researchers read repository records only to confirm the flaw. It says they did not view other users' repository contents. The Seqrite analysis does not say whether attacks happened in the wild.
What leaders should ask this week
First, ask whether every GHES instance runs a patched build. GitHub's incident post lists the minimum versions. Upgrading closes the vulnerability.
Second, ask whether anyone has looked for past abuse. GitHub suggests searching /var/log/github-audit.log for pushes whose options contain a semicolon.
For each hit, check who pushed, to which repository, from where and when. Also look for odd processes, file access or repository activity around that time.
If a push looks suspicious, save the logs and system state first. Then rotate credentials and internal secrets that may have been exposed.
Third, ask who holds push access. Each of those accounts was a possible way in.
Fourth, ask your own engineers where internal services join user text into delimited strings. Seqrite's advice for builders has three parts. Escape separators before packing data into a string. Refuse repeated keys. Check execution settings again just before a hook runs.
The lesson of CVE-2026-3854 is that a trust boundary is only as strong as its least careful copy. The server checked who the user was. It never checked what the user's words would turn into.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Seqrite.
