GitLab waarschuwt voor kritiek beveiligingslek met CVSS-score van 10.0

GitLab waarschuwt voor een kritieke kwetsbaarheid in GitLab Community Edition en Enterprise Edition. De kwetsbaarheid is aanwezig in versies ouder dan 19.2.8, 19.3.5 en 19.4.2. Het lek heeft de hoogste CVSS3.1-score van 10.0 gekregen.

De kritieke kwetsbaarheid is een integer overflow en staat geregistreerd als CVE-2026-97229. Door het lek kunnen hackers via een kwaadaardige CI/CD-configuratie op afstand code op een GitLab-server uitvoeren. Dat kan via een speciaal geconstrueerde regex. GitLab controleerde deze opdrachten niet strikt genoeg.

GitLab heeft naast de kritieke kwetsbaarheid nog 23 andere gaten gedicht. Het Nationaal Cyber Security Centrum (NCSC) adviseert gebruikers de patches op korte termijn te installeren. GitLab patchte een maand geleden ook een kwetsbaarheid met een CVSS-score van 10.0.

Het logo van GitLab. Bron: Thomas Fuller/SOPA Images/LightRocket via Getty Images (afbeelding ter illustratie)

Reacties (38)

[Cristan]

Kan iemand me vertellen waarom dit een score 10.0 heeft gekregen? Het is niet alsof een willekeurige buitenstaander een CI/CD-configuratie kan uploaden. Dan heb je toch al best wat rechten voor nodig om dat te mogen.

[Stetsed]

Het ding is dat het well Arbitrary Remote Code Execution kan geven. Het uploaden van een CI/CD configuration is een ding, dit kan een reguliere gebruiker toevoegen aan hun repo. Dit betekent dus dat voor de gemiddelde gebruiker de complexity low is, en dat de attack vector Network is. Die brengen het all snell omhoog.

Dit is geen veiligheidslek als je er vanuit gaat dat je een enkele server draait voor jezelf en een bedrijf. Maar laten we zeggen dat niet all je gebruikers compleet vertrouwd zijn. Bijvoorbeeld de publieke gitlab of free desktop etc. Of dat er ergens een leaked key die kan pushen, is dit openeens veel gevaarlijker. Voor reference de volledige CVE classification is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Dus attack vector network, attack complexity low, privileges required none, no user interaction, scope changed, high impact on confidentiality, integrity en availability. Dus eigenlijk is het vanuit een CVE scoring letterlijk het ergste wat er is.

Maar je moet herinneren dat CVE severity niet direct iets te maken heeft met exploitability, dat is het verschil tussen “kan het gevaarlijk zijn” en “is het gevaarlijk”. In deze situatie ligt dat dus heel erg aan wie toegang heeft tot de server. Maar als het een publiek instance is is dat antwoord JA. Want het compromised dus niet alleen voor jou de gebruiker, maar geeft je toegang tot de machine waar het op draait.

Note: Het bovenstaande gaat er vanuit dat het via een uploaded CI/CD file moest gaan, echter blijkbaar en dit is ook logisch door de “Privilege Requirment” van None, dat zelfs dit blijkbaar niet nodig is. Er is op dit moment nog geen publicatie van hoe dit precies werkt en wat wordt aangetast. Dus het kan zelfs zijn dat servers die privé zijn aangetast zouden kunnen worden

[Reactie gewijzigd door Stetsed op 13 oktober 2026 19:26]

[Blokker_1999]

Zelfs binnen in een bedrijf zou ik dit aanzien als een ernstig lek dat zo snel mogelijk gedicht moet worden want in een bedrijf heb je ook gewoon insider risk. Een medewerker die zich niet goed behandelt voelt kan veel schade aanrichten in vele bedrijven. Maar ook een hacker die ergens met beperkte rechten op zoek is naar manieren om die rechten te verhogen kan van dit soort aanvallen gebruik maken.

Gebruik je het thuis, voor jezelf, zonder dat iemand anders er aan kan? Dan heb je wel een punt, en is het lek niet echt ernstig te noemen.

