GitLab-lek met CVSS 10 wordt actief misbruikt: patch zelfbeheerde instances nu

Meteen handelen: update kwetsbare servers

CVE-2026-85706 is een path-traversal-kwetsbaarheid met de maximale CVSS 3.1-score van 10,0 in zelfbeheerde GitLab Community Edition (CE) en Enterprise Edition (EE). Een niet-geauthenticeerde aanvaller kan onder bepaalde voorwaarden willekeurige bestanden uitlezen die toegankelijk zijn voor de GitLab-server. Het gaat niet alleen om een theoretisch risico: de Amerikaanse cyberbeveiligingsinstantie CISA heeft het lek opgenomen als aantoonbaar misbruikt, en onderzoekers zagen kort na de beschikbaarheid van patches al probes tegen publiek bereikbare instances. 32122

Draait een zelfbeheerde GitLab-instance op een getroffen versie, update dan zo snel mogelijk naar een van deze releases:

• 19.1.8 of nieuwer
• 19.2.6 of nieuwer
• 19.3.2 of nieuwer

Getroffen zijn GitLab CE/EE-versies vanaf 18.7 tot vóór 19.1.8, 19.2 tot vóór 19.2.6 en 19.3 tot vóór 19.3.2. GitLab bracht de fixes uit op 10 september 2026. 37

CISA voegde CVE-2026-85706 op 11 september toe aan de Known Exploited Vulnerabilities-catalogus (KEV), een lijst van kwetsbaarheden waarvoor bewijs is van misbruik in de praktijk. Voor Amerikaanse federale burgerlijke overheidsinstanties die onder de richtlijn vallen, was 14 september de uiterste actiedatum. Die datum is niet automatisch van toepassing op private organisaties, maar onderstreept wel de urgentie voor elke publiek bereikbare, zelfbeheerde installatie. 3

Wat gaat er mis?

De fout zit in GitLabs Repository Commits API. De gedocumenteerde oorzaak is een combinatie van onvoldoende begrenzing van door gebruikers aangeleverde paden en ontbrekende authenticatiecontrole. Daardoor kan een aanvraag zonder authenticatie bestanden uitlezen die voor de GitLab-service toegankelijk zijn. 3

Het gaat primair om een lek voor bestandsuitlezing, niet om op zichzelf bewezen remote code execution (RCE). Maar uitgelezen bestanden kunnen, afhankelijk van de serverconfiguratie, wel materiaal bevatten dat een vervolgcompromis mogelijk maakt: applicatie-instellingen, tokens, SSH-sleutels, databasegegevens en andere geheimen die het GitLab-proces kan lezen. 925

Actief misbruik maakt dit een incidentresponsvraagstuk

WatchTowr meldde probes in het wild, waaronder verkeer dat op 11 september via het eigen honeypotnetwerk werd waargenomen. Ook de KEV-vermelding door CISA is een belangrijk alarmsignaal: die catalogus is juist bedoeld voor kwetsbaarheden waarvoor aanwijzingen bestaan dat ze buiten testomgevingen worden uitgebuit. 222

De openbare berichtgeving bevestigt scanning en misbruikpogingen, maar noemt geen enkele verantwoordelijke actor, geen betrouwbaar aantal slachtoffers en geen universele vervolgketen na uitbuiting. Het ontbreken van een bekende inbraakmelding betekent dus niet dat een blootgestelde server onaangeroerd bleef.

Behandel publiek bereikbare instances als mogelijke geheimenlekken

Patching stopt het kwetsbare gedrag, maar maakt eerder uitgelezen gegevens niet ongedaan. Stel bij een getroffen, via internet bereikbare server eerst bewijs veilig en beoordeel welke gegevens voor het GitLab-serviceaccount bereikbaar waren, voordat u grootschalig opruimt.

Geef prioriteit aan controle en rotatie van onder meer:

