GitLab avaldas turvaparandused 21. oktoobril 2026. Kuna teadaolevalt puudub turvanõrkusele toimiv ajutine lahendus, soovitab Riigi Infosüsteemi Amet (RIA) kõigil ise hallatavate GitLabi serverite kasutajatel paigaldada turvauuendused esimesel võimalusel.
22. oktoober kell 15.10 seisuga:
Rünnakutest ei ole siiani teatatud, avalikku ründekoodi ei ole leitud ja viimastel andmetel ei ole viga CISA KEV nimekirjas. Parandatud versioonid on samad.
- Lähtekoodist paigaldatud GitLab vajab eraldi tähelepanu. Kui GitLab kasutab serveri enda (süsteemi) Ruby't, siis GitLabi uuendamine viga ei paranda. Parandus on ainult GitLabiga kaasas olevas Ruby's, mis tuleb Linuxi paketi, Dockeri ja Helmi paigaldusega. Ruby enda parandus ei ole veel jõudnud Ruby 3.3, 3.4 ega 4.0 väljalasetesse.
- Org-failide kuvamist ei saa eraldi välja lülitada. Sellist seadet ei ole leitud, nii et ainus päris lahendus on uuendamine.
- Lisasoovitused kuni paigani: pange GitLabi veebiliides VPN-i või null-usalduse puhvri taha, keelake avalik registreerumine ja avalike projektide loomine.
- CVE kirje on avaldatud (NVD, 22.10, tüüp CWE-190 ehk täisarvu ületäitumine). GitLab avaldab vea täielikud üksikasjad 90 päeva pärast ehk eeldatavasti 2027. aasta jaanuaris.
Mis juhtus?
21. oktoobril 2026 avaldas GitLab parandused turvaaugule, mille kaudu saab võõras inimene ise hallatavas GitLabi serveris oma koodi käivitada, ilma et peaks sisse logima. Turvanõrkuse raskusaste on maksimaalne ehk 10 punkti 10-st (CVSS 10.0). Turvanõrkus mõjutab nii GitLabi tasuta versiooni (Community Edition) kui ka tasulist versiooni (Enterprise Edition).
Viga ei ole GitLabi enda koodis, vaid programmeerimiskeeles Ruby, millega GitLab on tehtud. Rubys on sisseehitatud osa, mis otsib ja töötleb teksti etteantud mustri järgi (nn regulaaravaldiste abil). Kui sellele anda ette eriliselt koostatud muster, läheb üks arv liiga suureks ja „keerab ümber“. Seetõttu kirjutatakse andmed mälus valesse kohta. Kuna viga on nii sügaval, ulatub see tagasi GitLabi versioonini 7.0, mis ilmus 2014. aastal.
Kuidas võib rünnak toimuda?
GitLab võimaldab veebis kuvada muu hulgas Org-vormingus tekstifaile, mis sarnanevad Markdowni vorminguga. Nende töötlemiseks kasutab GitLab teeki org-ruby. Teek võtab .org faili #+TODO: realt märksõna ja teeb sellest otsingumustri, aga sisu enne ei kontrolli. Kui märksõna kordub üle 32 767 korra, tekibki ülal kirjeldatud viga. Ründaja saab siis serveris oma koodi käivitada samade õigustega, millega töötab GitLab ise.
Rünnaku käivitamiseks ei pruugi ründajal olla vaja GitLabi kasutajakontot. Piisab, kui serveris on üks avalik projekt, kuhu on pandud pahatahtlik .org fail. Edukas rünnak ei pruugi põhjustada serveri töö katkemist, mistõttu võib see jääda märkamatuks.
Ründe tehniline kirjeldus põhineb GitLabi avaldatud tuvastusreeglitel ja Konfirmity turvateate kokkuvõttel.
Tähelepanu: 12. oktoobri turvauuendus ei kaitse uue turvanõrkuse eest
Kui uuendasite GitLabi 12. oktoobril versioonile 19.4.2, 19.3.5 või 19.2.8, on teie server endiselt haavatav. Nende uuendustega parandati teine kriitiline turvanõrkus (CVE-2026-97229), mida oli võimalik ära kasutada CI/CD seadistuste kaudu.
Turvaettevõte Rapid7 töötas selle turvanõrkuse jaoks välja toimiva ründekoodi juba järgmisel päeval pärast paranduse avaldamist. See näitab, kui kiiresti võidakse kriitilistele turvanõrkustele leida toimivaid ärakasutamisviise.
Millised versioonid vajavad uuendamist?
GitLab avaldas 21. oktoobril turvaparandused nii tasuta kui ka tasulisele versioonile. Parandused on mõeldud kõigi GitLabi paigaldusviiside jaoks.
| Kui kasutate versiooni | Uuendage versioonile | Märkus |
|---|---|---|
| 19.5 | 19.5.1 | Kõik 12 parandust |
| 19.4 | 19.4.3 | Kõik 12 parandust, uuendus muudab ka andmebaasi |
| 19.3 | 19.3.6 | Kõik 12 parandust, uuendus muudab ka andmebaasi |
| 19.2 / 19.1 / 19.0 / 18.11 | 19.2.9 / 19.1.9 / 19.0.10 / 18.11.13 | Ainult selle kriitilise vea parandus |
| 18.10 ja vanem | Parandust ei tule | Tuleb minna uuemale versioonile, see võib vajada mitut vahesammu |
Versioonid 19.5.1, 19.4.3 ja 19.3.6 sisaldavad kõiki 21. oktoobri väljalaskes avaldatud 12 turvaparandust. Vanematele versiooniharudele avaldati eraldi kriitilise turvanõrkuse CVE-2026-110264 parandus.
GitLab.com kasutajatel ei ole vaja midagi teha, sest GitLab on vajalikud turvaparandused juba paigaldanud. Ka GitLab Dedicatedi teenuses on parandused paigaldatud toetatud versioonidele.
Kas turvanõrkust on juba ära kasutatud?
22. oktoobri seisuga ei ole avalikult kinnitatud juhtumeid, kus turvanõrkust CVE-2026-110264 oleks rünnakutes ära kasutatud. Samuti ei ole see lisatud USA küberturvalisuse agentuuri CISA aktiivselt ärakasutatud turvanõrkuste nimekirja (KEV) ning avalikult kättesaadavat toimivat ründekoodi ei ole teada.
See ei tähenda siiski, et turvanõrkus oleks väiksema riskiga. Arvestades selle kriitilist raskusastet ja võimalust käivitada serveris koodi ilma autentimiseta, tuleb turvaparandused paigaldada viivitamata.
Ametlikku ajutist lahendust turvanõrkuse kõrvaldamiseks ei ole. Kuni uuendamiseni tasub võimaluse korral piirata avalike projektide ja GitLabi serveri kättesaadavust. Need meetmed võivad vähendada ründevõimalusi, kuid ei asenda turvauuendust.
Kuidas rünnakukatseid tuvastada?
GitLab on avaldanud kaks Sigma-vormingus tuvastusreeglit, mida saab kasutada logianalüüsi- ja SIEM-süsteemides. Need aitavad tuvastada järgmisi võimalikke rünnakukatsete tunnuseid:
- Org-failide kuvamise korduvad tõrked. Sama klient põhjustab 30 minuti jooksul vähemalt viis tõrget. Vastavad sündmused võivad olla nähtavad logifailis
exceptions_json.log. - GitLabi tööprotsessi ootamatu katkemine regulaaravaldise töötlemisel. Võimalikud tunnused on nähtavad logifailis
puma_stderr.log.
Kahtlaste Org-failide otsimiseks koodihoidlatest saab kasutada järgmist käsku:
rg -l --glob '**/*.org' '^\#\+(TODO|SEQ_TODO|TYP_TODO):.{500,}'
Tuvastusreeglite abil saab leida võimalikke rünnakukatseid, kuid kahtlaste sündmuste puudumine ei kinnita, et serverit ei ole rünnatud.
Kui ilmnevad märgid õnnestunud rünnakust, tuleb käsitleda serverit potentsiaalselt kompromiteerituna. Sellisel juhul tuleb muu hulgas vahetada välja serveris hoitavad saladused ja autentimisvahendid, sealhulgas CI/CD muutujates olevad saladused, GitLab Runnerite autentimistokenid, juurutusvõtmed (deploy keys) ja ligipääsutokenid.
Mida peaksid asutused ja ettevõtted tegema?
RIA soovitab kõigil ise hallatava GitLabi kasutajatel teha järgmised toimingud.
- Kaardistage kõik GitLabi serverid. Kontrollige ka Geo-koopiaid, testi- ja arenduskeskkondi ning varuservereid. Turvanõrkus võib mõjutada ka harva kasutatavaid või vähem jälgitavaid servereid.
- Kontrollige iga serveri tarkvaraversiooni. Erilist tähelepanu pöörake serveritele, mida uuendati 12. oktoobril, sest toonased parandused ei kõrvalda uut turvanõrkust.
- Paigaldage turvauuendused esimesel võimalusel. Uuendage GitLab oma versiooniharus parandatud versioonile (näiteks 19.4.x → 19.4.3). Vanemate versioonide puhul järgige tootja soovitatud uuendamisteekonda.
- Kontrollige varasemaid logisid. Rakendage GitLabi avaldatud tuvastusreegleid ka viimaste nädalate logidele, et leida võimalikke varasemaid rünnakukatseid.
Kriitilise turvanõrkuse korral ei tasu turvauuendust edasi lükata. GitLabi serverites võidakse hoida asutuse lähtekoodi, ligipääsutunnuseid ja muid tundlikke andmeid. Serveri kompromiteerimine võib seetõttu mõjutada ka teisi organisatsiooni infosüsteeme.
Allikad
Loomise kuupäev: 22.10.2026