[Stetsed]

Dat was eigenlijk mijn punt met de “of dat er ergens een leaked key is”. Als er iemand met de rechten is om Actions te modificeren(of zelfs unauthorized zoals er in de post staat, maar ik vindt het raar dat een unauthorized user CI/CD configs zou kunnen veranderen… maar kan geen publieke diff/POC vinden), dan is het eigenlijk equivalent aan toegang tot het systeem op het niveau dat gitlab draait. Dus daaruit ben ik het met je eens, zelfs als je het thuis alleen draait is dit het soort ding waar ik zeg “Maakt niet uit, update gewoon”

Maar het komt natuurlijk altijd neer dat CVSS score je alleen vertelt hoe gevaarlijk het kan zijn, maar je moet er altijd nog zelf naar kijken. Een beetje in dezelfde manier dat wanneer je een scan doet op een container je vaak dozijnen/honderden reacties krijgt, maar veel hebben helemaal geen impact op de configuratie. Het vereist altijd dat er naar wordt gekeken en welke acties ondernomen worden. Maar in deze situatie is het duidelijk een bruikbare kwetsbaarheid en moet je dus eigenlijk gewoon updaten.

Note: Toevoeging dat de Privilege Requirment none is, dit zou aangeven dat geeneens dit nodig is en dat je op elke publieke instance het zou kunnen doen. De vraag is dan natuurlijk hoe je de CI/CD config aantast, dit is echter nog niet gepubliceerd zover ik kan zien en weerhouden ze voor nu.

[Reactie gewijzigd door Stetsed op 13 oktober 2026 19:24]

[Raymond Deen]

Mooi opgeschreven, maar even een oprechte vraag (serieus!): hoeveel hiervan komt uit ai? Ik zie nogal wat gekke schrijffoutjes in je tekst.

[Stetsed]

Absoluut 0 komt uit AI en ik heb het ook niet gebruikt voor spellings controle. Moet ook zeggen dat het zeker kan zijn dat er ook wat Engels en Nederlands door elkaar lopen want zo denk ik in mijn hoofd. Dus alles wat raar leest is gewoon mijn eigen fouten xD

[Reactie gewijzigd door Stetsed op 14 oktober 2026 08:33]

[springtouwtje]

[Raymond Deen]

Helemaal ok hoor. Het viel me gewoon op dat deze reactie best afweek van je andere reacties waar die spelfoutjes niet in voor komen. Maar dat kan ook komen door hoe mijn brein dan weer werkt😜

[joco]

die zijn dan zeker allemaal AI

[MoonWatcher]

Best mogelijk dat er AI bij gebruikt is bij het vinden van de exploit. Maar de whitehat dit gevonden heeft vind zeer veel gitlab exploits en heeft een goede reputatie op dit vlak.

https://hackerone.com/joaxcar?type=user

Dus ga er maar van uit dat deze goed is uitgezocht. Ook als je kijkt naar de meeste voorgaande sub releases dan zijn vrijwel alle grote CVEs van hem.

Als je Gitlab draait moet je eigenlijk elke dag checken voor een update en het zo snel mogelijk doorvoeren op dit moment. Het product ligt aardig onder vuur.

[Gotiniens]

Je kan externe CI/CD templates includen, als deze aangepast worden kan je via die weg gecompromitteerd worden.

include:
- remote: 'https://other-gitlab.example.com/my-group/templates/-/raw/main/ci.yml'
- remote: 'https://raw.githubusercontent.com/org/templates/main/ci.yml'

[tszcheetah]

Als dat nodig is, is de 10.0 score ergens ook wel een storm in een glas water. Als je externe CI templates gebruikt is er altijd het risico dat die aangepast worden en bijvoorbeeld secrets gaan wegsluizen. Sowieso kan zo'n template onderdelen bevatten dat code uitvoert op de runner, want dat is het hele doel van CI/CD. Oftewel: je moet al je externe bronnen hoe dan ook vertrouwen voordat je ermee aan de slag gaat.

