GitLab CVE-2026-97229: CVSS 10.0 in de CI/CD-regex-compiler

18 oktober 2026 Kwetsbaarheden 6 min lezen

Op 12 oktober 2026 heeft GitLab patchreleases 19.4.2, 19.3.5 en 19.2.8 uitgebracht. Daarin zit CVE-2026-97229, een integer overflow in de reguliere-expressiecompiler die GitLab voor CI/CD-configuratie gebruikt. GitLab geeft de kwetsbaarheid CVSS 10.0. Een dag later publiceerde Rapid7 technische details en een proof-of-concept. Het NCSC schaalt de schade als hoog en wijst op indicaties dat misbruik mogelijk is.

Voor wie een self-managed GitLab beheert is dit geen kwetsbaarheid om op de volgende patchronde te laten liggen. In dit artikel zet ik op een rij wat er feitelijk bekend is, waar de bronnen elkaar nuanceren, en hoe je binnen een uur weet of je geraakt kunt worden. Ik beschrijf geen exploit; het gaat om beoordelen, patchen en controleren.

Wat er bekend is

Feiten volgens de patchrelease-pagina van GitLab:

CVE-2026-97229, CVSS 10.0, vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H.
Een ongeauthenticeerde gebruiker kan via een kwaadaardige reguliere expressie in een CI/CD-configuratie code op de server uitvoeren.
Getroffen vanaf 19.2: alle versies van 19.2 vóór 19.2.8, 19.3 vóór 19.3.5 en 19.4 vóór 19.4.2. Community Edition en Enterprise Edition, self-managed.
GitLab.com draait al een gepatchte versie. GitLab Dedicated-klanten hoeven niets te doen.
Dezelfde release bevat 24 beveiligingsfixes. Naast de kritieke zijn onder meer CVE-2026-92883 (XSS in syntax highlighting, CVSS 8.7), CVE-2026-16301 (autorisatiefout bij downstream-pipelines, 8.5) en CVE-2026-14814 (vergiftiging van gecachte repositorybestanden, 8.2) interessant, omdat ze allemaal op de pipeline- en repositorylaag zitten.

Het is dus geen kwetsbaarheid in een randonderdeel: CI/CD-configuratie is precies wat een GitLab-server de hele dag verwerkt.

Technische achtergrond

GitLab zelf noemt als oorzaak onvoldoende validatie van reguliere expressies. Volgens de analyse van Rapid7, zoals samengevat in secundaire bronnen, werd een reguliere expressie in één encoding gevalideerd en daarna opnieuw gecompileerd voor UTF-8. Een integer overflow in de berekening van de programmagrootte levert dan ongeldige instructies op, waarna code binnen het Ruby-proces draait onder de git-gebruiker van GitLab.

Dit is de kern van de klasse: een controle op de ene representatie van invoer, gevolgd door gebruik van een andere. Zulke fouten zie je vaker bij parsers en compilers. Het is mijn eigen duiding dat het risico daarom niet in de regex zelf zit, maar in het feit dat een server door gebruiker aangeleverde patronen compileert.

De git-gebruiker is niet “maar een servicegebruiker”. Die heeft toegang tot de repositories, de configuratie, de secrets die GitLab opslaat en (afhankelijk van de inrichting) tot tokens waarmee deployments lopen. Compromittering betekent bij een GitLab daarom al snel: toegang tot broncode en tot de sleutels naar andere systemen.

De advisory en de CVSS-vector (PR:N) spreken van een ongeauthenticeerde aanvaller. De beschrijving van Rapid7 laat een iets praktischer pad zien. Daarvoor moet een aanvaller een kwaadaardig .gitlab-ci.yml en een repositorypad met UTF-8-tekens kunnen plaatsen in een publiek project. Op een instantie die open zelfregistratie toestaat en gebruikers publieke projecten laat aanmaken, doet een vers account dat in een paar minuten zelf.

Wat dat betekent voor jouw risico, is mijn interpretatie van de bronnen:

Een GitLab met open registratie, bereikbaar vanaf internet, is in de hoogste risicogroep.
Een GitLab zonder zelfregistratie, waar publieke projecten niet zijn toegestaan, is lastiger te bereiken voor het beschreven pad. Dat is geen vrijbrief: Rapid7 beschrijft één route, niet de enige mogelijke. Ook een kwaadwillende of overgenomen intern account kan configuratie committen.
Een interne GitLab die alleen via VPN bereikbaar is, verkleint de kring van aanvallers, maar niet tot nul.

