Biztonsági kutatók proof-of-concept exploitot hoztak nyilvánosságra egy több GitLab-verziót érintő távoli kódfuttatási sérülékenységhez. A publikáció jelentősen növeli a kockázatot azoknál a szervezeteknél, amelyek még nem telepítették a 2026 júniusában kiadott javításokat.
A sérülékenység kihasználásával egy hitelesített GitLab-felhasználó, aki jogosult módosításokat commitolni egy projektbe, operációs rendszer szintű parancsvégrehajtást érhet el a GitLabot futtató kiszolgálón.
A támadónak ehhez nincs szüksége:
- GitLab-rendszergazdai jogosultságra;
- GitLab Runner feletti kontrollra;
- más felhasználó projektjének kompromittálására;
- rendszergazdai közreműködésre;
- arra, hogy egy másik felhasználó megnyissa a rosszindulatú tartalmat.
A támadási lánc a GitLab Jupyter Notebook fájlokhoz biztosított speciális diff-megjelenítési funkcióját és az Oj Ruby JSON-feldolgozó könyvtár két memóriabiztonsági hibáját kapcsolja össze.
Sikeres kihasználás esetén a parancsok a GitLab Puma alkalmazásfolyamatai által használt git operációs rendszerbeli szolgáltatásfiók jogosultságaival futnak.
Nyilvánosságra került a működő exploit
A depthfirst biztonsági vállalat 2026. július 24-én publikálta a sérülékenység részletes technikai elemzését és demonstrációs exploitját.
Ez körülbelül hat héttel azután történt, hogy GitLab már frissítette a problémás Oj komponenst.
A javítást tartalmazó első GitLab-verziók:
- GitLab 19.0.2
- GitLab 18.11.5
- GitLab 18.10.8
A frissítések 2026. június 10-én jelentek meg.
A probléma azért különösen érdekes patch management szempontból, mert az Oj 3.17.3-ra történő frissítése nem külön biztonsági javításként jelent meg a GitLab kiadási megjegyzéseiben.
A módosítás a normál hibajavítások között szerepelt.
Nem társult hozzá:
- külön CVE-azonosító;
- CVSS-pontszám;
- RCE-re figyelmeztető leírás.
Ezért azok a szervezetek, amelyek kizárólag CVE-feedek vagy a gyártói security táblázatok alapján priorizálták a júniusi frissítéseket, könnyen alábecsülhették a módosítás jelentőségét.
Mely GitLab-rendszerek érintettek?
A probléma a saját infrastruktúrán üzemeltetett, vagyis self-managed GitLab Community Edition és Enterprise Edition környezeteket érinti.
A licenccsomag önmagában nem jelent védelmet.
A Free, Premium és Ultimate környezetek egyaránt érintettek lehetnek.
A kutatók szerint a GitLab 15.2 és 18.9 közötti régebbi verziói szintén potenciálisan sérülékenyek, azonban ezekhez az ágakhoz életciklusuk miatt nem készült visszaportolt javítás.
Az ilyen rendszereket támogatott GitLab-verzióra kell frissíteni.
A GitLab.com szolgáltatást a javítás bejelentésekor már frissítették, a GitLab Dedicated ügyfelek számára pedig nem írtak elő külön beavatkozást.
A self-managed környezetek jelentik tehát a legfontosabb kockázati csoportot.
Nem maga a Ruby sérülékeny
A probléma nem a Ruby programozási nyelvben található.
A hibák az Oj nevű nagy teljesítményű JSON-feldolgozó könyvtárhoz kapcsolódnak.
Az Oj jelentős része natív C-kódban készült Ruby extensionként.
Ennek biztonsági szempontból fontos következménye van.
Egy hagyományos Ruby-alkalmazás memóriakezelését a futtatókörnyezet jelentős mértékben kontrollálja. Egy natív C extensionben található memóriakezelési hiba azonban olyan klasszikus sérülékenységeket hozhat létre, mint:
- out-of-bounds write;
- memóriakorrupció;
- pointerek felülírása;
- memóriacímek kiszivárgása.
A GitLab esetében pontosan ilyen hibák kombinációja vezetett el a távoli kódfuttatáshoz.
A Jupyter Notebook diff funkció biztosítja a belépési pontot
A támadási felület a GitLab Jupyter Notebook támogatásához kapcsolódik.
A Jupyter Notebook fájlokat széles körben használják:
- adattudományban;
- gépi tanulásban;
- szoftverfejlesztésben;
- kutatásban;
- kiberbiztonsági munkában.
Az .ipynb fájlok a háttérben strukturált JSON-dokumentumok.
Egy hagyományos soronkénti Git diff azonban egy ilyen dokumentum esetében nehezen áttekinthető lenne.
A GitLab ezért speciális notebook-diff funkciót biztosít, amely a JSON-adatokat ember számára könnyebben értelmezhető formában jeleníti meg.
A rendszer többek között elkülönítheti:
- a notebook celláit;
- forráskódját;
- metaadatait;
- kimeneti eredményeit.
Ehhez a GitLab egy ipynbdiff nevű Ruby komponenst használ.
Repositoryból származó adat kerül natív C parserbe
A probléma biztonsági szempontból kritikus pontja az adatáramlás.
A GitLab a repositoryban található, tehát bizonyos felhasználók által kontrollálható notebooktartalmat átadja az Oj JSON-parserének.
A feldolgozás egy hosszú ideig futó Puma worker folyamaton belül történik.
Ez lényegében a következő bizalmi határátlépést hozza létre:
projektben tárolt felhasználói adat → notebook renderer → Oj JSON parser → natív C-kód → GitLab alkalmazásfolyamat
Ha a natív parser memóriakezelése hibás, a repositoryban elhelyezett speciálisan kialakított JSON-adat már nem egyszerű dokumentumként viselkedhet.
Két különálló memóriabiztonsági hiba alkotja a támadási láncot
A kutatók nem egyetlen hibából hozták létre a távoli kódfuttatást.
Két különálló Oj-sérülékenységet kapcsoltak össze.
Az egyik hiba memóriakorrupciót tesz lehetővé.
A másik memóriacímet képes kiszivárogtatni.
A kettő kombinációja azért lényeges, mert a modern operációs rendszerek számos memóriavédelmi mechanizmust alkalmaznak.
Az egyik legfontosabb az ASLR – Address Space Layout Randomization.
Az ASLR minden folyamatindításkor változtatja a fontos könyvtárak és memóriaterületek címét, hogy a támadó ne tudja előre, hol találhatók a kihasználáshoz szükséges komponensek.
Ha azonban egy másik sérülékenység kiszivárogtat egy érvényes memóriacímet, az ASLR által biztosított bizonytalanság részben megszüntethető.
Az első hiba a túl mély JSON-struktúrák kezeléséhez kapcsolódik
Az Oj parser belsőleg nyilvántartja, hogy egy JSON-dokumentum feldolgozásakor milyen mélységben jár.
Ez szükséges például az egymásba ágyazott:
- objektumok;
- tömbök
kezeléséhez.
A sérülékeny verzióban azonban a parser nem ellenőrizte megfelelően, hogy a nesting depth továbbra is belefér-e az erre fenntartott belső memóriaterületbe.
Extrém mélyen egymásba ágyazott JSON-struktúra esetén a parser ezért a kijelölt területen kívülre írhatott.
Ez out-of-bounds write, amely szomszédos memóriaterületek sérüléséhez vezethet.
A kutatók a memóriakorrupciót irányíthatóbbá tették
Egy out-of-bounds write önmagában még nem feltétlenül jelent megbízható távoli kódfuttatást.
A kutatóknak ezért azt kellett megvizsgálniuk, hogy a sérült memória milyen további adatstruktúrákat befolyásolhat.
A részletes elemzés során olyan belső állapotot sikerült elérniük, amely végül lehetővé tette egy Oj által használt callbackhez kapcsolódó pointer manipulálását.
Ez kulcsfontosságú lépés volt a memóriakorrupció és a tényleges programvezérlés között.
Az upstream javítás nesting limiteket vezetett be annak megakadályozására, hogy a parser túllépje a számára fenntartott memóriaterületet.
A második hiba memóriacímet szivárogtathatott ki
A támadási lánc másik komponense rendkívül hosszú JSON object key-k kezeléséhez kapcsolódott.
Bizonyos szélsőséges kulcshosszak esetében egy integer-konverziós probléma miatt a parser nem a várt adatot kezelte megfelelően.
A kutatók által kialakított körülmények között ennek eredményeként egy belső pointerhez kapcsolódó adat kerülhetett vissza a feldolgozás eredményébe.
A GitLab pedig ezt a notebook diff részeként visszaküldhette a kliensnek.
Így a szerver belső memóriájáról származó információ jelent meg a HTTP-válaszban.
A memóriaszivárgás segített az ASLR megkerülésében
A kiszivárgott cím referenciapontot adott a kutatóknak a folyamat memóriatérképének meghatározásához.
Ezután következtetni tudtak olyan betöltött komponensek helyére, mint:
- Ruby runtime;
- standard C library;
- más szükséges könyvtárak.
A memóriakorrupciós primitívvel kombinálva ez végül lehetővé tette a programvezérlés eltérítését és operációs rendszer szintű parancsvégrehajtás demonstrálását.
A technikai részletek nyilvánosságra kerülése azért növeli jelentősen a veszélyt, mert a támadóknak már nem a teljes kutatási folyamatot kell önállóan végigjárniuk.
Nincs szükség külön áldozatra
A sérülékenység egyik legfontosabb tulajdonsága, hogy a támadónak nem kell rávennie egy másik felhasználót a rosszindulatú notebook megnyitására.
Sok repository-alapú támadásnál szükséges, hogy:
- maintainer megnyisson egy merge requestet;
- adminisztrátor átnézzen egy fájlt;
- valaki elindítson egy pipeline-t;
- felhasználó megnyisson egy rosszindulatú dokumentumot.
Itt azonban maga a támadó is aktiválhatja a sérülékeny feldolgozási útvonalat.
Ha jogosult commitolni egy projektbe, létrehozhatja a szükséges notebookváltozatokat, majd saját maga megnyithatja a commit diff nézetet.
Az „authenticated RCE” besorolás nem jelenti azt, hogy alacsony a kockázat
Valóban szükség van GitLab-fiókra.
Ez csökkenti a támadási felületet egy teljesen hitelesítés nélküli RCE-hez képest.
Egy vállalati GitLab-környezetben azonban több száz vagy több ezer felhasználó rendelkezhet fiókkal.
Ide tartozhatnak:
- alkalmazott fejlesztők;
- külső fejlesztők;
- beszállítók;
- alvállalkozók;
- kutatók;
- gyakornokok;
- federált identitással rendelkező partnerek.
Egy kompromittált fejlesztői fiók is elegendő lehet.
További kockázatot jelentenek azok az instance-ok, amelyek lehetővé teszik a nyílt regisztrációt vagy a személyes projektek létrehozását.
Nem feltétlenül kell érzékeny repositoryhoz hozzáférni
A támadás célja nem elsősorban a projektben található kód.
A projekt a sérülékeny GitLab szerveroldali feldolgozási funkció eléréséhez szükséges.
Ez azt jelenti, hogy bizonyos konfigurációkban a támadónak nem feltétlenül kell hozzáférnie a vállalat legértékesebb repositoryjához.
Elegendő lehet egy olyan projekt, amelyben commitjoggal rendelkezik, és amelyen keresztül elérhető a notebook-diff feldolgozás.
Ez jelentősen megváltoztatja a jogosultsági kockázat értékelését.
A kód a git szolgáltatásfiók jogosultságával fut
A demonstrált exploit nem biztosít azonnali root hozzáférést.
A parancsok a git operációs rendszerbeli felhasználó nevében futnak.
Ez azonban egy GitLab szerveren továbbra is rendkívül érzékeny biztonsági kontextus.
A GitLab alkalmazásrétege hozzáférhet többek között:
- privát repositorykhoz;
- alkalmazáskonfigurációhoz;
- szolgáltatáscredentialökhöz;
- Rails secret értékekhez;
- CI/CD-adatokhoz;
- tokenekhez;
- adatbázis-kapcsolatokhoz;
- belső GitLab-szolgáltatásokhoz.
A tényleges hozzáférés természetesen az adott infrastruktúra kialakításától függ.
A GitLab kompromittálása supply-chain kockázatot jelent
A GitLab sok szervezetnél nem egyszerű forráskód-tároló.
Központi helyet foglalhat el a teljes fejlesztési és deployment folyamatban.
Kapcsolódhat:
- CI/CD pipeline-okhoz;
- container registryhez;
- cloud deploymenthez;
- Kubernetes környezetekhez;
- artifact repositorykhoz;
- secrets management rendszerekhez;
- production deployment folyamatokhoz.
Ezért egy GitLab alkalmazásszerver kompromittálása potenciálisan a teljes szoftverellátási láncot veszélyeztetheti.
A támadó célja lehet például további hitelesítő adatok megszerzése vagy más belső szolgáltatások elérése.
A tényleges hatás erősen függ az infrastruktúrától
Nem minden GitLab telepítés jelent azonos kockázatot.
A következményeket jelentősen befolyásolja:
- konténerben fut-e a GitLab;
- milyen izolációt kap a Webservice;
- külön gépen működik-e a repository storage;
- milyen credentialök vannak elérhetőek a Puma környezetében;
- milyen hálózati kapcsolat engedélyezett;
- elérhető-e az adatbázis;
- milyen kapcsolat van Gitaly felé;
- elérhetők-e CI/CD vagy cloud credentialök.
A „csak git user” ezért nem tekinthető megfelelő kockázatcsökkentő érvnek.
A publikált PoC egy meghatározott környezetre készült
A nyilvánosságra hozott demonstrációt GitLab 18.11.3, 64 bites x86 környezetre fejlesztették.
A megbízható kihasználás több környezetfüggő tényezőre támaszkodik.
Ez azt jelenti, hogy a jelenlegi PoC nem feltétlenül működik változtatás nélkül minden sérülékeny GitLab telepítés ellen.
Ez azonban csak átmeneti technikai akadály.
A teljes kutatás és a PoC publikálása jelentősen csökkenti annak munkamennyiségét, amely egy másik buildre adaptált exploit elkészítéséhez szükséges.
A Puma újraindítása sem tekinthető javításnak
A memóriacímek a Puma folyamat újraindításakor megváltozhatnak.
Ez bizonyos exploitállapotokat érvényteleníthet.
Az újraindítás azonban nem szünteti meg az alapvető sérülékenységet.
A támadó újra elvégezheti a szükséges előkészítést.
Ezért:
Puma restart ≠ security patch.
A tényleges megoldás a sérülékeny Oj-verziót tartalmazó GitLab kiadás lecserélése.
A javítás szokatlan módon jelent meg a release notes-ban
A GitLab 2026. június 10-i patch kiadása 12 másik sérülékenységet külön security táblázatban sorolt fel.
Ezeknél szerepeltek:
- CVE-k;
- súlyossági értékek;
- érintett verziók;
- biztonsági hatások.
Az Oj 3.17.3-ra történő frissítése azonban a bug fixes között jelent meg.
Ez fontos tanulság a vállalati sérülékenységkezelés számára.
A CVE-alapú patch management önmagában nem elegendő
Ha egy szervezet kizárólag:
- CVE-adatbázisokat;
- vulnerability scanner eredményeket;
- CVSS-határértékeket
használ a frissítések priorizálására, az ilyen esetek könnyen kimaradhatnak.
A dependency update mögött ugyanis kritikus biztonsági javítás húzódhat meg akkor is, ha azt a gyártó eredetileg nem külön security advisoryként kommunikálta.
A GitLab ugyanakkor már júniusban arra kérte a self-managed ügyfeleket, hogy mielőbb frissítsenek.
Kubernetes esetén különösen fontos a tényleges alkalmazásverzió
GitLab Helm Chart vagy GitLab Operator használata esetén nem elegendő kizárólag a chart vagy az Operator verzióját ellenőrizni.
A GitLab alkalmazás verziószáma külön életciklust követhet.
A kritikus komponens a Puma folyamatot és Oj native extensiont tartalmazó Webservice image.
Az adminisztrátoroknak ezért valamennyi Webservice replika tényleges image-verzióját ellenőrizniük kell.
Vegyes verziójú Kubernetes környezetben maradhat sérülékeny pod
Egy részben végrehajtott upgrade után előfordulhat, hogy:
- bizonyos podok már javítottak;
- más podok még régi image-et futtatnak;
- rollback konfiguráció régi image-re mutat;
- secondary site régi verziót használ.
Ezért nem elegendő azt megállapítani, hogy „a GitLab frissítése megtörtént”.
A ténylegesen futó workloadokat kell inventoryzni.
Nincs megerősített aktív kihasználás
A depthfirst a technikai publikáció idején nem rendelkezett információval arról, hogy a sérülékenységet valódi támadásokban aktívan kihasználták volna.
A GitLab ugyanakkor reprodukálta a távoli kódfuttatási támadási láncot a javítás kiadása előtt.
Az aktív támadásokra utaló bizonyíték hiánya nem jelenti azt, hogy a sérülékenységet biztosan senki nem használta ki.
A helyzetet pedig jelentősen megváltoztatta a PoC publikálása.
A nyilvános exploit után nő a kockázat
A támadók számára most már rendelkezésre áll:
- részletes technikai elemzés;
- a két memóriabiztonsági hiba működésének leírása;
- GitLab-specifikus támadási útvonal;
- demonstrációs exploit;
- javítás előtti és utáni kód összehasonlításának lehetősége.
A következő logikus lépés különböző GitLab-buildre és infrastruktúrára adaptált exploitok megjelenése lehet.
Ezért az internet felől elérhető self-managed GitLab rendszereket kiemelt prioritással kell frissíteni.
Közel négy évig létezett a támadási felület
Az érintett Oj parser implementáció 2021 augusztusában került a projektbe, és az Oj 3.13.0 verzióban jelent meg.
A GitLab 2022 júliusában vezette be az érintett Oj::Parser feldolgozási útvonalat a notebookkezelésbe.
Ez a GitLab 15.2.0 környékétől tette elérhetővé a sérülékeny útvonalat.
A kutatók számítása szerint az Oj hibái 1753 napig voltak jelen a kódbázisban a javítás előtt.
A GitLabon keresztül elérhető támadási felület pedig közel négy évig létezett.
Automatizált elemzés indította el a kutatást
A depthfirst Open Defense Initiative keretében elemezte az Oj natív kódját.
Az automatizált elemzés több lehetséges problémát jelzett, amelyeket később emberi kutatók vizsgáltak meg részletesen.
A folyamat során több memóriabiztonsági problémát azonosítottak, majd ezek közül kettőt sikerült olyan módon összekapcsolni, hogy GitLabon keresztül távoli kódfuttatási láncot alkossanak.
Ez egyben jól mutatja az AI-val és automatizált kódelemzéssel támogatott vulnerability research növekvő jelentőségét.
Gyorsan reagáltak a fejlesztők
A koordinált disclosure idővonala:
- 2026. május 21. – az Oj hibáit jelentették a projektnek;
- május 27. – az Oj maintainer beolvasztotta a szükséges javításokat;
- június 4. – megjelent az Oj 3.17.3;
- június 5. – a GitLab külön értesítést kapott az elérhető RCE-láncról;
- június 8. – a GitLab megerősítette a problémát;
- június 10. – megjelent a GitLab 19.0.2, 18.11.5 és 18.10.8;
- július 17. – a GitLab lezárta a hibajelentést;
- július 24. – a depthfirst publikálta a technikai elemzést és a PoC-t.
A javítás tehát már jóval a teljes technikai részletek nyilvánosságra kerülése előtt rendelkezésre állt.
Mit tegyenek most a GitLab-adminisztrátorok?
Az első feladat valamennyi self-managed GitLab rendszer tényleges verziójának azonosítása.
Nemcsak a fő szervert kell ellenőrizni.
A vizsgálatnak ki kell terjednie:
- minden GitLab node-ra;
- Webservice containerre;
- Kubernetes podra;
- secondary site-ra;
- tartalék és rollback image-ekre.
A sérülékeny verziókat a legfrissebb támogatott GitLab kiadásra kell frissíteni.
Nem célszerű pusztán a legelső javított verzióig frissíteni, ha már újabb támogatott security release áll rendelkezésre.
Az Oj 3.17.3 a két szükséges javítást tartalmazó első verzió
Azokban a környezetekben, ahol az Oj dependency külön kezelhető, a 3.17.3 az első olyan verzió, amely mindkét szükséges korrekciót tartalmazza.
A gyakorlatban azonban itt is a legújabb kompatibilis stabil kiadás használata javasolt.
GitLab esetében elsődlegesen a támogatott GitLab-verzióra történő frissítés az ajánlott út.
A logokat is át kell vizsgálni
A frissítés mellett különösen a nagy értékű vagy internet felől elérhető GitLab rendszereknél érdemes kompromittálási vizsgálatot végezni.
Gyanús lehet:
- szokatlanul nagy
.ipynbfájl; - rendellenes notebook commit diff aktivitás;
- ugyanazon diff végpont ismételt lekérése;
- váratlan Puma worker crash;
- Puma újraindulás;
- GitLab Webservice folyamatból induló szokatlan gyermekfolyamat;
- nem várt operációs rendszer parancsvégrehajtás;
- rendellenes outbound kapcsolat;
- ismeretlen belső szolgáltatás felé induló kommunikáció.
Ezek egyike önmagában nem bizonyítja a kompromittálást, de együtt már erős indikátor lehet.
Kompromittálás gyanúja esetén application-server breachként kell kezelni
Ha hiteles bizonyíték van arra, hogy a sérülékenységet kihasználták, nem elegendő a GitLab frissítése.
Az eseményt alkalmazásszerver-kompromittálásként kell kezelni.
Az incidenskezelés része lehet:
- az érintett rendszer izolálása;
- forenzikus bizonyítékok megőrzése;
- hozzáférhető secret értékek azonosítása;
- tokenek és credentialök rotálása;
- repository-hozzáférések ellenőrzése;
- CI/CD környezet vizsgálata;
- deployment credentialök ellenőrzése;
- kapcsolódó belső rendszerek átvizsgálása.
Különösen fontos meghatározni, milyen titkokhoz férhetett hozzá a Puma/Webservice folyamat.
A hozzáférések korlátozása csak átmeneti kockázatcsökkentés
A frissítést elhalasztó szervezetek csökkenthetik a támadási felületet például:
- a nyílt regisztráció tiltásával;
- projektlétrehozási jogosultságok szűkítésével;
- külső felhasználók hozzáférésének korlátozásával;
- GitLab hálózati elérhetőségének szűkítésével.
Ezek azonban nem javítják a memóriabiztonsági hibát.
A megfelelő megoldás továbbra is a frissítés.
Összegzés
A GitLabot érintő támadási lánc azért különösen veszélyes, mert egy viszonylag alacsony jogosultságú, de commitolásra képes felhasználó által kontrollált Jupyter Notebook tartalmától egészen a GitLab alkalmazásszerverén történő operációs rendszer szintű parancsvégrehajtásig vezethet.
A lánc két Oj memóriabiztonsági problémát kapcsol össze:
memóriakorrupció + memóriacím-szivárgás → ASLR megkerülésének támogatása → programvezérlés eltérítése → RCE
A sérülékenységet különösen fontossá teszi, hogy nincs szükség arra, hogy egy rendszergazda vagy más felhasználó megnyissa a rosszindulatú tartalmat. A támadó saját maga aktiválhatja a sérülékeny notebook-diff feldolgozást.
A GitLab már 2026. június 10-én kiadta a javított verziókat, de az Oj dependency frissítése nem külön security fixként szerepelt a release notes-ban. Emiatt azok a szervezetek, amelyek kizárólag CVE- vagy CVSS-alapú patch prioritizálást alkalmaznak, könnyen figyelmen kívül hagyhatták.
A július 24-én nyilvánosságra hozott részletes technikai elemzés és PoC azonban új kockázati szintet jelent.
A self-managed GitLab rendszerek üzemeltetőinek ezért nem érdemes megvárniuk egy külön CVE-t vagy az aktív kihasználás első bizonyítékait: az érintett rendszereket a legfrissebb támogatott GitLab-verzióra kell frissíteni, és a nagy értékű vagy internet felől elérhető példányokon indokolt a korábbi gyanús notebook-diff és Puma/Webservice aktivitás visszamenőleges ellenőrzése is.