Het verschil met dit lek lijkt me te zijn dat de code execution op de gitlab server zelf, in plaats van in de context van een runner, plaatsvindt. Dat maakt de impact wel groter, maar met includes die ongecontroleerd aangepast kunnen worden blijf je een groot risico hebben.

Daarom dus ook het advies om externe bronnen vast te zetten op bijv. een commit sha. Mocht de main branch dan ooit malafide code bevatten, ben je niet meteen de pineut. Nadeel is natuurlijk wel dat updates wat moeite vereisen.

[spoordressing]

Wat belet jou om op gitlab.com, of een andere publieke instantie, een repo aan te maken en daar dingen te doen met CI? Op gitlab.com in ieder geval niets.

[Reactie gewijzigd door spoordressing op 13 oktober 2026 18:59]

[GertMenkel]

De beoordeling waar iedereen die iets met CVE's doet naar zou moeten kijken is hier CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H (van CVE.org gehaald); dat laat zien hoe erg het risico en de impact echt zijn. De score van 1 tot 10 is niet iets waar je wat mee kan, behalve misschien sorteren als je meerdere CVE's aan het oplossen bent (maar je moet ze alsnog allemaal door).

Je kunt dit invullen op deze website en met de score spelen: https://www.first.org/cvss/calculator/3.1#CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Mijn persoonlijke mening is dat dit, omdat het een account vereist en daarom wel degelijk privileges nodig heeft, PR:L zou moeten zijn. Dan zou je op een CVSS3.1 score van 9.9 uitkomen.

edit:
Onderste paragraaf was fout; volgens cve.org kan een ongeauthoriseerde gebruiker de exploit ook triggeren.

[Reactie gewijzigd door GertMenkel op 13 oktober 2026 19:17]

[Keypunchie]

Die 10.0 moet je niet blind op afgaan. Helemaal nu met de golf aan AI bugs, zitten er veel tussen die eigenlijk heel erg meevallen, alleen door de manier waarop de score wordt berekend (zeer) hoog uitvallen.

Zo loopt de maker van cURL er vrij vaak tegen te hoop. En in een blogje heeft hij het voorbeeld van een CVE die op 9.1 was gezet, die hij zelf volgens eigen berekening van de CVSS score een 5.4 gaf, en die uiteindelijk op een 3.4 is uitgekomen.

En dat is niet uniek. CVE-2025-68121, krijgt bvb. afhankelijk van je bron alles van een 4.8 tot en met een 10.0...

[dasiro]

da's volgens de bron wel wat er gebeurt:

under certain conditions, could have allowed an unauthenticated user to execute arbitrary code on the GitLab server

welke die conditions zijn staat er waarschijnlijk heel bewust niet bij, maar ik ga er van uit dat een server niet standaard zo geconfigureerd staat.

[MichielHimself]

Dit is het type lek dat gebruikt wordt om backdoor kwetsbaarheden in broncode te installeren zonder dat de eigenaren van die code / software het in de gaten hebben.

Een voorbeeld van wat voor gevolgen dat kan hebben: SolarWinds hack timeline

De aanname "binnen mijn netwerk is alles en iedereen 'veilig'" moet je al lang niet meer maken, zeker niet in (middel)grote / corporate omgevingen.

[Reactie gewijzigd door MichielHimself op 14 oktober 2026 09:57]

[hamsteg]

Volgens CVSS3.1moet je ook wat meer doen dan alleen hierop reageren. De CVSS3.1 vulnerability scanning bestaat grofweg uit 3 delen:
1. Globale assessment (door de NVD)
2. Systeem impact / Omgeving assessment (door het eigen bedrijf)
3. Zoals @Stetsed aangeeft de exploitability itself: "is het gevaarlijk"

De globale assessment is een eerste indicatie om wel of niet actie te ondernemen. Wij hebben bijvoorbeeld als stelregel dat een CVSS3.1-score lager dan 6, geen aandacht behoeft (graag geen discussie, is gewoon een uitgangspunt met en behoorlijke rationale daaronder).

