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 (18)

[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]

[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]

[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'

[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]

[SubSpace]

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

[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

[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).

[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.

[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.

[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!