Šest zranitelností Gitu: aktualizujte nejen příkazovou řádku

Pokud jste aktualizovali Git v terminálu, práce ještě nekončí: jednotlivé aplikace a buildovací prostředí mohou spouštět vlastní kopii. Projekt Git vydal 10. listopadu 2026 opravy šesti zranitelností — od spuštění kódu při rekurzivním klonování až po poškození paměti při slučování. Zkontrolovat je proto potřeba každé prostředí, které zpracovává repozitáře nebo jejich obsah, nejen výsledek příkazu git --version ve vašem shellu.

Co se v aktualizaci změnilo

Opravy jsou součástí Gitu 2.56.1 a byly přeneseny i do podporovaných řad: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 a 2.50.2. Aktualizace řeší šest problémů v různých částech Gitu — při práci s cestami, odkazy, podpisy, binárními patchi, slučováním a importními proudy. GitHub 10. listopadu zveřejnil popis zranitelností a doporučení k aktualizaci; poznámky k vydání Gitu 2.56.1 uvádějí CVE opravené v této sérii.

V praxi je třeba aktualizovat Git používaný na třech místech: na pracovních počítačích, v automatizaci a uvnitř aplikací, které obsahují vlastní sestavení Gitu. Právě na poslední bod se snadno zapomene: aktualizace systémového balíčku automaticky nezmění verzi v každém klientovi nebo buildovacím obrazu.

Proč stojí rekurzivní clone za pozornost

Nejzřetelnější scénář začíná rekurzivním klonováním nedůvěryhodného repozitáře. Kvůli zkrácení délky cesty mohl velmi dlouhý název projít kontrolou pod jedním jménem a následně se na disk zapsat v kratší podobě. V popsaném scénáři Gitu to umožňovalo nahradit soubor .git submodulu symbolickým odkazem na adresář se škodlivou konfigurací nebo hooky. Při pozdější práci s repozitářem pak Git mohl spustit kód připravený útočníkem.

Pro praxi je důležité, že jde o speciálně připravený repozitář a odpovídající operaci. Týmy, které pravidelně klonují projekty z externích zdrojů s parametrem --recurse-submodules, by měly přednostně aktualizovat klienty i automatizovaná prostředí. Oprava odmítne příliš dlouhé cesty ještě před zkrácením jejich délky.

Další místa, kde Git zpracovává nedůvěryhodná data

Další problém nastává při klonování prázdného repozitáře přes Git protocol v2. Server mohl poslat odkaz HEAD s názvem větve obsahujícím komponenty pro procházení adresářů; pozdější operace aktualizace větve pak mohla zapsat soubor mimo očekávaný adresář odkazů. Opravené verze Gitu ověřují tento cíl i další názvy odkazů získané prostřednictvím protokolu.

Samostatné zranitelnosti se týkaly operací slučování a patchů. Při zpracování podpisů počítalo pevné pole maximálně se dvěma podpisy; speciálně sestavená zpráva s větším počtem podpisů mohla způsobit zápis mimo hranice pole a poškození paměti. Při aplikaci binárního patche kontrola velikosti zohledňovala původní podobu dat, přestože se komprimovaná data mohou po rozbalení výrazně zvětšit. Git nyní před zpracováním kontroluje deklarovanou nekomprimovanou velikost.

Rozsáhlá slučování mohla také způsobit přetečení při výpočtu potřebné velikosti bufferu a následný zápis mimo jeho hranice. To se týká mimo jiné hostingových služeb a aplikací, které slučují nedůvěryhodný obsah. A konečně, tři funkce git fast-import dostaly omezení pro příkazy ze vstupního proudu: rewrite-submodules-from a rewrite-submodules-to mohly číst libovolné soubory, zatímco export-pack-edges mohl vytvářet soubory nebo připojovat data k existujícím. Tyto funkce se nyní blokují, pokud není výslovně uveden příznak --allow-unsafe-features; používat by se měl pouze u důvěryhodného generátoru proudu.

Kde hledat samostatné kopie Gitu

Vývojář může začít inventarizací míst, odkud se Git spouští. Zkontrolujte verzi v terminálu a využijte vestavěnou kontrolu aktualizací v IDE a desktopových klientech Gitu. Poté prověřte obrazy CI, kontejnery, runnery a serverové úlohy, které provádějí clone nebo merge, aplikují binární patche či spouštějí fast-import. To, že je na hostiteli nainstalovaný aktuální Git, nezaručuje, že aplikace používá právě jeho.

V organizacích je vhodné zkontrolovat nejen zdrojové obrazy, ale také již nasazená pracovní prostředí: trvalý runner nebo interní služba mohla po aktualizaci základního obrazu stále používat starý binární soubor. Pro GitHub Enterprise Server uvádí GitHub opravené verze 3.19.15, 3.20.11, 3.21.9 a 3.22.4. Společnost oznámila, že opravy již nasadila na github.com a GitHub Enterprise Cloud, včetně variant s umístěním dat. Vydání GitHub Desktop a aplikace GitHub Copilot s opraveným Gitem se koordinují; opravené verze pro Codespaces a GitHub Actions mají být rovněž teprve k dispozici.

Jak snížit riziko před aktualizací

Pokud opravu nelze nainstalovat okamžitě, dočasně omezte operace s nedůvěryhodnými daty: klonujte repozitáře pouze z důvěryhodných serverů, vyhýbejte se rekurzivnímu klonování neprověřených projektů, neslučujte jejich obsah a neaplikujte binární patche ani proudy fast-import, které z nich pocházejí. Tato opatření omezují vystavení konkrétním zranitelným scénářům, aktualizaci však nenahrazují.

Hlavní praktický závěr je jednoduchý: opravu Gitu je třeba hledat tam, kde program Git skutečně spouští. Příkaz v terminálu je jen jedním z těchto míst; vývojářské klienty, CI a služby zpracovávající repozitáře je nutné prověřit zvlášť.