Co se stalo
GitLab je platforma, ve které firmy uchovávají zdrojový kód, spravují projekty a spouštějí automatické sestavování a nasazování aplikací (CI/CD). Řada organizací ho provozuje na vlastním serveru.
21. října 2026 vydal GitLab mimořádné opravné verze pro Community Edition (CE) i Enterprise Edition (EE). Nejzávažnější z opravených chyb, CVE-2026-110264, může za určitých podmínek umožnit útočníkovi bez přihlášení spustit na serveru libovolný kód. Chyba je v kompilátoru regulárních výrazů, tedy vzorů pro vyhledávání v textu.
Výrobce doporučuje okamžitě aktualizovat všechny instalace na vlastních serverech. CERT-EU, tým kybernetické bezpečnosti institucí EU, vydal 22. října 2026 varování se stejným doporučením. Potvrzené případy zneužití zatím nejsou známé, GitLab ale zveřejnil pravidla pro odhalení pokusů o útok.
Proč je to nebezpečné
Jde o přetečení celého čísla (integer overflow). Představte si starý tachometr, který po 999 999 kilometrech skočí zpátky na nulu. Při kompilaci speciálně připraveného regulárního výrazu se podobně „přetočí“ číslo, se kterým program počítá, a program pak pracuje se špatnou hodnotou. Za určitých podmínek tak útočník může na serveru spustit vlastní kód.
Podle hodnocení výrobce útok nevyžaduje přihlášení ani žádnou akci uživatele a vede se po síti. Pokud je váš GitLab dostupný z internetu, může to zkusit kdokoli. Útočník, který takto spustí kód na serveru s GitLabem, se může dostat ke zdrojovému kódu, přihlašovacím údajům uloženým v CI/CD a klíčům pro nasazování a často i do dalších firemních systémů.
Skóre CVSS hodnotí závažnost na stupnici od 0 do 10. GitLab této chybě přidělil 10,0, tedy maximum. EPSS odhaduje pravděpodobnost zneužití v příštích 30 dnech. K 28. říjnu 2026 je to přibližně 1 %, což je více než u zhruba 63 % známých zranitelností. Katalog CISA KEV eviduje chyby, které jsou prokazatelně zneužívány. Tato v něm zatím není, to ale neznamená, že jste v bezpečí.
Koho se to týká
Zasaženy jsou instalace GitLab CE i EE na vlastních serverech (self-managed) ve verzích:
- od 7.0 před 18.11.13
- 19.0 před 19.0.10
- 19.1 před 19.1.9
- 19.2 před 19.2.9
- 19.3 před 19.3.6
- 19.4 před 19.4.3
- 19.5 před 19.5.1
Týká se to všech typů nasazení: balíčků Omnibus, instalací ze zdrojového kódu, kontejnerů Docker i Helm chartu. Typicky jde o firemní servery vývojářských týmů, softwarových dodavatelů, škol a úřadů.
Uživatelů GitLab.com se to netýká, ten už běží na opravené verzi. Zákazníci GitLab Dedicated na verzi 19.3.5-internal0, 19.4.2-internal0 nebo novější opravu už mají a nemusí nic dělat.
Jak zjistit, zda jste zasaženi
Nejjednodušší je přihlásit se jako administrátor a otevřít administraci (Admin area). Verze je hned v přehledu. Najdete ji také na stránce /help vaší instance.
Na serveru s balíčkem Omnibus verzi zjistíte příkazy, které nic nemění:
sudo gitlab-rake gitlab:env:infosudo cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONU Dockeru (název kontejneru upravte podle sebe) a u Kubernetes s Helmem:
docker exec gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSIONhelm list -A | grep -i gitlabVýsledek porovnejte se seznamem zasažených verzí. Každá verze nižší než 18.11.13 je zasažená. V řadách 19.0 až 19.5 jste zasaženi, pokud máte nižší verzi, než je opravená verze vaší řady. U Helmu sledujte sloupec APP VERSION.
Jak to opravit
Opravené verze jsou 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 a 18.11.13. Aktualizujte na opravenou verzi ve své řadě, například z 19.4 na 19.4.3. Pokud máte verzi nižší než 18.11.13 ze starší řady, opravená verze pro vaši řadu neexistuje. Aktualizujte alespoň na 18.11.13 a projděte přitom povinnými mezikroky, které ukáže nástroj GitLab Upgrade Path.
Doporučený postup:
- Nejprve aktualizujte servery dostupné z internetu, doporučuje to i CERT-EU.
- Udělejte zálohu příkazem
sudo gitlab-backup createa uložte si i soubory/etc/gitlab/gitlab-secrets.jsona/etc/gitlab/gitlab.rb. Běžná záloha je neobsahuje. - U balíčku Omnibus na Debianu nebo Ubuntu spusťte
sudo apt-get updatea potomsudo apt-get install --only-upgrade gitlab-ee(nebogitlab-ce). Tak získáte nejnovější verzi. Pokud chcete zůstat ve své řadě, zadejte konkrétní verzi, napříkladsudo apt-get install gitlab-ee=19.4.3-ee.0. - U Dockeru stáhněte image s opravenou verzí a kontejner vytvořte znovu. U Helmu nasaďte chart s opravenou verzí GitLabu.
- Po aktualizaci ověřte verzi stejně jako v části o kontrole.
GitLab ve svém oznámení neuvádí žádné dočasné řešení, jedinou opravou je aktualizace. Dokud ji nenainstalujete, můžete jako obecné opatření povolit přístup ke GitLabu z internetu jen přes VPN nebo z povolených IP adres. Chybu to ale neodstraní. Aktualizace zároveň opravuje dalších 11 chyb, z toho 2 s vysokou závažností.
Co když už jste mohli být napadeni
GitLab zveřejnil dvě pravidla pro odhalení pokusů o zneužití: „Onigmo native worker crash“ a „Org mode render error burst“. Podle názvů sledují nečekané pády pracovních procesů při zpracování regulárních výrazů (Onigmo je knihovna pro regulární výrazy) a náhlé série chyb při zobrazování dokumentů ve formátu Org. CERT-EU doporučuje prověřit, zda některý server nebyl kompromitován, a odkazuje přitom právě na tato pravidla.
Na co se podívat (příkazy jen čtou). První příkaz prohledá logy procesů Puma a Sidekiq včetně starších komprimovaných souborů a hledá záznamy o pádu procesu („Segmentation fault“ nebo „[BUG]“). Druhý vypíše procesy běžící pod uživatelem git.
sudo sh -c 'zgrep -iE "segmentation fault|\[BUG\]" /var/log/gitlab/puma/puma_stderr.log* /var/log/gitlab/puma/current /var/log/gitlab/sidekiq/current /var/log/gitlab/sidekiq/@*'ps -u git -o pid,etime,cmd- Neznámé administrátorské účty, nové přístupové tokeny a SSH klíče.
- Nové runnery, webhooky a deploy klíče, které nikdo z vás nepřidal.
- Neznámé procesy pod uživatelem
gita nečekaná odchozí spojení.
Pokud najdete podezřelé stopy, odpojte server od sítě, nic nemažte a přizvěte odborníka na řešení incidentů. Po kompromitaci je nutné změnit všechna hesla, tokeny a klíče uložené v GitLabu včetně proměnných CI/CD.