• GitLab-applicatie- en configuratiegeheimen;
• referenties voor database, Redis, objectopslag, containerregistry, SMTP, directorydiensten en identityproviders die in configuratie staan;
• CI/CD-variabelen, deploytokens, accesstokens, runnertokens, deploy keys en gegevens die beschikbaar zijn voor jobs of integraties;
• cloudkeys, credentials voor package registries, ondertekeningssleutels en SSH- of TLS-privésleutels die de host of het GitLab-proces kon lezen.

Plan die rotatie zorgvuldig. Het wijzigen van applicatiegeheimen of encryptiegerelateerde instellingen kan sessies ongeldig maken en versleutelde instellingen of koppelingen verstoren. Bewaar daarom eerst relevante logs en configuratiebewijs, werk herstelstappen uit en roteer de risicovolste gegevens in een gecontroleerde volgorde.

Waar u in logs naar zoekt

Een eerste nuttige indicator is een HTTP-POST-verzoek naar dit Repository Commits API-pad:

/api/v4/projects/<id>/repository/commits/

In rapportages wordt specifiek aangeraden te zoeken naar verzoeken met de parameter file.path. Controleer logs van reverse proxies, load balancers, WAF's en GitLab Rails op ongebruikelijke niet-geauthenticeerde verzoeken, gecodeerde invoer die op path traversal wijst, onverwachte project-ID's, herhaalde fouten, enumeratiepatronen of afwijkende responsgroottes. 212426

Onderzoek ook mogelijke vervolgactiviteit na het vermoedelijke blootstellingsvenster, zoals nieuw aangemaakte of gebruikte tokens, runnerregistraties, gewijzigde CI/CD-variabelen of pipeline-definities, ongewone imports, GraphQL-activiteit en onverwachte uitgaande verbindingen. Rond de release werd eveneens geadviseerd commits, GraphQL-subscriptions, projectimports en CI/CD-pipelines na te lopen. 23

Een schone zoekopdracht in de logs is niet doorslaggevend. Logretentie kan beperkt zijn, applicatielogging registreert mogelijk niet alle relevante details en proxy- of WAF-logs kunnen de enige beschikbare sporen bevatten.

Tijdelijke maatregelen als updaten echt niet direct lukt

Updaten is de noodzakelijke oplossing. Is een spoedupdate tijdelijk onmogelijk, beperk dan de toegang tot de GitLab-webdienst en API tot een VPN of goedgekeurde netwerken. Een zeer gerichte regel op reverse proxy of WAF die de kwetsbare Repository Commits API-route beperkt, kan het risico op korte termijn verminderen. Zo'n regel kan echter legitieme automatisering breken en vervangt patchen niet.

De praktische volgorde voor elke getroffen server:

1. Breng in kaart en prioriteer zelfbeheerde instances die van buitenaf bereikbaar zijn.
2. Update naar 19.1.8, 19.2.6, 19.3.2 of een nieuwere versie.
3. Verifieer de draaiende versie na de wijziging.
4. Stel logs veilig en onderzoek ze op signalen van misbruik.
5. Roteer mogelijk blootgestelde geheimen, passend bij de toegang van de server en de bedrijfsimpact.

Twee andere kwetsbaarheden uit dezelfde release

De beveiligingsrapportage beschreef ook twee Enterprise Edition-problemen die in deze release zijn opgelost:

• CVE-2026-87719 is gemeld als een geauthenticeerd insecure-deserialization-lek met CVSS 9,9, dat volgens sommige berichtgeving configuratie en credentials van Advanced Search kan blootstellen. 6
• CVE-2026-88765 is gemeld als een risico op remote code execution voor geauthenticeerde gebruikers bij het importeren van een gemanipuleerde Git-projectexport, met een gemelde CVSS-score van 8,5. 625

Deze kwetsbaarheden hebben andere voorwaarden en gevolgen dan CVE-2026-85706. Voor blootgestelde, zelfbeheerde GitLab-installaties blijft de niet-geauthenticeerde en actief misbruikte fout voor bestandsuitlezing de eerste prioriteit voor indamming en incidentrespons.