Bezpečnostní výskumníci zverejnili funkčný proof-of-concept exploit pre zraniteľnosť umožňujúcu vzdialené spustenie kódu (RCE) v self-managed inštaláciách GitLab. Zverejnenie exploitu výrazne zvyšuje naliehavosť pre organizácie, ktoré doteraz neinštalovali opravy vydané v júni 2026.
Podstata zraniteľnosti
Reťazec útoku umožňuje autentizovanému používateľovi GitLab s oprávnením commitovať zmeny do projektu spustiť operačno-systémové príkazy na serveri, na ktorom GitLab beží. Príkazy sa vykonávajú pod servisným účtom git, ktorý používajú aplikačné procesy Puma bežiace v GitLab.
Útok nevyžaduje administrátorské oprávnenia, prístup ku GitLab Runneru, kontrolu nad projektom iného používateľa ani žiadnu interakciu zo strany administrátora. Útočník stačí, keď do projektu, ktorý smie upravovať, vloží špeciálne pripravený Jupyter Notebook a následne zobrazí diff medzi dvomi commitmi tohto súboru – tým sa spustí zraniteľná časť kódu.
Bezpečnostná spoločnosť depthfirst zverejnila 24. júla podrobnú technickú analýzu a demonštračný exploit, približne šesť týždňov po tom, čo GitLab distribuoval opravu závislej knižnice vo verziách 19.0.2, 18.11.5 a 18.10.8.
Prečo si to nikto nevšimol: oprava ukrytá medzi bežnými bugfixmi
Zraniteľnosť je pozoruhodná najmä tým, že GitLab ju v poznámkach k vydaniu z 10. júna neoznačil ako bezpečnostnú opravu. Aktualizácia knižnice Oj sa objavila v bežnej sekcii opráv chýb bez pridelenia CVE identifikátora, CVSS skóre alebo vysvetlenia, že rieši vzdialene zneužiteľný reťazec poškodenia pamäte.
GitLab napriek tomu vo vydaní uviedol, že obsahuje dôležité bezpečnostné a stabilizačné aktualizácie, a odporučil self-managed zákazníkom okamžitú aktualizáciu. GitLab.com bol v čase oznámenia už aktualizovaný, zákazníkom GitLab Dedicated bolo oznámené, že nemusia podniknúť žiadne kroky.
Tá istá séria vydaní obsahovala oddelenú tabuľku bezpečnostných opráv pre 12 ďalších zraniteľností – s CVE identifikátormi, hodnotením závažnosti aj popisom dopadu. Aktualizácia knižnice Oj v tejto tabuľke nebola. K 24. júlu 2026 tento reťazec RCE stále nemal vlastný CVE identifikátor ani verejné CVSS skóre.
Toto zaradenie má zásadný dopad na riadenie záplat: mnohé bezpečnostné tímy uprednostňujú aktualizácie na základe bezpečnostných tabuliek výrobcu, CVE feedov a výsledkov skenerov zraniteľností. Aktualizácia závislosti zaznamenaná len ako bežná oprava chyby nemusí spustiť rovnaký eskalačný proces – aj keď v skutočnosti rieši potenciálnu kompromitáciu servera. Absencia CVE tiež znamená, že skenery spoliehajúce sa výlučne na CVE detekciu nemusia zraniteľné inštalácie GitLab identifikovať.
Postihnuté produkty a verzie
Zraniteľnosť sa týka GitLab Community Edition aj Enterprise Edition, naprieč všetkými licenčnými úrovňami (Free, Premium, Ultimate).
| GitLab vetva | Stav |
|---|---|
| 19.x | Opravené vo verzii 19.0.2 |
| 18.11.x | Opravené vo verzii 18.11.5 |
| 18.10.x | Opravené vo verzii 18.10.8 |
| 15.2 – 18.9 | Potenciálne zraniteľné, bez spätne portovanej opravy (mimo aktívne udržiavaných vetiev) |
Self-managed organizácie by mali prejsť na najnovšiu podporovanú verziu GitLab, nielen na prvú opravenú verziu vo svojej vetve. Inštalácie na verziách 15.2 až 18.9 musia prejsť na podporovanú vetvu obsahujúcu Oj 3.17.3 alebo novšiu.
Samotný jazyk Ruby zraniteľný nie je – chyba sa nachádza v knižnici Oj, vysokovýkonnom JSON parseri implementovanom prevažne ako natívne C rozšírenie pre Ruby.
Ako útok funguje
Útok využíva funkciu GitLabu na zobrazovanie zmien v súboroch Jupyter Notebook. Notebook (.ipynb) je interaktívny dokument kombinujúci kód, text a výstupy, no na disku je uložený ako štruktúrovaný JSON. Zobrazenie surového JSON diffu by bolo pre používateľov nečitateľné, preto GitLab používa interný komponent nazvaný ipynbdiff, ktorý JSON obsah pred zobrazením spracuje a naformátuje.
Podľa technickej analýzy depthfirst posiela ipynbdiff obsah notebooku kontrolovaný útočníkom priamo do funkcie Oj::Parser.usual.parse – a to v rámci dlhobežiaceho procesu Puma, ktorý obsluhuje aplikáciu GitLab. Vzniká tak priama cesta z dát kontrolovaných prispievateľom projektu do natívneho C kódu bežiaceho vnútri dôveryhodného aplikačného procesu.
Útočník jednoducho vytvorí prvú verziu notebooku, commitne druhú verziu a otvorí stránku s diffom medzi commitmi – GitLab pri tom automaticky spracuje oba súbory cez zraniteľný parser. Nie je potrebné nahrávať spustiteľný program ani mať prístup k CI/CD pipeline.
Dve chyby pamäte spojené do jedného reťazca
Exploit kombinuje dve samostatné zraniteľnosti pamäte v knižnici Oj:
1. Zápis mimo hranice pri hlbokom zanorení JSON – parser Oj ukladá informácie o aktuálnej úrovni zanorenia JSON polí a objektov do pevného 1024-bajtového poľa vo svojej internej C štruktúre. V zraniteľných verziách parser nekontroloval, či zostáva v hraniciach tohto poľa, takže dokument s tisíckami zanorených polí mohol spôsobiť zápis za hranicu alokovanej pamäte a prepísanie susedných dát. Výskumníci zistili, že týmto prepisom je možné zmeniť interný pamäťový ukazovateľ a následne, manipuláciou správania alokátora pamäte, prepísať funkčný callback uložený v štruktúre parsera.
2. Únik pamäťovej adresy pri extrémne dlhých kľúčoch JSON objektov – dĺžka kľúča sa mohla nesprávne zúžiť na 16-bitovú hodnotu so znamienkom, takže hodnota 65 565 bajtov sa interpretovala ako 29. Parser za týchto podmienok vrátil dáta prekrývajúce sa s interným ukazovateľom namiesto samotného obsahu kľúča. Keďže GitLab tento výstup parsera zahrnul do vykresleného diffu, ukazovateľ sa stal viditeľným priamo v HTTP odpovedi.
Únik platnej adresy na halde je pre útok kľúčový, pretože umožňuje obísť ochranu ASLR (Address Space Layout Randomization), ktorá náhodne mení umiestnenie knižníc v pamäti pri každom spustení procesu. Vďaka tejto úniknutej adrese dokázali výskumníci určiť polohu ďalších načítaných komponentov – vrátane štandardnej C knižnice a runtime prostredia Ruby – a následne presmerovať callback parsera na funkciu system() z C knižnice, čím sa poškodenie pamäte zmenilo na spustenie systémových príkazov.
Útok nevyžaduje samostatnú obeť
Na rozdiel od mnohých útokov založených na repozitároch, ktoré vyžadujú, aby si niekto iný prezrel merge request alebo schválil pipeline, tento reťazec je priamočiary – ten istý autentizovaný používateľ, ktorý commitne notebooky, otvorí aj stránku s diffom a spustí tak spracovanie. Nie je potrebná žiadna akcia administrátora ani správcu projektu.
Jediná požiadavka je autentizovaný účet s oprávnením commitovať do projektu GitLab. Môže ísť o legitímneho používateľa s nízkymi oprávneniami, kontraktora, účet vytvorený cez otvorenú registráciu, alebo o útočníka, ktorý skompromitoval existujúce vývojárske prihlasovacie údaje. Inštancie umožňujúce vytváranie osobných projektov môžu poskytnúť cestu k zraniteľnému rendereru bez potreby prístupu k citlivému firemnému repozitáru.
Dopad: kompromitácia servisného účtu git
Úspešné zneužitie neposkytuje útočníkovi okamžite root oprávnenia – verejná demonštrácia spúšťa príkazy pod účtom git. Ten však v self-managed prostredí GitLab zastáva vysoko dôveryhodnú pozíciu a v závislosti od architektúry nasadenia môže mať prístup k citlivým aplikačným dátam a poverovacím údajom.
Potenciálne ohrozené aktíva zahŕňajú súkromne hostovaný zdrojový kód, konfiguračné dáta GitLab, Rails secrets, servisné poverovacie údaje, CI/CD informácie, podpisové materiály a tokeny dostupné aplikácii. Útočník sa tiež môže pokúsiť pripojiť k databázam, úložiskám, Gitaly uzlom alebo iným interným systémom dostupným zo skompromitovaného GitLab servera. Dopad teda nemusí zostať obmedzený na jeden hostiteľ – GitLab často slúži ako centrálny repozitár proprietárneho kódu a riadiaci bod build a deployment procesov, takže kompromitácia jeho aplikačnej vrstvy môže otvoriť cestu do širšieho softvérového dodávateľského reťazca.
Obmedzenia verejného exploitu
Zverejnený proof-of-concept bol vyvinutý pre GitLab 18.11.3 na 64-bitovej x86 platforme a spolieha sa na konkrétne charakteristiky tohto prostredia (offsety knižníc, stav registrov, správanie objektov Ruby, vzory alokácie pamäte jemalloc). Fáza vyhľadávania adries v pamäti trvala podľa depthfirst približne 5 až 10 minút na novo spustenej inštalácii s dvomi Puma workermi, na serveroch s dlhšie bežiacimi procesmi a fragmentovanejšou pamäťou až 1 až 2 hodiny. Zistené rozloženie pamäte navyše platí len počas behu daného procesu Puma – reštart procesu ho invaliduje.
Tieto obmedzenia by sa však nemali považovať za spoľahlivú mitigáciu. Podkladové chyby v Oj sa týkajú širokého spektra verzií GitLab a zverejnenie kompletnej technickej analýzy dáva ostatným výskumníkom aj útočníkom základ na prispôsobenie exploitu iným zostavám, verziám knižníc a konfiguráciám nasadenia.
Nasadenia cez Helm a Operator vyžadujú dodatočnú kontrolu
Organizácie prevádzkujúce GitLab na Kubernetes by mali overiť verziu GitLab aplikácie priamo v obraze kontajnera Webservice, nielen verziu Helm chartu alebo Kubernetes Operátora – tie používajú samostatné číslovanie a nasadenie sa môže javiť ako aktuálne na úrovni orchestrácie, pričom stále beží zraniteľný aplikačný obraz. Zmiešané prostredia môžu zostať čiastočne zraniteľné, ak aktualizácia nahradila len časť podov alebo ak starší obraz stále používa niektoré nasadenie, rollback konfigurácia alebo sekundárna lokalita.
Zatiaľ žiadne potvrdené zneužitie v praxi
Depthfirst uviedol, že v čase zverejnenia nemal informácie o zneužívaní zraniteľnosti v reálnej prevádzke. GitLab podľa spoločnosti nezávisle reprodukoval možnosť vzdialeného spustenia kódu ešte pred vydaním opravy.
Absencia zaznamenaného zneužívania však nedokazuje, že k útokom nedošlo – technika beží v rámci štandardných procesov aplikácie GitLab a nemusí spôsobovať nápadný pád procesu. Zverejnenie funkčného exploit kódu situáciu zásadne mení: verejné technické detaily môžu urýchliť vývoj prenosnejších payloadov, skenovanie vystavených inštancií GitLab aj cielenie na organizácie, ktoré júnovú aktualizáciu odložili.
Najvyššiu prioritu pri náprave by mali mať GitLab systémy dostupné z internetu, inštancie s veľkým počtom externých prispievateľov a vývojárske platformy obsahujúce hodnotný proprietárny kód.
Časová os zodpovedného zverejnenia
- 21. máj 2026 – zraniteľnosti v Oj nahlásené projektu
- 27. máj – správca Oj zlúčil opravy oboch chýb
- 4. jún – vydaná verzia Oj 3.17.3 s opravami
- 5. jún – depthfirst súkromne nahlásil dosiahnuteľný RCE reťazec v GitLab
- 8. jún – GitLab potvrdil zraniteľnosť
- 10. jún – GitLab vydal verzie 19.0.2, 18.11.5 a 18.10.8
- 17. júl – GitLab označil hlásenie za vyriešené
- 24. júl – depthfirst zverejnil analýzu a proof-of-concept kód
Zraniteľná implementácia parsera sa v Oj nachádzala od augusta 2021 (prvýkrát distribuovaná v Oj 3.13.0). GitLab zaviedol volanie Oj::Parser.usual.parse do procesu validácie notebookov v júli 2022 (GitLab 15.2.0) – cesta k zraniteľnosti tak bola dosiahnuteľná takmer štyri roky (1 753 dní) pred zlúčením opravy.
Odporúčania pre administrátorov
- Okamžite identifikujte presnú verziu aplikácie GitLab na každom uzle a v každom kontajneri (vrátane obrazov Webservice pri Kubernetes nasadeniach) a aktualizujte na najnovšiu podporovanú verziu.
- Pri samostatnej správe knižnice Oj použite verziu 3.17.3 alebo novšiu.
- Skontrolujte prístupové a aplikačné logy GitLab – zamerajte sa na neobvykle veľké súbory Jupyter Notebook, opakované požiadavky na endpointy diffu notebookov, neočakávané pády alebo reštarty Puma workerov a anomálne príkazy či odchádzajúce sieťové spojenia z procesov Webservice.
- Keďže úspešné zneužitie môže odhaliť poverovacie a podpisové materiály, pri dôveryhodných indíciách kompromitácie postupujte ako pri narušení aplikačného servera – izolujte postihnutý hostiteľ, zachovajte forenzné dôkazy, rotujte dostupné tajomstvá a tokeny, preskúmajte prístupy k repozitárom a skontrolujte prepojené CI/CD a interné systémy.
- V súčasnosti neexistuje oficiálne podporované dočasné riešenie pre organizácie, ktoré nemôžu okamžite aktualizovať. Obmedzenie nedôveryhodnej registrácie účtov, zúženie oprávnení na vytváranie projektov a obmedzenie prístupu k self-managed GitLab môžu znížiť expozíciu, ale neopravujú zraniteľný parser a nemali by nahrádzať samotnú aktualizáciu.
Záver
Kombinácia dvoch chýb pamäte v bežne používanej JSON knižnici, takmer štvorročná dosiahnuteľnosť zraniteľnej cesty a najmä spôsob, akým bola oprava komunikovaná – ako bežný bugfix bez CVE či bezpečnostného upozornenia – robí z tohto prípadu výraznú pripomienku, že prioritizácia záplat len na základe oficiálnych bezpečnostných tabuliek a CVE feedov nemusí stačiť. Organizácie prevádzkujúce self-managed GitLab by mali overiť skutočne nasadenú verziu aplikácie priamo, nespoliehať sa na výsledky skenerov závislých od CVE, a s aktualizáciou na opravenú verziu nečakať.
Viac informácii:
https://www.linkedin.com/pulse/critical-gitlab-flaws-enable-remote-code-execution-ci0oe
https://thehackernews.com/2026/07/researcher-publishes-gitlab-rce-poc.html