Staat van misbruik

Stand van de bronnen op 18 oktober:

Rapid7 meldde tot en met 13 oktober geen bevestigd misbruik in het wild.
De kwetsbaarheid stond in de door mij geraadpleegde bronnen niet in de KEV-catalogus van CISA. Controleer die zelf, want dit kan snel veranderen.
Er is wel een publieke PoC, door Rapid7 gebouwd op GitLab CE 19.4.1 met ASLR ingeschakeld. Met een publieke PoC en een hoge blootstelling is het redelijk om te verwachten dat misbruik volgt (mijn inschatting). Een secundaire bron noemt als precedent een andere GitLab-kwetsbaarheid van vorige maand (CVE-2026-85706), waarvoor binnen enkele uren na publicatie aanvalspogingen werden gezien.
Censys telde op 13 oktober 82.454 GitLab-hosts, waarvan 25.766 (ongeveer 31%) met een kwetsbare versie. Dat zijn detecties op versie, geen bevestigde compromitteringen.

Let op de versie: CERT-EU noemde volgens een secundaire bron 19.3.4 als fixversie. GitLab noemt 19.3.5, omdat 19.3.4 een apart defect bevatte. Gebruik 19.3.5.

Wat je nu doet

Bepaal de versie. Op de server zelf:
```
sudo gitlab-rake gitlab:env:info
```
Ingelogd zie je de versie ook onder het helpmenu (/help). Leg vast welke instanties je hebt, ook de vergeten ontwikkel- of testomgeving.
Patch naar 19.2.8, 19.3.5 of 19.4.2 of nieuwer. Houd rekening met downtime bij een single-node-installatie door databasemigraties, en lees de opmerking van GitLab over de post-deploy-migratie in 19.3.5. Neem een back-up vóór de upgrade en volg de upgradepaden uit de GitLab-documentatie.
Beperk tot die tijd het pad dat Rapid7 beschrijft. Dit is een maatregel om tijd te winnen, geen oplossing: de compiler is er niet mee gerepareerd.
- Zet zelfregistratie uit of achter goedkeuring (in het Admin Area onder Settings → General → Sign-up restrictions; de menunamen kunnen per versie verschillen).
- Beperk de zichtbaarheid van nieuwe projecten (Admin Area → Settings → General → Visibility and access controls → Restricted visibility levels: Public).
- Haal een GitLab die niet publiek hoeft te zijn van het open internet af, bijvoorbeeld achter VPN of een reverse proxy met IP-beperking.
Controleer of er al iets is gebeurd. Dat is het lastige deel, omdat er geen gepubliceerde, betrouwbare indicatoren zijn. Wat wel redelijk is:
- Kijk naar nieuwe gebruikers en projecten sinds ongeveer 12 oktober, vooral met ongebruikelijke namen of repositorypaden met niet-ASCII-tekens.
- Kijk in de logs (standaard in /var/log/gitlab/gitlab-rails/, zoals production_json.log en application_json.log) naar pipeline-aanmaak en fouten rond CI-configuratie vanaf nieuwe accounts.
- Kijk op de server naar procesboom en netwerkverkeer van het Ruby-proces onder de git-gebruiker: uitgaande verbindingen naar onbekende hosts, onverwachte kindprocessen (shell, curl, wget).
- Controleer op nieuwe SSH-sleutels, access tokens, deploy tokens en runners die je niet herkent.
Vermoed je compromittering? Behandel dan alle secrets die GitLab bevat als gelekt: CI/CD-variabelen, deploy keys, tokens, runner-registraties en eventueel de GitLab-secrets zelf. Alleen patchen is dan niet genoeg, want een aanvaller kan al persistentie hebben gebouwd. Neem het incidentproces erbij (zie ook het artikel over de aanvalsketen van Qilin voor wat aanvallers doen met zulke toegang).

Wat ik hieruit meeneem

Het zijn dezelfde lessen als bij NetScaler eerder deze maand, alleen op een andere plek in het netwerk:

Een systeem dat code uitvoert voor gebruikers is een aanvalsoppervlak, ook als het “alleen een ontwikkeltool” is. Beschouw GitLab, Jenkins en vergelijkbare tools als kritieke infrastructuur met patchtermijnen die daarbij passen.
Weet wat je hebt. De organisaties die dit het snelst oplossen, zijn degene die een lijst hebben van hun GitLab-instanties en versies.
Open registratie op een interne of semi-publieke GitLab is zelden bewust gekozen. Zet het uit, tenzij je een reden hebt.