A GitLab október 21-én biztonsági frissítéseket adott ki a CVE-2026-110264 azonosítójú sérülékenységhez, és azonnali frissítésre kérte a saját üzemeltetésű rendszerek gazdáit. A 10,0 pontos CVSS-besorolású hiba a GitLab Community Edition (CE) és Enterprise Edition (EE) kiadásait egyaránt érinti, egészen a 7.0-s verzióig visszamenőleg. Így olyan régi telepítéseket is ellenőrizni kell, amelyekre az októberben korábban bejelentett kritikus CI/CD-hiba nem vonatkozott.
A sérülékenység egy speciálisan összeállított reguláris kifejezés fordításakor fellépő egészszám-túlcsordulás. Bizonyos feltételek mellett egy távoli támadó bejelentkezés nélkül tetszőleges kódot futtathat a kiszolgálón. A hibát a joaxcar néven dolgozó kutató jelentette a GitLab hibavadászprogramjában. A GitLab október 21-i biztonsági közleménye
A lehetséges kár attól függ, milyen adatokhoz és szolgáltatásokhoz fér hozzá az érintett folyamat. Egy fejlesztési platformon ez jelenthet zárt forráskódot, automatizált összeállítási folyamatokat vagy más rendszerekhez használt hitelesítő adatokat. Ezek a kiszolgáló kompromittálásának lehetséges következményei; a közlemény nem állítja, hogy ennél a hibánál forráskódlopást vagy kiadások manipulálását figyelték volna meg.
Hogyan vezethet egy szövegminta feldolgozása kódfuttatáshoz?
A reguláris kifejezések írják le, hogy egy program milyen mintát keressen a szövegben. A feldolgozóprogram a mintát kiértékelés előtt belső formára fordíthatja. A sérülékenység ebben a fordítási lépésben jelentkezik.
Egészszám-túlcsorduláskor egy számítás eredménye kívül esik azon a tartományon, amelyet a program az adott számtípussal ábrázolni tud. Ha például egy hossz kiszámításakor a program a vártnál jóval kisebb értéket kap, a későbbi műveletek hibás mérettel dolgozhatnak. Attól függően, hogy mire használják az értéket, a következmény lehet összeomlás, hibás memóriafoglalás, memóriasérülés, biztonsági ellenőrzés megkerülése vagy akár tetszőleges kód végrehajtása. A MITRE leírása az egészszám-túlcsordulásról
Ezért számít, hogy a GitLab kódfuttatási hibát jelentett be. Egy rosszul megválasztott szövegminta más körülmények között pusztán túl sok processzoridőt köthet le. Ebben az esetben a sikeres kihasználás ennél tovább mehet: a támadó az érintett kiszolgálófolyamat jogosultságaival hajthat végre műveleteket.
Melyik GitLab-verzióra kell frissíteni?
Az alábbi táblázat az október 21-én közölt első javított kiadásokat mutatja. Régebbi telepítésnél a táblázat a javítás verzióhatárát jelzi; a tényleges frissítési útvonal több kötelező köztes kiadást is érinthet. A GitLab verziólistája
| Érintett verziótartomány | A CVE-2026-110264 első javított kiadása |
|---|---|
| 7.0-tól a 18.11.13 előtti kiadásokig | 18.11.13 |
| 19.0.x a 19.0.10 előtt | 19.0.10 |
| 19.1.x a 19.1.9 előtt | 19.1.9 |
| 19.2.x a 19.2.9 előtt | 19.2.9 |
| 19.3.x a 19.3.6 előtt | 19.3.6 |
| 19.4.x a 19.4.3 előtt | 19.4.3 |
| 19.5.x a 19.5.1 előtt | 19.5.1 |
A GitLab.com a bejelentéskor már javított verziót futtatott. A GitLab Dedicated ügyfeleinél a 19.3.5-internal0, illetve a 19.4.2-internal0 vagy annál újabb megfelelő belső kiadások már tartalmazták a javítást. Ez a kivétel a Dedicated szolgáltatás belső csomagjaira vonatkozik: a saját üzemeltetésű GitLab 19.4.2 továbbra is érintett. A GitLab tájékoztatása az üzemeltetési módokról
Az ellenőrzésnél ezért a futó verzió teljes azonosítója és az üzemeltetés módja a mérvadó. Egy októberben sikeresen lezárt karbantartás önmagában még nem mutatja meg, hogy a két különálló hiba közül melyiket javították.
Az október 12-i frissítés másik sérülékenységet javított
Október 12-én a GitLab már kiadott egy maximális, 10,0 pontosra értékelt javítást. Az akkori CVE-2026-97229 a CI/CD-konfigurációban szereplő reguláris kifejezések fordítóját érintette. A GitLab szerint egy speciálisan összeállított kifejezés bizonyos körülmények között hitelesítés nélküli, tetszőleges kódfuttatást tett lehetővé. Ezt a hibát is joaxcar jelentette. A GitLab október 12-i közleménye
A korábbi hiba érintettségi tartománya a 19.2-es verzióval kezdődött. Javítása a 19.2.8, 19.3.5 és 19.4.2 kiadásokba került be. Az október 21-i sérülékenység ezzel szemben már a 7.0-s kiadástól érintette a GitLabot. Például aki október 12-én 19.3.5-re frissítette saját rendszerét, az elhárította a korábbi CI/CD-hibát, de az újabb hiba miatt ugyanezen az ágon legalább 19.3.6-ra kellett továbblépnie.
Mit igazolt a Rapid7 támadási próbája?
A Rapid7 a korábbi, CVE-2026-97229 jelű hibánál önállóan is előidézte a tetszőleges kódfuttatást egy javítatlan GitLab Community Edition példányon. A bemutatott támadáshoz előbb el kellett helyezni egy rosszindulatú .gitlab-ci.yml konfigurációt egy nyilvános projekt valamely ágában; a vizsgált esetben egy UTF-8-as karaktereket tartalmazó útvonal is szerepet játszott. A nyílt regisztráció és a saját projektek létrehozásának engedélyezése lehetőséget adhatott e feltételek teljesítésére. Ugyanaz a tesztbemenet a megfelelő javított kiadáson már nem vezetett kódfuttatáshoz. A Rapid7 eredeti vizsgálata
A vizsgálat segít értelmezni, mit jelent egy adott támadásnál a „hitelesítés nélkül” megjelölés: a kiváltó kéréshez szükséges jogosultság és a rosszindulatú tartalom előzetes elhelyezése két külön feltétel lehet. A Rapid7 eredményei azonban nem bizonyítják, hogy az október 21-i hiba is ugyanezen a CI/CD-útvonalon használható ki. Emiatt a projektlétrehozás korlátozása vagy egy CI/CD-funkció kikapcsolása nem tekinthető a CVE-2026-110264 javításának.
Milyen jeleket érdemes keresni a naplókban?
A GitLab az új hibához két észlelési szabályt tett közzé. Az Onigmo native worker crash a reguláris kifejezéseket kezelő Onigmo motorhoz köthető folyamatösszeomlást keresi. Az Org mode render error burst az Org-formátumú dokumentumok megjelenítésekor rövid időn belül megszaporodó hibákat jelzi. A szabályok a GitLab közleményének észlelésről szóló részéből érhetők el. A GitLab észlelési útmutatója
Egy összeomlás vagy hibasorozat indokolja a vizsgálatot, de önmagában nem bizonyít sikeres kódfuttatást. Érdemes összekapcsolni az esemény időpontját a beérkező kérésekkel, az alkalmazásnaplókkal és a kiszolgálón megfigyelt folyamatokkal. A riasztás hiánya sem zárja ki a próbálkozást, különösen akkor, ha a kérdéses időszakból már nincsenek meg a részletes naplók.
Gyanús eseménynél célszerű megőrizni az elérhető bizonyítékokat, majd megvizsgálni, történt-e jogosulatlan változtatás, hozzáférhetett-e valaki hitelesítő adatokhoz, és látszik-e kapcsolódó aktivitás a GitLabhoz csatlakozó szolgáltatásokban. Ezek az incidensvizsgálat kérdései; a sérülékeny verzió puszta jelenléte egyik következményt sem igazolja.
A régi telepítéseknél a köztes frissítési lépések is számítanak
Egy évekkel korábban telepített GitLabot nem feltétlenül lehet egyetlen lépésben javított verzióra emelni. A GitLab előírhat kötelező köztes kiadásokat, és a következő ilyen állomás előtt be kell fejeződniük a háttérben futó adatmigrációknak. A vállalat minden szükséges köztes állomáson az adott ághoz elérhető legfrissebb javítókiadás használatát javasolja. A GitLab frissítési útmutatója
A GitLab Upgrade Path eszköze segít a kiinduló és a célverzió közötti lépések meghatározásában. Az üzemeltetők így előre láthatják, hol kell megvárniuk egy migráció végét, és mennyi karbantartási időt kell biztosítaniuk. A kötelező lépések kihagyása üzemzavart okozhat, és megnehezítheti a helyreállítást. A GitLab frissítésiútvonal-tervezője
Jelentősen elavult telepítésnél legyen felelőse a teljes frissítésnek és annak is, hogy a köztes időszakban kik érhetik el a rendszert. A munka lezárásakor a futó verzió ellenőrzése mellett érdemes kipróbálni az alapvető műveleteket: elérhetők-e a projektek, olvashatók-e a tárolók, és rendben elindulnak-e a megszokott automatizált feladatok.
A hozzáférés szigorítása a javítás mellett segít
A GitLab általános biztonsági útmutatója a szükségtelen nyilvános regisztráció korlátozását, a többtényezős hitelesítés megkövetelését, a projektek láthatóságának felülvizsgálatát és a kérésszámkorlátok beállítását javasolja. A webhookok belső szolgáltatásokhoz való hozzáférését is célszerű azokra az esetekre szűkíteni, amikor a kapcsolat ténylegesen szükséges. A GitLab útmutatója a példányok biztonságos beállításához
Ezek az intézkedések különösen az internet felől elérhető telepítéseken csökkenthetik a visszaélés lehetőségét. A többtényezős hitelesítés azonban a bejelentkezést védi; egy hitelesítés nélkül is elérhető sérülékeny műveletet nem feltétlenül állít meg. A kérések számának korlátozása szintén kevés lehet, ha a hibát egyetlen gondosan összeállított kérés váltja ki.
A saját üzemeltetésű GitLabnál a legfontosabb ellenőrizhető eredmény az, hogy minden érintett példányon javított kiadás fut, és a gyanús korábbi eseményeket külön kivizsgálták. Ehhez a fejlesztési infrastruktúra minden példányánál tudni kell, ki felel érte, melyik verziót futtatja, és milyen kódhoz, hitelesítő adatokhoz vagy éles telepítési lehetőségekhez fér hozzá.
Eredeti cím: GitLab Patches Maximum-Severity Flaw Affecting More Than A Decade of Releases
