Wiz Research rapporterte CVE-2026-3854 til GitHub 4. mars og fikk feilen mitigert på GitHub.com samme dag. CVE-en, som GitHub klassifiserer med CVSS 8.7, lar enhver autentisert bruker kjøre vilkårlige kommandoer på GitHubs backend ved å pushe med spesielt utformede push-options. Eksploiteringen krever ingen spesialverktøy, kun en standard git-klient og kommandoen git push -o.
Selve feilen er en injeksjon i et internt protokoll-header kalt X-Stat. GitHubs backend består av flere tjenester (babeld, gitauth, gitrpcd, pre-receive-hooken) som hver er skrevet i forskjellige språk og som videresender sikkerhetspolicyer som semikolon-separerte key=value-felter. Når babeld kopierte brukerens push-options inn i headeren uten å sanitere semikolon, kunne en angriper «bryte ut» av sitt eget felt og overskrive sikkerhetskritiske felter som rails_env, custom_hooks_dir og repo_pre_receive_hooks. Map-en bruker last-write-wins, så angriperens verdi vinner.
«Each assumption was reasonable in isolation, and dangerous in combination.» — Wiz Research
Forskerne kjedet tre injeksjoner sammen for å eskalere til RCE: bytte rails_env til en non-production-verdi (gir usandboxet eksekvering), peke custom_hooks_dir mot en kontrollert sti, og injisere et hook med path traversal i repo_pre_receive_hooks. På GitHub.com landet de som git-bruker på en delt storage-node og kunne i prinsippet lese millioner av andre brukeres repoer. Wiz bekreftet eksponeringen kun via egne testkontoer.
For deg som driver GitHub Enterprise Server er dette en P1. Wiz oppgir at 88 prosent av instansene fortsatt var sårbare ved disclosure 28. april. Patcher finnes for 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 og 3.19.3. GitHub.com-brukere trenger ikke gjøre noe, GitHub fikset det 4. mars.
Den andre interessante vinklingen er metoden: Wiz brukte KI-assistert reverse engineering med IDA MCP for å analysere GitHubs lukkede binærer. Det er en av de første kritiske sårbarhetene Wiz har funnet i lukket kildekode med KI-verktøy, og det varsler at den klassen av cross-component-bugs som tidligere var for tidkrevende å lete etter, nå er innen rekkevidde.
Hva bør du gjøre?
- Hvis du kjører GHES: oppgrader til en patchet versjon i dag. Sjekk versjonsnummeret med
ghe-versionog match mot listen over. - Audit andre interne protokoller du selv har bygget: hvor flyter brukerinput gjennom delimiter-baserte headere mellom tjenester? Sanitering på input-grensen er ikke nok hvis en nedstrømstjeneste tolker dataen som autoritativ.
- Tegn opp tillit-modellen mellom tjenestene dine. Når en tjeneste «trusts babeld completely», som gitrpcd gjorde, er det et angrepsmål.