GitLab zapira kritično luknjo: nadgradnja je edina obramba

GitLab je 12. oktobra 2026 v kritičnem varnostnem obvestilu objavil popravke za CVE-2026-97229 v izdajah Community Edition (CE) in Enterprise Edition (EE): 19.2.8, 19.3.5 in 19.4.2. Ranljivost v samostojno upravljanih namestitvah ima oceno CVSS 10,0 in lahko pod določenimi pogoji omogoči izvajanje poljubne kode na strežniku brez prijave. Skrbniki prizadetih namestitev morajo ugotoviti, katera veja deluje pri njih, in namestiti ustrezno popravljeno izdajo.

Analiza Rapid7 pojasnjuje pomemben pogoj: napadalec mora najprej spraviti zlonamerno konfiguracijo CI/CD v repozitorij javnega projekta, nato pa lahko sproži ranljivo obdelavo brez prijave. Izvajanje kode je bilo ponovljeno na izdaji 19.4.1, na popravljeni 19.4.2 pa isti vhod ni uspel. GitLab.com že uporablja popravljeno različico, uporabnikom GitLab Dedicated pa za ta popravek ni treba ukrepati.

Kako konfiguracija CI/CD doseže strežnik

Napaka je v prevajalniku regularnih izrazov, ki obdeluje izraze iz konfiguracije CI/CD. Posebej oblikovan izraz najprej prestane preverjanje, pri poznejši obdelavi poti v repozitoriju pa se lahko zaradi prekoračitve celoštevilske vrednosti prevede v napačna navodila. Možni izid je izvajanje napadalčeve kode v procesu GitLaba na strežniku, ne zgolj napaka v opravilu cevovoda.

V ponovljenem napadu je bila zlonamerna konfiguracija v datoteki .gitlab-ci.yml, veja javnega projekta pa je vsebovala posebej oblikovano pot z znaki UTF-8. Izraz se je najprej prevedel za kodiranje US-ASCII, ob obdelavi poti pa ga je Rubyjev mehanizem Onigmo prevedel znova. Ker je do tega prišlo po prvotnem preverjanju, je napačen izračun velikosti programa omogočil izvajanje ukaza s pravicami GitLabovega sistemskega uporabnika git. To je preizkušena pot napada, zato omejevanje samo te poti ne odpravi napake v programski opremi.

Ocena CVSS 10,0 označuje najvišjo stopnjo resnosti in možen učinek ranljivosti, ne števila že napadenih namestitev. Ob objavi analize ni bilo potrjene zlorabe te ranljivosti v dejanskih napadih. Za skrbnika je bistveno, da oznaka »brez prijave« opisuje sprožitev ranljive obdelave; pred tem mora biti zlonamerna konfiguracija na dosegljivi poti v repozitoriju.

Popravljena izdaja za posamezno vejo

Matrika popravkov za CVE-2026-97229 zajema izdaji CE in EE ter vse vrste samostojne namestitve. Ciljna različica je odvisna od veje, ki že teče na strežniku. Če je nameščena izdaja v spodaj navedeni veji starejša od njene meje, jo je treba nadgraditi:

• Veja 19.2: različice pred 19.2.8; ciljna izdaja je 19.2.8.
• Veja 19.3: različice pred 19.3.5; ciljna izdaja je 19.3.5.
• Veja 19.4: različice pred 19.4.2; ciljna izdaja je 19.4.2.

Pri veji 19.3 je treba paziti na izdajo 19.3.4. Aktualna ciljna izdaja je 19.3.5, ker je imela 19.3.4 napako na straneh zahtevkov za združitev, kadar je bila vključena integracija Ona. Skrbnik, ki je namestil 19.3.4, naj zato preide na trenutno priporočeno izdajo, tudi če je nadgradnjo opravil takoj po prvem obvestilu.

Te meje opisujejo CVE-2026-97229; za starejše veje objavljena matrika ne navaja ločenih popravljenih izdaj. Skrbnik starejše namestitve mora zato določiti pot do podprte, popravljene izdaje, namesto da bi iskano rešitev pripisal svoji sedanji veji. Različica v pregledu je cilj za odpravo opisane ranljivosti v ustrezni veji, ne splošno zagotovilo o stanju vseh drugih popravkov.

Kako ugotoviti, katera različica dejansko deluje

GitLabova navodila za različico za samostojno upravljano namestitev določajo preprost postopek: prijavljen uporabnik na dnu levega stranskega menija izbere Help > Help, številka različice pa je prikazana na vrhu strani. Prikazani podatek je treba primerjati z mejo za isto vejo v pregledu. Če je rezultat denimo 19.4.1, gre za različico pred popravljeno 19.4.2; pri veji 19.3 je meja drugačna.

Preverjanje v samem GitLabu je pomembno tudi po namestitvi popravka. Prenesen paket, pripravljen namestitveni načrt ali zaključen poseg še ne povejo, katera različica trenutno odgovarja uporabnikom. Če organizacija upravlja več samostojnih namestitev, ima vsaka svojo prikazano različico in svojo pot nadgradnje. Tako se skrbnik izogne sklepu, da popravek ene namestitve velja tudi za druge.

Zakaj sprememba nastavitev ne odpravi napake

Omejitev samostojne registracije ter ustvarjanja ali spreminjanja javnih projektov lahko oteži pot, po kateri je bila zlonamerna konfiguracija vnesena v ponovljenem napadu. Tudi omejitev anonimnega dostopa do javnih projektov lahko zmanjša izpostavljenost tej poti. Takšne nastavitve pa ne popravijo prevajalnika regularnih izrazov, v katerem nastane prekoračitev; ranljiva različica ostane ranljiva.

Razlika je praktična: nastavitve vplivajo na to, kdo lahko pripravi pogoje za znano pot napada, medtem ko popravek spremeni programsko opremo, ki napačno obdeluje izraz. Če lahko zlonamerno konfiguracijo v repozitorij vnese nekdo z že obstoječim dostopom, zgolj izklop nove registracije tega ne prepreči. Zmanjšanje dostopa lahko zato pomaga med pripravo nadgradnje, ne more pa biti končni ukrep za odpravo CVE-2026-97229.

Kdo mora namestiti popravek

Nadgraditi morajo organizacije, ki same upravljajo prizadeto izdajo GitLab CE ali EE. To vključuje tudi namestitev, ki teče pri ponudniku oblaka, če za njeno programsko opremo skrbi organizacija sama. Odločilna ni lokacija strežnika, temveč to, kdo upravlja GitLabovo namestitev in katera različica na njej dejansko deluje.

Pri GitLab.com je popravek že vključen v storitev, uporabnikom GitLab Dedicated pa za to izdajo ni treba opraviti posega. Za samostojno upravljano namestitev ostane odločilen rezultat preverjanja po nadgradnji: dokler aplikacija prikazuje izdajo pod mejo svoje veje, odprava te ranljivosti na tej namestitvi ni zaključena.

Preberite tudi:

• GitLab CI ali Jenkins: hitrejši cevovod lahko zahteva več vzdrževanja
• GitHub Actions ali GitLab CI: brezplačne minute skrivajo drugačen strošek
• Osavul je zbral 8,5 milijona € in cilja na kritično infrastrukturo