GitLab opravuje chybu s hodnocením 10,0: útok ale vyžaduje cestu do CI/CD

GitLab podle svého bezpečnostního bulletinu vydal 12. října 2026 opravy chyby CVE-2026-97229 se skóre CVSS 10,0 pro vlastní instalace Community Edition (CE) a Enterprise Edition (EE). Zranitelnost v kompilátoru regulárních výrazů CI/CD opravují verze 19.2.8, 19.3.5 a 19.4.2. Dotčené instalace mají být aktualizovány co nejdříve.

Rozbor Rapid7 z 13. října popisuje reprodukované spuštění kódu na neopravované verzi 19.4.1 a neúspěch stejného vstupu na opravené 19.4.2. Útočník však nejprve potřebuje možnost vložit škodlivou konfiguraci CI/CD do větve veřejného projektu. K datu zveřejnění rozboru nebylo potvrzeno zneužívání chyby při skutečných útocích.

Které instalace potřebují opravu

Rozhoduje verze běžící instance; zranitelnost se týká edic CE i EE. Dotčené jsou tři vydávací větve a každá má vlastní nejnižší opravenou verzi:

• Větev 19.2: verze od 19.2.0 do 19.2.7 jsou zranitelné; oprava je ve verzi 19.2.8.
• Větev 19.3: verze od 19.3.0 do 19.3.4 jsou zranitelné; oprava je ve verzi 19.3.5.
• Větev 19.4: verze od 19.4.0 do 19.4.1 jsou zranitelné; oprava je ve verzi 19.4.2.

Výčet platí pro self-managed nasazení bez ohledu na způsob instalace. GitLab.com již běží na opravené verzi a zákazníci GitLab Dedicated nemusí kvůli této opravě podnikat žádné kroky. Správce vlastní instance potřebuje porovnat skutečně běžící verzi s hranicí opravy v příslušné větvi: stažený balíček ještě nedokládá, že aktualizovanou verzi používá služba, která zpracovává požadavky.

Starší větev nelze zařadit mezi dotčené jen proto, že má nižší číslo než opravené vydání. Rozsah této konkrétní chyby začíná až u uvedené větve 19.2. Pro rozhodnutí o opravě je proto podstatný celý údaj o verzi, nikoli samotné hlavní číslo vydání.

Proč skóre 10,0 nevystihuje celou cestu útoku

Chyba může za určitých podmínek vést ke spuštění libovolného kódu na serveru GitLabu. Maximální hodnocení CVSS vyjadřuje závažnost zranitelnosti; neříká však, zda cizí člověk v konkrétním nasazení dokáže připravit potřebný vstup. V reprodukované cestě musel útočník zapsat do větve veřejného projektu škodlivý soubor .gitlab-ci.yml a speciálně vytvořenou cestu v repozitáři obsahující znaky UTF-8.

Upravený regulární výraz nejprve projde kontrolou při kompilaci v reprezentaci US-ASCII. Když se následně použije na připravenou cestu UTF-8, knihovna Onigmo v Ruby jej znovu kompiluje pro jiné kódování. Přetečení při výpočtu velikosti výsledného programu může vytvořit neplatné instrukce a umožnit spuštění příkazu v procesu GitLabu pod účtem git. Dopad se tedy týká serverové aplikace, nejen běžné úlohy vykonávané CI runnerem.

Označení „bez přihlášení“ se vztahuje ke spuštění zranitelné operace, ale samo nevysvětluje, jak se útočníkův soubor dostane do projektu. Na instanci, kde si nový uživatel může založit účet a veřejný projekt, lze tuto podmínku splnit prostřednictvím běžné registrace. Jestliže založení projektu nebo zápis do repozitáře podléhá schválení, musí útočník získat jinou cestu k vložení konfigurace. Omezený zápis snižuje dostupnost popsané cesty, zranitelný kompilátor však neopravuje.

Kdy je veřejná instance vystavená popsanému scénáři

Veřejná dostupnost instance a oprávnění měnit její projekty jsou dvě různé věci. První určuje, kdo se může ke GitLabu připojit; druhá, kdo dokáže připravit škodlivý vstup. Anonymní návštěvník tím, že vidí veřejný projekt, automaticky nezískává právo měnit jeho konfiguraci CI/CD. Posouzení rizika proto musí zahrnout jak přístup k instanci, tak pravidla registrace, vytváření veřejných projektů a zápisu do jejich repozitářů.

Měření Censys zveřejněné 13. října evidovalo 25 766 hostitelů a 79 224 webových služeb s verzí z dotčeného rozsahu. Hostitelé a webové služby jsou odlišné jednotky, takže jejich počty nelze sečíst jako počet instalací. Rozpoznaná verze také neukazuje, zda lze na konkrétní instanci založit veřejný projekt nebo do něj zapisovat.

1. Pokud již instance běží na opravené verzi své větve, tato chyba má nasazenou opravu. Pro případnou kontrolu dřívější aktivity je důležité vědět, kdy aktualizace začala účinkovat.
2. Pokud běží zranitelná verze a nedůvěryhodní uživatelé mohou vytvářet veřejné projekty nebo zapisovat do existujících, je popsaná cesta k vložení konfigurace otevřená. Prioritou je aktualizace.
3. Pokud je zápis omezen na prověřené účty, popsaná cesta je užší. Správce přesto potřebuje opravu a přehled o tom, kdo mohl konfiguraci v dotčeném období měnit.

Co ověřit po aktualizaci

Prvním kontrolním bodem je verze, která skutečně běží na každé vlastní instanci. U nasazení s více uzly je třeba ověřit všechny uzly obsluhující požadavky. Čas dokončení aktualizace vymezuje období, ve kterém mohl zranitelný proces připravený vstup zpracovat; instalace opravy sama o sobě nevysvětluje dřívější změny v projektech.

Kontrola historie veřejných projektů může začít u nečekaně založených projektů, změn souboru .gitlab-ci.yml a neobvyklých cest v repozitáři před instalací opravy. Nálezy je nutné porovnat s oprávněnou prací týmu a časově je spojit s přístupovými a aplikačními logy. Samotná cesta obsahující znaky UTF-8 není důkazem útoku; význam získává teprve spolu s dalšími okolnostmi.

Tento postup vychází z reprodukované cesty útoku, nejde o ověřený detekční podpis pro každé možné zneužití. Pokud historie projektu a logy ukazují podezřelou návaznost změn a serverové činnosti, má smysl uchovat příslušné záznamy a vyšetřit možný zásah do serveru. Rozhodující hranicí pro takové šetření zůstává okamžik, kdy všechny dotčené uzly začaly používat opravené vydání.

Přečtěte si také:

• AI zkracuje přípravu útoku na sekundy, staré chyby ale stále vítězí
• GitHub Actions, nebo GitLab CI: účet mění minuty, cache i runner
• TeamViewer opravuje pět vážných chyb, jedna obcházela zákaz funkcí