GitLab CE a EE: zneužívaná chyba umožňuje číst soubory ze serveru bez přihlášení

Co se stalo

GitLab je platforma, na které firmy a vývojářské týmy uchovávají zdrojový kód, spouštějí automatické sestavování a nasazování (CI/CD) a řeší úkoly. Řada organizací ho provozuje na vlastním serveru ve verzi Community Edition (CE, zdarma) nebo Enterprise Edition (EE, placená).

Výrobce 10. září 2026 vydal bezpečnostní aktualizace, které opravují 18 zranitelností. Dvě z nich jsou kritické. Nejzávažnější, CVE-2026-85706, umožňuje za určitých podmínek člověku bez jakéhokoli účtu přečíst soubory přímo ze serveru GitLabu. Druhá, CVE-2026-87719, se týká jen verze EE a vyžaduje přihlášeného uživatele s přístupem k asistentovi Duo Chat. Opravy obou chyb dostaly i starší řady, a to ve verzích 19.0.9 a 18.11.12.

První chybu útočníci skutečně zneužívají. Výzkumníci z firmy watchTowr podle SK-CERT zachytili vyhledávání zranitelných serverů už pár hodin po zveřejnění informací o chybách. Americká agentura CISA ji 11. září 2026 zařadila do katalogu zneužívaných zranitelností a evropská databáze ENISA EUVD ji od téhož dne vede jako zneužívanou. Před oběma chybami varuje i slovenský národní tým SK-CERT.

Proč je to nebezpečné

CVE-2026-85706 je chyba typu „path traversal“, tedy průchod adresáři. Představte si podatelnu, kde řeknete, který dokument chcete. Úředník má vydávat jen papíry z vaší složky, ale nekontroluje, jestli jste mu nenadiktovali adresu úplně jiného oddělení. A ani se neptá, kdo jste. Přesně tak se chová dotčená část API pro commity: špatně omezuje cestu k souboru a chybí v ní kontrola přihlášení.

Útok za určitých podmínek funguje přes internet a nepotřebuje heslo ani žádnou akci uživatele. Útočník si může přečíst například logy a konfigurační soubory. Podle SK-CERT mohou obsahovat přihlašovací údaje a kryptografický materiál. S nimi může útočník získat neoprávněný přístup do systému a pokračovat dalšími útoky. SK-CERT varuje, že to může vést až k úplnému narušení důvěrnosti, integrity a dostupnosti systému.

CVE-2026-87719 je chyba ve zpracování přijatých dat (nebezpečná deserializace). Přihlášený uživatel s přístupem k Duo Chat jí může za určitých podmínek získat konfiguraci funkce Advanced Search a citlivé přihlašovací údaje. O zneužívání této chyby se zatím neví.

CVSS: mezinárodní stupnice závažnosti od 0 do 10. První chyba má skóre 10,0, tedy maximum, druhá 9,9. Obě hodnoty přidělil výrobce GitLab.
CISA KEV: seznam zranitelností, o kterých americká agentura CISA ví, že se skutečně zneužívají. Federálním úřadům v USA nařídila opravu do 14. září 2026, tedy do tří dnů.
EPSS: odhad pravděpodobnosti, že chybu někdo zneužije v příštích 30 dnech. U CVE-2026-85706 je to k 28. říjnu 2026 přibližně 97 %, což patří k nejvyšším hodnotám vůbec. U CVE-2026-87719 je to méně než 1 %.

Koho se to týká

Týká se to GitLab Community Edition i Enterprise Edition, které si provozujete sami na vlastním serveru, virtuálním stroji nebo v kontejneru Docker. Typicky jde o firemní servery vývojářských týmů, interní Git servery agentur a softwarových firem nebo instance u poskytovatelů hostingu.

CVE-2026-85706 (CE i EE): všechny verze od 18.7 před 18.11.12, verze 19.0 před 19.0.9, 19.1 před 19.1.8, 19.2 před 19.2.6 a 19.3 před 19.3.2.
CVE-2026-87719 (jen EE): všechny verze od 18.3 před 18.11.12 a stejné řady verzí 19 jako výše. Zneužít ji může jen přihlášený uživatel s přístupem k Duo Chat.

Největší riziko mají servery dostupné z internetu, ale první chybu může zneužít kdokoli, kdo se k serveru dostane, i ve vnitřní síti. Pokud už máte opravenou verzi, ještě zkontrolujte, zda server nebyl napaden před aktualizací.

Jak zjistit, zda jste zasaženi

