GitLab CVE-2026-85706 se aktivně zneužívá. Opravte vlastní instance ihned

Co je potřeba udělat hned

Pokud provozujete vlastní instalaci GitLabu (self-managed) ve zranitelné verzi, aktualizujte bez odkladu na jednu z opravených verzí:

• 19.1.8 nebo novější,
• 19.2.6 nebo novější,
• 19.3.2 nebo novější.

Chyba CVE-2026-85706 se týká GitLab Community Edition (CE) i Enterprise Edition (EE) ve verzích 18.7 až před 19.1.8, 19.2 až před 19.2.6 a 19.3 až před 19.3.2. Opravy GitLab vydal 10. září 2026. 37

Jde o mimořádně naléhavou situaci: americká agentura CISA zařadila zranitelnost 11. září do katalogu Known Exploited Vulnerabilities (KEV), tedy seznamu chyb s důkazy o zneužití v praxi. Pro dotčené civilní federální úřady USA stanovila termín nápravy na 14. září. Tento termín sice přímo nezavazuje soukromé organizace, dobře však ukazuje závažnost rizika pro každý veřejně dostupný vlastní GitLab. 3

Útočník nepotřebuje účet

CVE-2026-85706 je chyba typu path traversal v rozhraní Repository Commits API. Kombinace nedostatečného omezení cesty zadané uživatelem a chybějícího vynucení ověření umožňuje za určitých podmínek neautentizovanému útočníkovi číst libovolné soubory, k nimž má přístup služba GitLab. Hodnocení CVSS 3.1 je maximálních 10,0. 3

Jádrem problému je únik souborů, nikoli samostatně potvrzené vzdálené spuštění kódu. Přesto mohou být následky velmi vážné. Podle konfigurace serveru mohou mezi čitelnými daty být nastavení aplikace, tokeny, databázová připojení, SSH klíče či jiná tajemství dostupná procesu GitLabu. 925

Skenování začalo prakticky okamžitě

Výzkumníci z watchTowr uvedli, že v síti svých honeypotů zachytili aktivní pokusy o zneužití už 11. září. Zařazení do katalogu KEV ze strany CISA je další důležitý signál, že nejde jen o hypotetický scénář. 222

Veřejně dostupné informace potvrzují průzkum a zneužívání, neuvádějí však jednoho konkrétního pachatele, spolehlivý počet obětí ani jednotný navazující postup útočníků. To, že organizace dosud nezaznamenala incident, proto nelze považovat za důkaz, že její veřejně dostupný server nebyl prověřován nebo napaden.

Po záplatování posuďte únik tajemství

Aktualizace zastaví zranitelné chování, ale nevrátí data, která mohla být přečtena před ní. U dotčených serverů vystavených internetu je vhodné ještě před rozsáhlým úklidem uchovat důkazy a vyhodnotit, k jakým souborům měl účet služby GitLab přístup.

Přednostně prověřte a podle míry rizika obměňte zejména:

• tajemství aplikace GitLab a konfigurační údaje,
• přístupy k databázi, Redis, objektovému úložišti, registru, SMTP, adresářovým službám a poskytovatelům identity uložené v konfiguraci,
• proměnné CI/CD, deploy tokeny, access tokeny, tokeny runnerů, deploy klíče a údaje připojené pro úlohy či integrace,
• cloudové klíče, přístupy k registrům balíčků, podpisové klíče a soukromé klíče SSH či TLS dostupné hostiteli nebo procesu GitLabu.

Obměnu provádějte řízeně. Změna aplikačních tajemství nebo nastavení souvisejících se šifrováním může zneplatnit relace či narušit integrace a šifrovaná nastavení. Nejprve si proto zajistěte relevantní logy a konfigurace, připravte postup obnovy a teprve poté obměňujte nejrizikovější údaje.

Jak hledat stopy v logách

Prvotním indikátorem je HTTP požadavek POST na cestu Repository Commits API:

/api/v4/projects/<id>/repository/commits/

Zprávy doporučují hledat zejména požadavky obsahující parametr file.path. V logách reverzní proxy, load balanceru, WAF i GitLab Rails hledejte neověřené nebo neobvyklé požadavky, kódované vstupy připomínající traversal, nečekaná ID projektů, opakované chyby, pokusy o enumeraci a nezvykle velké odpovědi. 212426

Zkontrolujte také následnou aktivitu po možném okně expozice: nově vytvořené nebo použité tokeny, registrace runnerů, změny proměnných CI/CD a definic pipeline, neobvyklé importy projektů, aktivitu GraphQL či neočekávaná odchozí spojení. Doporučení k vydání zmiňují rovněž kontrolu commitů, GraphQL subscriptions, importů projektů a CI/CD pipeline. 23

Nenalezení stopy v logách není definitivním očištěním. Retence může být krátká, aplikační logování nemusí zachytit potřebné detaily a jediným použitelným záznamem mohou být údaje z proxy nebo WAF.

Pokud aktualizaci nelze provést okamžitě

Řádnou nápravou je aktualizace. Pokud ji nelze provést v nouzovém režimu hned, omezte přístup k webu a API GitLabu na VPN nebo schválené sítě. Krátkodobě může riziko snížit i striktní omezení dotčené trasy Repository Commits API na reverzní proxy nebo WAF. Může ale poškodit legitimní automatizaci a nenahrazuje záplatu.

Praktický postup pro každý dotčený server:

1. Zjistěte a seřaďte podle priority veřejně dosažitelné vlastní instance.
2. Aktualizujte na 19.1.8, 19.2.6, 19.3.2 nebo novější verzi.
3. Ověřte skutečně běžící verzi po dokončení změny.
4. Uchovejte a prověřte logy s ohledem na indikátory zneužití.
5. Obměňte potenciálně vystavená tajemství podle přístupů serveru a dopadu na provoz.

Další chyby opravené ve stejném vydání

Bezprostřední prioritou pro veřejně dostupné vlastní instalace zůstává CVE-2026-85706. Ve stejném bezpečnostním vydání se však objevily i dvě chyby specifické pro Enterprise Edition:

• CVE-2026-87719: hlášená autentizovaná chyba nebezpečné deserializace s CVSS 9,9; některé zprávy ji spojují s možným únikem konfigurace a přístupových údajů Advanced Search. 6
• CVE-2026-88765: hlášené riziko vzdáleného spuštění kódu pro autentizovaného útočníka při importu upraveného exportu projektu Git; uváděné CVSS je 8,5. 625

Tyto dvě chyby mají jiné předpoklady i dopady. Neověřená, aktivně zneužívaná možnost číst soubory přes CVE-2026-85706 by ale měla být prvním bodem při omezení rizika a reakci na incident.