Als systeem eigenaar moet je zeker daarna nog de eigen assessment doen, daar waar van toepassing. Mogelijk moet je ook nog tijd besteden aan de laatste stap, dit is afhankelijk van vele elementen. Zo kan een globale 10.0, bij ons na beoordeling uiteindelijk op een systeem specifieke beoordeling van 2.4 uitkomen.

De NVD beoordeling is een eerste, maar wel significante, indicatie. Daarna moet je je eigen huiswerk doen.

[nzall]

Een Integer overflow die te misbruiken valt via REGEX? Hoe dan? Ik zou graag wel eens willen lezen hoe ze dat voor elkaar gekregen hebben...

[P1nGu1n]

Regex ondersteunt recursieve patronen, afhankelijk van de smaak? Dan kan het oneindig oplopen in theorie

[gertvdijk]

Dat zou een DoS verklaren, geen RCE.

Maar als de regex als parameter aan een command wordt meegegeven... Tja. Zeg niet dat het hier gebeurt is, maar zoiets moet het haast wel zijn.

[The-Source]

Met een overflow kom je in geheugen uit waar je niet zo mogen komen. En dan kan plek zijn waar secrets geladen zijn, kan een plek zijn waar root shell actief is, etc etc.
Maar omdat meeste interne processes van software vaak op een hoog toegangslevel draaien (vaak als root) is elke vorm van mogelijke manipulative vaak al grote impact. En RCE is niet gelijk dat de server is overgenomen maar het geeft een hacker een startpunt achter je firewall en vaak dus ook al met elevated user rights.

[tedades]

Je RegEx parser gaat geheugen claimen op basis van hoeveel ruimte de parser denkt nodig te hebben. Met een speciaal geconstrueerde RegEx kun je over die 32bit integer waarde heen gaan en zo een buffer overflow veroorzaken. De parser claimt namelijk maar een beetje geheugen terwijl je expressie veel meer verbruikt. In die reguliere expressie stop je dan code die op je heap wordt geplaatst over bijvoorbeeld functie pointers om je eigen code te kunnen draaien.

[SubSpace]

Kan ik hier uit opmaken dat GitLab 18 niet kwetsbaar is?

[gbspeel]

Nee. GitLab 18 wordt niet meer ondersteund (alleen 19.2 - 19.4), dus 18.x en eerdere versies zijn wellicht nog niet getest op deze kwetsbaarheid. Dat kan zowel betekenen dat de kwetsbaarheid toen nog niet aanwezig was of nog niet bekend is.

Als er geen specifieke reden is om op GitLab 18.x te blijven hangen, zou ik de documentatie raadplegen om stap voor stap te upgraden naar een recente versie die onderhouden wordt. Bij zowel major als minor upgrades kan het nodig zijn om eerst een specifieke maximale versie te installeren. In jouw geval zullen het meerdere stappen worden.

[Reactie gewijzigd door gbspeel op 13 oktober 2026 19:45]

[SubSpace]

Ik weet dat er meerdere tussenstappen nodig zijn, maar ik had ergens gelezen dat er 3 major versions gesupport werden, dus ik had niet zo'n haast gemaakt. Maar goed, 19.2.8 is aan het installeren (de eerste tussenstap vanaf 18.11).

[tszcheetah]

Gitlab doet niet echt aan semver, ze releasen op vaste momenten. Elk jaar gaat het major versienummer omhoog (nu dus 19), elke maand het minor versienummer. Ze ondersteunen doorgaans 3 minor versies. 19.2 is ook alweer bijna 3 maanden oud inmiddels.

Ze hebben recent wel wat uitzonderingen gemaakt. Na het vorige kritieke lek is er nog een 18.11.12 release geweest, maar die kwam pas later dan de andere patches en is geen normaal beleid. Kortom: het best upgrade je minstens elke 3 maanden je installatie naar de nieuwste versie, en daarbinnen natuurlijk regelmatig naar de juiste patch releases.

[CriticalHit_NL]

