Viens git push deva koda izpildi uz GitHub.com — kļūda X-Stat galvenē ļāva lasīt svešus repozitorijus

Marta sākumā Wiz pētnieki ar vienu git push komandu panāca patvaļīga koda izpildi uz GitHub.com serveriem. Kļūda ar apzīmējumu CVE-2026-3854 (CVSS 8.7) ļāva jebkuram lietotājam, kam ir push tiesības kaut vienā repozitorijā, izpildīt komandas GitHub iekšējā infrastruktūrā un no tā paša glabāšanas mezgla nolasīt svešus repozitorijus.

GitHub labojumu uz GitHub.com izvietoja aptuveni divās stundās pēc ziņojuma 4. martā. Pašmitinātajiem GitHub Enterprise Server serveriem tas nepalīdz automātiski: publiskošanas dienā 28. aprīlī ap 88% instanču vēl bija ievainojamas.

Kā viena push opcija pārrakstīja iestatījumus

GitHub push protokols ļauj klientam nosūtīt papildu parametrus ar karodziņu git push -o. Serverī šīs vērtības nonāk iekšējā galvenē X-Stat, ko GitHub servisi izmanto metadatu apmaiņai. Galvene laukus atdala ar semikolu. Lietotāja ievadi tur iekopēja bez pārbaudes, tāpēc semikols push opcijā vairs nebija dati — tas kļuva par lauka atdalītāju.

Rezultāts: uzbrucējs push opcijā varēja iespraust paša izdomātus atslēga-vērtība laukus un pārrakstīt drošībai svarīgus iestatījumus, kurus GitHub serviss uzskatīja par saviem iekšējiem. Wiz apraksta, ka ievainojamība skāra veselu servisu ķēdi — git starpniekserveri babeld, autentifikācijas servisu gitauth, RPC serveri gitrpcd un pre-receive āķu bināro failu.

Trīs injekcijas līdz koda izpildei

Viena lauka pārrakstīšana pati par sevi nedod čaulu. Uzbrukums saliek kopā trīs soļus:

1. Iesprauž rails_env ar vērtību, kas nav produkcija. Tas serveri pārslēdz no smilškastes produkcijas ceļa uz ceļu bez izolācijas.
2. Iesprauž custom_hooks_dir un tādā veidā norāda, no kuras mapes binārais fails meklē āķu skriptus.
3. Iesprauž repo_pre_receive_hooks ierakstu ar ceļa šķērsošanu (path traversal), kas norāda uz uzbrucēja kontrolētu skriptu.

Kad push izpildās, GitHub palaiž šo pre-receive āķi ar git servisa lietotāja tiesībām. Uzbrucējs iegūst komandu izpildi serverī bez smilškastes. Vienīgā prasība ir push piekļuve kaut vienam repozitorijam, un to GitHub.com dod jebkuram reģistrētam lietotājam, kurš izveido savu repozitoriju.

Uz GitHub.com repozitoriji glabājas kopīgos mezglos. Koda izpilde vienā mezglā deva pieeju arī citu klientu datiem uz tā paša mezgla.

Kāpēc tas skāra svešus repozitorijus

GitHub.com nav viens serveris uz katru kontu. Repozitoriji ir izkliedēti pa kopīgiem glabāšanas mezgliem, kur blakus atrodas daudzu klientu dati. Tiklīdz uzbrucējs ieguva koda izpildi uz šāda mezgla, robeža starp klientiem pazuda — no viena mezgla varēja lasīt miljoniem repozitoriju, arī privātu. Tieši šī daudznomnieku uzbūve pārvērta vienas push komandas kļūdu par plaša mēroga datu noplūdes risku.

Enterprise Server versijās uzbrukums dod pilnu kontroli pār konkrēto instanci, ieskaitot lasīšanu un rakstīšanu failu sistēmā. Tur nav kopīgo mezglu, bet ir vesela organizācija ar visu tās kodu vienā serverī.

Kļūdu slēgtā kodā palīdzēja atrast MI

GitHub iekšējie servisi ir slēgts kods. Wiz komanda binaros failus atkodēja ar mākslīgā intelekta palīdzību un tā izsekoja, kā push opcija ceļo cauri servisiem līdz āķa palaišanai. The Hacker News ziņo, ka šī ir viena no pirmajām kritiskajām ievainojamībām, kas slēgta koda binārajos failos atrasta ar MI atbalstītu reverso inženieriju. Metode maina pieņēmumu, ka slēgts kods pats par sevi apgrūtina kļūdu meklēšanu.

Atklāšanas gaita bija ātra: ziņojums 4. martā, CVE numurs 10. martā, GitHub.com labojums dažu stundu laikā, publisks apraksts 28. aprīlī. Kopā ar aprakstu parādījās arī publisks koncepta pierādījums, tāpēc Enterprise Server administratoriem laika logs sašaurinājās.

Ko darīt Enterprise Server administratoriem

GitHub.com un GitHub Enterprise Cloud lietotājiem darbība nav jāveic — labojums jau ir serverī. Pašmitinātajiem serveriem GitHub izlaida labotas versijas visām atbalstītajām 3.14–3.20 sērijām. The Cyber Express aicina atjaunināt uz jaunāko sērijas laidienu bez kavēšanās, jo koncepta pierādījums ir publisks un push tiesības parasti ir plašam lietotāju lokam.

Ja atjaunināšana aizkavējas, der ierobežot, kas drīkst veidot repozitorijus un veikt push, un pārbaudīt serveru žurnālus par neparastām push opcijām ar semikoliem. Ievainojamības cēlonis ir tīra ievades apstrāde — vērtība, kurai bija jāpaliek datiem, kļuva par vadības instrukciju. Semikols vienā galvenē izrādījās pietiekams, lai atvērtu GitHub iekšējo infrastruktūru.

Avoti

• Wiz — GitHub RCE Vulnerability: CVE-2026-3854 Breakdown
• The Hacker News — Researchers Discover Critical GitHub CVE-2026-3854 RCE Flaw
• The Cyber Express — CVE-2026-3854 RCE in GitHub Enterprise Server
• RH-ISAC — Critical GitHub RCE Vulnerability CVE-2026-3854