Nejjednodušeji zjistíte verzi v administraci: po přihlášení jako správce otevřete stránku /help na vašem GitLabu nebo přehled v Admin Area. Uvidíte číslo verze i to, zda jde o CE, nebo EE.

Na serveru s instalací z oficiálního balíčku (Omnibus) stačí jeden z těchto příkazů. Nic nemění, jen čtou:

sudo gitlab-rake gitlab:env:info

head -n 1 /opt/gitlab/version-manifest.txt

Pokud GitLab běží v Dockeru (název kontejneru upravte podle své instalace):

docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION

Výsledek porovnejte se seznamem v části „Koho se to týká“. Pokud máte například řadu 19.2 s nižším číslem opravy než 19.2.6, jste zranitelní. Zranitelná je i každá verze od 18.7 nižší než 18.11.12, u EE kvůli druhé chybě už od 18.3.

Jak to opravit

Opravené verze jsou 19.3.2, 19.2.6, 19.1.8, 19.0.9 a 18.11.12. SK-CERT doporučuje aktualizovat bez odkladu. Pokud už ve vaší řadě vyšla novější verze, nasaďte rovnou ji. Postupujte v tomto pořadí:

Nejdřív servery dostupné z internetu, potom interní.
Pokud nemůžete aktualizovat hned, dočasně omezte přístup ke GitLabu jen na důvěryhodné IP adresy (firewall, VPN). Jde o dočasné opatření podle SK-CERT, aktualizaci nenahrazuje.
Udělejte zálohu příkazem sudo gitlab-backup create a uložte si i adresář /etc/gitlab. Soubory gitlab.rb a gitlab-secrets.json běžná záloha neobsahuje.
Aktualizujte na opravenou verzi ve své řadě, například v řadě 19.2 alespoň na 19.2.6, přes správce balíčků nebo novým obrazem Docker. Pokud máte starší verzi řady 18, přejděte alespoň na 18.11.12. Při skoku o více verzí dodržte oficiální cestu aktualizace (upgrade path) od GitLabu.
Po aktualizaci znovu ověřte verzi příkazy z části „Jak zjistit, zda jste zasaženi“.
Nakonec zkontrolujte, zda jste už nebyli napadeni. Aktualizace díru uzavře, ale ukradená hesla a klíče tím zpět nezískáte.

Dostupné verze balíčku na Debianu nebo Ubuntu zobrazíte tímto příkazem:

sudo apt-get update && apt-cache policy gitlab-ee gitlab-ce

Co když už jste mohli být napadeni

Skenování zranitelných serverů začalo pár hodin po zveřejnění informací o chybách a 11. září 2026 CISA zneužívání potvrdila. Pokud byl váš GitLab dostupný z internetu a neopravený, počítejte s tím, že z něj mohl někdo číst. SK-CERT uvádí jako indikátor HTTP POST požadavky na /api/v4/projects/{id}/repository/commits/ s parametrem file.path. Hledejte je v lozích (u Dockeru v připojeném adresáři s logy):

sudo zgrep -h 'repository/commits' /var/log/gitlab/nginx/gitlab_access.log* | grep 'POST'

sudo zgrep -h 'repository/commits' /var/log/gitlab/gitlab-rails/api_json.log* | grep 'POST'

Takové požadavky posílají i běžné nástroje, které přes API vytvářejí commity. Podezřelé jsou hlavně ty z neznámých IP adres nebo bez přihlášeného uživatele. GitLab ve výchozím nastavení uchovává logy asi 30 dní, takže záznamy ze září už mít nemusíte.

Prohledejte repozitáře a hledejte citlivé údaje: účty, hesla, soukromé klíče, konfigurace VPN.
Pokud něco najdete nebo jsou logy podezřelé, tato hesla a klíče změňte v GitLabu i všude, kde se používala.
V administraci zkontrolujte nové nebo neznámé účty, přístupové tokeny, SSH a deploy klíče.
Ověřte integritu Git repozitářů a hledejte neoprávněné změny.

Pokud najdete podezřelé záznamy, logy ze září už nemáte, nebo si nejste jistí, jak vyměnit tajné klíče GitLabu, přizvěte odborníka na řešení incidentů. Incident můžete nahlásit na Slovensku SK-CERT, v Česku NÚKIB.

Zdroje

Články sestavuje AI agent z veřejných zdrojů (výrobci, CISA, ENISA, NVD, NÚKIB, SK-CERT) a čísla verzí i CVE proti nim automaticky ověřuje. Před zásahem do produkce si postup vždy ověřte v bulletinu výrobce.