Versie 18 is voor dit specifieke lek niet kwetsbaar maar het is toch aan te raden te upgraden omdat 18 al end-of-life support is en dus geen beveiligingsupdates meer ontvangt én omdat deze ook in het recente verleden al enkele aardige beveiligingslekken hebben gehad:

• https://nvd.nist.gov/vuln/detail/cve-2026-19478
• https://nvd.nist.gov/vuln/detail/cve-2026-1090
• https://nvd.nist.gov/vuln/detail/cve-2025-4700
• https://nvd.nist.gov/vuln/detail/cve-2026-1069
• https://nvd.nist.gov/vuln/detail/cve-2026-3988

[The Third Man]

End of support releases zijn praktisch gezegd altijd kwetsbaar, omdat er geen actief beveiligingsbeleid meer is; er worden geen bugs meer van gemeld en niet proactief vanuit de beheerders gedicht. Dan is het effectief een vergiet alleen weet je niet exact waar de gaten zitten.

[magnifor]

Nou, net geupdate naar 19.4.2 en nog steeds in het admin paneel krijg ik de popup dat ik moet updaten naar 19.4......2

[Reactie gewijzigd door magnifor op 13 oktober 2026 18:58]

[orvintax]

Klopt, het duurt na een update altijd even voordat die notificatie doorheeft op welke versie die zit. Als je naar het admin paneel gaat moet het versienummer wel goed staan. Let overigens niet op het label daarnaast, die heeft ook even tijd nodig..

[Tweakez]

Blij dat onze gitlab sowieso alleen maar intern draait. scheelt stress!

[Xilonz]

Totdat een van je collega's dit in z'n eigen repo's ci heeft staan:

include:
- remote: https://andergitlab.nl/ci.yml


En er nog nergens een poc staat, dus ik zou nog niet zo zeker zijn.

[fameus]

Niet bij te houden, die security releases. Het updaten van een multi-node installatie is nu niet bepaald eenvoudig. En dan heeft GitLab ook nog eens geen echte LTS releases waardoor je gedwongen wordt op maximaal 3 maanden afstand van the-latest-greatest te blijven. Niet eenvoudig omdat ze kwistig met breaking changes strooien.

[cdwave]

Ik zit er zo een beetje over te denken, maar iedereen die een pull-request of iets dergelijks kan indienen kan in ieder geval code uitvoeren op de build server. Want ja, uiteindelijk bestaan de build-en-test stappen uit het runnen van jouw scripts en code die in de repo staan. Vanwege een aantal projecten met Docker is het zelfs redelijk eenvoudig om root te worden op de build machine. Niet dat je daar veel aan hebt overigens, daar krijg je op het netwerk verder geen extra rechten van.

Nu is dat geen probleem omdat iedereen dat weet en er zorgvuldig mee omgaat. De ontwikkelaars zijn lief voor de buildserver. En de repo server is alleen via het interne netwerk te bereiken. Maar vanuit management heerst een "alles in de cloud" sentiment, en als dat overslaat naar development dan wordt dit toch wel een serieus risico.

[Thadir]

Dat licht ook wel aan hoe de build setup is gedaan. Gitlab gebruikt de runner princiepen waar weer geconteriseerde build agents in werken. Dit kan jij als platform beheerder reldijk dicht timmeren met een vissitor pattern, non root.

Maar dat is ook gelimiteerd aangezien GitLab hard timmerd aan bijv Agentic Swamr based agent setups. En dan loop je tegen tegen wat enge kernel challanges en andere concepten. Zelfs met selfhosted is dit gewoon een uitdaging.

[mocem]

De 10 was een dure voor Gitlab. De aandelen gingen 7.8% naar beneden.

[thabasement]

Zojuist kreeg ik mijn eerste spammail op mijn specifieke gitlab e-mail alias (die ik dus nergens anders gebruik of genoemd heb).

Ik heb een sterk vermoeden dat er data is buitgemaakt bij gitlab.com. Heeft iemand hier al specifiek iets over gelezen, of een soortgelijke ervaring?