CVE-2026-3854 is the kind of bug you do not want in the git push pipeline. GitHub's postmortem calls it critical remote code execution. The blog post does not publish a CVSS score. I read it as the rare incident report with two truths at once: the response was fast, and the bug lived inside the kind of boring developer workflow everyone treats like plumbing until it sprays sewage on the carpet.
The report came through GitHub's Bug Bounty program on March 4, 2026 from Wiz researchers. GitHub says the team reproduced the issue within 40 minutes and deployed a fix to github.com at 19:00 UTC, less than two hours after identifying the root cause at 17:45 UTC. That is genuinely quick. It also does not shrink the blast radius of "a push can become command execution" into a footnote.
The attack used a crafted git push option. Push options are a normal Git feature that lets clients send key-value strings during a push. GitHub says user input was incorporated into internal metadata without enough sanitization. Because the metadata format used a delimiter that could also appear in user input, an attacker could inject trusted-looking internal fields, override the processing environment, bypass sandboxing protections, and execute arbitrary commands on the server handling the push. In other words, the front desk accepted a visitor badge with extra rooms printed on it, then the building treated it as official.
Cloud users do not need to do anything: github.com and GitHub Enterprise Cloud variants were patched on March 4. GitHub Enterprise Server customers get the less cinematic ending. GitHub lists fixed releases 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4, and 3.20.0 or later. It also recommends reviewing /var/log/github-audit.log for push operations containing semicolons in push options. Glamour, apparently, is grepping appliance logs for punctuation.
The exploitation paragraph needs careful wording. GitHub says telemetry showed every anomalous code path execution mapped to Wiz testing and that no customer data was accessed, modified, or exfiltrated. I would not turn that into fairy dust. It is GitHub's forensic conclusion, not a magic independent proof. Still, the described telemetry hook is concrete: the exploit forced a code path not used in normal github.com operation.
The most useful lesson is the defense-in-depth failure. GitHub says the exploit worked partly because an unintended code path still existed on disk in the server container image after a deployment model changed. An older deployment method excluded it; the newer one did not carry that exclusion forward. I noticed that line because it turns a modern deployment story into an old release-hygiene problem: some neglected component is still sitting in the corner, waiting to make everyone's day worse.
So yes, credit for speed. Also: patch GHES, inspect logs, and audit what dead code your deployment images still ship. Dead code is not nostalgia. On a server that accepts pushes, it is an open utility closet with root-shaped tools inside.