CVE-2026-3854: check your GHES patch number twice

If you patched your GitHub Enterprise Server to 3.19.3 because the research write-up told you to, you are still vulnerable. CVE-2026-3854 is a remote code execution flaw in GitHub Enterprise Server, scored 8.7, that an attacker with push access to any repository can trigger with a single git push. The fix versions quoted in most coverage are the last affected versions from GitHub's own advisory, off by one patch release.

That is the first thing to check this week. The second is how the bug was found: not by reading source, but by pointing an AI agent at a decompiler and letting it work through GitHub's shipped binaries. That method does not care whose appliance you run.

What CVE-2026-3854 is, and who has to act

GitHub's own CVE record describes it as an improper neutralisation of special elements — CWE-77, command injection. During a git push, user-supplied push option values were not sanitised before being placed into internal service headers, and because the header format used a delimiter that could also appear in user input, an attacker could inject extra metadata fields. We are deliberately stopping at the level of detail GitHub published; the exploit chain is in the researchers' hands and does not need repeating here.

The CVSS 4.0 vector is the part worth reading: network attack vector, low complexity, low privileges required, no user interaction, high impact on confidentiality, integrity and availability. Base score 8.7. Note that the CVE record's own severity label for 8.7 is "High", not "Critical", even though the research write-up and most press coverage call the flaw critical. Both are defensible — the business impact is worse than the arithmetic — but if your patch policy triggers on the word "critical", check what your scanner actually ingested.

Low privileges required means push access to a repository. On a self-hosted instance where any employee can create a repo, that is effectively every account you have issued.

The patch numbers in circulation are off by one

This is the discrepancy that matters operationally. Wiz's write-up lists vulnerable versions as "<= 3.19.1", gives fixed versions as 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 and 3.19.3, and tells administrators to "upgrade to GHES version 3.19.3 or later". GitHub, as the CVE numbering authority for its own product, says those exact versions are the highest affected ones.

Release line	Affected up to and including	First fixed version
3.14	3.14.24	3.14.25
3.15	3.15.19	3.15.20
3.16	3.16.15	3.16.16
3.17	3.17.12	3.17.13
3.18	3.18.6	3.18.7
3.19	3.19.3	3.19.4

The CVE record settles it twice over. Its version ranges mark each of those releases as affected with status changing to unaffected at the next patch, and every reference URL on the record points at the release notes for 3.19.4 and its siblings — 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7. The Spanish-language description on the NVD entry repeats the lower set of numbers while the English description on the same entry gives the higher set, so even the national database carries the error in one field.

Treat GitHub's advisory as authoritative and upgrade past the numbers in the blog coverage. An instance sitting on 3.19.3 and marked remediated in your tracker is a false negative, and false negatives are how this becomes an incident rather than a ticket. We have written before about what to automate in vulnerability triage and what to keep in human hands; reconciling a vendor advisory against a researcher's summary is firmly in the second category.

A decompiler agent found it, not a source audit

Wiz says plainly that it had looked at GitHub Enterprise Server before and given up on this class of bug, because "extracting and auditing the sheer volume of compiled blackbox binaries that run this pipeline historically required an impractical amount of time and manual effort". What changed was tooling. By running automated reverse engineering through IDA MCP, the team analysed the compiled binaries, reconstructed the internal protocol, and mapped where user input could influence server behaviour across the pipeline. Wiz calls it one of the first critical vulnerabilities discovered in closed-source binaries using AI.

The supporting detail is that this tooling stopped being a hobbyist project in autumn 2026. Hex-Rays shipped an official IDA MCP server on 25 September 2026, free and open source, whose primary tool is IDAPython evaluation — the agent writes and runs Python against the database — and which can drive headless idalib instances without anyone opening the GUI. Vector 35 shipped a first-party MCP server in Binary Ninja 6.0 on 3 September 2026, included in every edition down to the free one.

Two of the three major decompilers now ship vendor-supported agent interfaces. The cost of auditing a binary you did not write has dropped, for defenders and for everyone else, and it dropped for every vendor appliance in your rack at the same time. To be clear about our own position: Creuto did not find this bug, we were not involved in the disclosure, and we have not used either of these MCP servers in client work. We are reading the same advisories you are.

Why cloud customers were fine and self-hosted ones were not

Wiz reported the flaw on 4 March 2026 and states that GitHub mitigated GitHub.com within 6 hours of the report; the disclosure timeline shows the report and the GitHub.com fix both landing on 4 March. Some secondary coverage puts that window at 2 hours. Wiz's own figure is 6, and on a disputed number the primary write-up wins.

The gap between 2 and 6 hours is trivia. The gap between a vendor-operated fix and a customer-operated one is the whole post. GitHub.com users needed to do nothing. Self-hosted administrators needed to notice, schedule and apply an upgrade — and at publication on 28 April 2026, Wiz's data indicated 88% of GHES instances were still vulnerable. That figure is nearly six months old as of October 2026 and the true current share is unknown, so treat 88% as evidence about patch velocity rather than today's exposure.

This is the same shape as the Forgejo template repository RCE and the Next.js 16.4.1 triage: the hosted tier gets patched by someone whose job it is, and the self-hosted tier inherits the work. Running your own source control is a defensible choice for compliance, latency or data residency. It is not a free one, and the invoice arrives as unplanned upgrade windows.

How to triage your own instance this week

1. Get the real version. Read it from the management console or ghe-version on the appliance, not from your asset inventory. Inventories lag upgrades.
2. Compare against the first-fixed column above, not against the numbers in press coverage. If you are on 3.19.3, you are affected.
3. Upgrade to the patch release in your own line rather than jumping a minor version. GitHub shipped a fix for all six supported lines specifically so you would not have to.
4. Assume push access equals exposure. There is no configuration that makes an unpatched instance safe, so do not spend the window hunting for a mitigation instead of patching.
5. Check what else is listening. The discovery method generalises to any compiled appliance you host — the question is which other vendor binaries are sitting on your network with no patch pipeline behind them.

If nobody owns that last question at your company, that is the real finding, and it outlives this CVE. Our DevOps and cloud engineering practice does this kind of inventory and patch-path work with clients. The next decision is smaller than it sounds: name the person who reads vendor advisories for your self-hosted estate, and give them the authority to take an upgrade window without asking.