GitLab-lek scoort 10,0: zelfbeheerders moeten patchen

GitLab bracht op 12 oktober 2026 patches uit voor een lek met CVSS-score 10,0 in Community Edition (CE) en Enterprise Edition (EE): getroffen zijn 19.2 vóór 19.2.8, 19.3 vóór 19.3.5 en 19.4 vóór 19.4.2. Beheerders van zulke zelfbeheerde installaties moeten direct bijwerken. GitLab.com draait al op een gerepareerde versie; klanten van GitLab Dedicated hoeven de update niet zelf uit te voeren.

De analyse van Rapid7 van 13 oktober beschrijft een onafhankelijke reproductie van code-uitvoering op GitLab CE 19.4.1; dezelfde invoer voerde op de gepatchte 19.4.2 geen code uit. Voor die aanval moesten onderzoekers eerst een kwaadaardig .gitlab-ci.yml-bestand en een speciaal repositorypad in een publiek project plaatsen. Waar gebruikers zichzelf kunnen registreren en publieke projecten mogen maken, kan een gewoon account die plaatsingsstap uitvoeren. Bij publicatie meldde Rapid7 geen bevestigd misbruik in het wild.

Welke installaties moeten worden bijgewerkt?

GitLab Self-Managed heeft per getroffen versietak een vaste patchrelease; GitLab.com is al bijgewerkt.

Voor beheerders begint de versiecontrole bij de vraag wie GitLab host. Bij GitLab.com beheert GitLab de software en is de correctie al toegepast. Ook voor GitLab Dedicated vraagt deze kwetsbaarheid geen update door de klant. Wie CE of EE op eigen infrastructuur draait, moet de versie van de draaiende instantie vaststellen; de waarschuwing geldt ongeacht of GitLab als Linux-pakket, vanuit broncode of via een Helm-chart is geïnstalleerd.

Vergelijk daarna de geïnstalleerde release met de patchgrens van de eigen versietak. Een hoger hoofd- of subversienummer op zichzelf zegt weinig als de betreffende patchrelease nog ontbreekt. Een instantie op een getroffen release heeft de correctie pas na een geslaagde upgrade en een controle van de werkelijk draaiende versie. GitLab raadt aan die upgrade niet tot een reguliere onderhoudsronde uit te stellen. Oudere versietakken vallen buiten de door GitLab opgegeven reeks voor dit specifieke lek, maar dat is geen oordeel over andere kwetsbaarheden in die releases.

Waarom de maximale score een aanvalseis verhult

GitLab beschrijft een route waarbij een speciaal gemaakte reguliere expressie in een CI/CD-configuratie onder bepaalde omstandigheden willekeurige code op de server kan laten uitvoeren. De maximale CVSS-score en de aanduiding ‘zonder authenticatie’ gaan over de kwetsbare verwerking. Voor de door Rapid7 gereproduceerde aanval moest de schadelijke invoer eerst in een repository terechtkomen. Dat onderscheid is bepalend voor de blootstelling van een concrete instantie.

In de demonstratie stonden de gewijzigde CI/CD-configuratie en een pad met UTF-8-tekens op een branch van een publiek project. Zelfregistratie met toestemming om zo’n project te maken verlaagt de drempel sterk: de aanvaller kan dan zelf de benodigde inhoud aanleveren. Op een instantie waar alleen vertrouwde gebruikers projecten mogen maken of erin mogen schrijven, vergt dezelfde route toegang tot een bestaand project of een andere manier om de bestanden te plaatsen. Gesloten registratie maakt de kwetsbare verwerking zelf niet veilig.

De gereproduceerde keten laat ook zien waarom een beheerder niet hoeft te wachten op een opvallende CI-job. De code-uitvoering vond plaats in een GitLab-applicatieproces. De toegangsvoorwaarden voor het plaatsen van bestanden helpen dus bij de prioritering van onderzoek, maar veranderen het patchadvies voor een getroffen versie niet.

Tijdelijke beperkingen tot de patch is geïnstalleerd

Een kwaadaardige GitLab CI/CD-configuratie en een UTF-8-repositorypad vormen samen de aangetoonde aanvalsinvoer.

Als de upgrade niet onmiddellijk kan plaatsvinden, ligt de meest gerichte tijdelijke beperking bij de aanleverroute uit de demonstratie. Beheerders kunnen zelfregistratie en het aanmaken van publieke projecten door onbekende gebruikers beperken, schrijfrechten op bestaande publieke projecten aanscherpen en anonieme toegang tot die projecten beperken. Vooral bij een instantie die bewust externe bijdragen ontvangt, moet duidelijk zijn welke samenwerking daardoor tijdelijk stopt.

Deze ingrepen verkleinen de ruimte voor de aangetoonde aanvalsketen; ze repareren de compiler voor reguliere expressies niet. Ze sluiten ook geen andere, nog niet onderzochte manier uit om een schadelijke configuratie te plaatsen. Koppel een tijdelijke toegangsbeperking daarom aan een concrete upgrade en controleer na afloop of de ingestelde beperkingen nog nodig zijn. De beslissende controle blijft de versie die de instantie daadwerkelijk uitvoert.

Waarom dit verder gaat dan een kwetsbare runner

Het technische probleem ontstaat bij de verwerking van een reguliere expressie uit de CI/CD-configuratie. Die expressie doorstaat eerst de validatie in een compacte US-ASCII-vorm. Wanneer GitLab haar later toepast op een passend repositorypad met UTF-8-tekens, compileert de gebruikte Onigmo-engine de expressie opnieuw voor die codering. Bij die stap kan een integer-overflow ongeldige instructies opleveren.

In de door Rapid7 beschreven keten kon dat leiden tot uitvoering van een opdracht in het Ruby-proces onder de systeemgebruiker git. Daaruit volgt dat alleen een CI-runner afschermen de aangetoonde kwetsbare verwerking in GitLab niet wegneemt. Het verschil tussen de kwetsbare en gepatchte testimage ondersteunt het belang van de softwarecorrectie, terwijl de vereiste repositorywijzigingen verklaren waarom de feitelijke toegangsinstellingen per instantie meetellen.

Welke activiteit is achteraf te controleren?

GitLab-logbestanden kunnen samenhangende projectactiviteit helpen reconstrueren tijdens onderzoek naar het lek.

Voor onderzoek op een getroffen instantie zijn recent aangemaakte publieke projecten, nieuwe accounts en onverwachte wijzigingen aan .gitlab-ci.yml of paden met UTF-8-tekens logische aanknopingspunten. Bekijk daarbij wie een project kon aanmaken of erin kon schrijven en wanneer de wijzigingen plaatsvonden. Dit zijn onderzoeksvragen die uit de gereproduceerde route volgen, geen gepubliceerde detectieregel die uitbuiting met zekerheid bewijst.

De documentatie van GitLab over beveiligingstelemetrie beschrijft welke gebeurtenissen applicatielogs en auditgegevens vastleggen. Zo registreren production_json.log en api_json.log web- en API-verzoeken, gitlab-shell.log Git-verkeer via SSH en GitLab Workhorse onder meer Git-verkeer via HTTPS. Een correlatie-ID kan verzoeken door meerdere componenten verbinden. Welke auditgebeurtenissen beschikbaar zijn, hangt mede af van het abonnement en de ingestelde verzameling.

Bewaar relevante logs als er aanwijzingen zijn voor verdachte projectactiviteit vóór de upgrade. Een ontbrekende auditmelding sluit eerdere activiteit niet uit; de geïnstalleerde patch voorkomt nieuwe uitbuiting van dit lek, maar reconstrueert niet wat eerder op de instantie is gebeurd.