De GitLab-kwetsbaarheid CVE-2026-97229 laat een aanvaller zonder account code uitvoeren op je GitLab-server. De patch is er sinds 12 oktober, maar bij een eigen build van GitLab is updaten alleen niet genoeg: de fout zit in Ruby, en die moet je dan ook bijwerken.
Alpine Linux liep daar in oktober tegenaan. Host je GitLab zelf, dan is hun incidentverslag verplichte kost.
Wat is CVE-2026-97229?
GitLab dichtte het lek op 12 oktober in de kritieke patchrelease 19.4.2, 19.3.5 en 19.2.8. Het gaat om een integer overflow bij het compileren van reguliere expressies in een CI/CD-configuratie. Onder bepaalde omstandigheden kan een niet-ingelogde gebruiker daarmee willekeurige code uitvoeren op de server. GitLab geeft het de maximale CVSS-score van 10.0. Kwetsbaar zijn de Community en Enterprise Edition vanaf 19.2 tot 19.2.8, 19.3 tot 19.3.5 en 19.4 tot 19.4.2. GitLab.com en GitLab Dedicated waren al gepatcht toen de release uitkwam.
De echte oorzaak ligt een laag dieper. Het Ruby-project schrijft in zijn bericht van 23 oktober dat drie fouten in Onigmo, de regex-engine van Ruby, achter vier GitLab-CVE's zitten, waaronder deze. GitLab loste ze in zijn eigen releases op door de meegeleverde Ruby te patchen. Ruby zelf bracht op 23 oktober versie 4.0.9, 3.4.12 en 3.3.13 uit met alle fixes.
Uit dat Ruby-bericht moeten je beheerders twee dingen weten. Een time-out op reguliere expressies beschermt niet tegen deze fouten. En de lengte van een patroon beperken helpt ook niet betrouwbaar, omdat een deel van de fouten met korte patronen te triggeren is.
Wat ging er mis bij Alpine Linux?
Alpine Linux, een veelgebruikte Linux-distributie, publiceerde op 28 oktober een openhartig incidentverslag. Op 13 oktober werkten ze hun eigen GitLab bij naar 19.3.4, een versie te vroeg. Op 20 en 21 oktober stuurde een net aangemaakt account bewerkte CI-configuraties in die het lek probeerden te misbruiken. De aanvaller liet GitLab-workers acht keer crashen en kwam in vier gevallen een stuk op weg. Hij downloadde ook Alpine's eigen GitLab-containerimage, vermoedelijk om de exploit op die build af te stemmen.
Op 22 oktober updatete Alpine naar 19.3.6. Dat dichtte het lek niet. Hun image gebruikte de standaard Ruby van de distributie, en de fix zit in de Ruby-patch die GitLab alleen in zijn eigen pakketten toepast. Op 25 en 26 oktober kwam de aanvaller terug. Die pogingen mislukten.
Alpine vond geen bewijs dat de aanval geslaagd is. Maar een geslaagde exploit laat geen sporen achter in de weblogs, en een deel van de logs van de aanvalsdag was weg. Ze behandelden de server daarom als gecompromitteerd: GitLab ging dicht, werd vanaf nul opnieuw opgebouwd, alle wachtwoorden zijn gereset en de geheime sleutels van GitLab zijn vervangen. Hun repository, pakketten en releases controleerden ze tegen gegevens buiten GitLab, zonder sporen van manipulatie.
Waarom een versienummer geen bewijs is
Op een dashboard had de GitLab van Alpine er na 22 oktober gepatcht uitgezien, want het versienummer klopte. Toch zat het lek er nog in.
Dat is mijn belangrijkste punt voor CISO's: bij platforms die je zelf bouwt, in een eigen container of met eigen componenten, zegt het versienummer van het hoofdproduct weinig. De fix kan in een onderliggend onderdeel zitten dat je eigen build niet meekrijgt. Alpine schrijft het zelf: draai je GitLab met een eigen Ruby, dan is GitLab upgraden niet genoeg, en moet je ook naar Ruby 3.3.13, 3.4.12 of 4.0.9 of hoger. Hun advies aan anderen is om kritieke GitLab-securityreleases binnen een dag toe te passen en bij elke release te controleren welke componentpatches je eigen build nodig heeft.
Een tweede punt dat ik uit het verslag haal: de aanval kwam via een nieuw geregistreerd account. Staat bij jou de registratie op een interne of publieke GitLab open, of kunnen externe partijen zelf pipelines starten, dan is het aanvalsoppervlak groter dan veel teams denken.
Wie is eigenaar van je GitLab?
Naar mijn mening wringt het in veel organisaties bij het eigenaarschap. GitLab is de plek waar je broncode, pipelines, deployment-sleutels en vaak ook infrastructuurcode samenkomen. Toch valt het beheer vaak tussen wal en schip. De ontwikkelteams gebruiken het, de infrastructuurafdeling host het, en security kijkt er pas naar als er iets gebeurt. Een patch die een dag na release moet, en waarbij iemand moet nagaan of een Ruby-fix wel in de eigen image zit, past niet in dat gat.
Mijn advies: wijs één eigenaar aan voor je ontwikkelplatform, met een securitymandaat. Dat is iemand die de releasenotes van GitLab leest op de dag dat ze verschijnen, weet hoe jullie image is opgebouwd, en durft te zeggen dat de server offline gaat tot het goed zit. In de praktijk is dat een DevSecOps-engineer of een platform engineer met securityervaring. Heb je die niet in huis, of zit die nu vast in ander werk, dan is tijdelijke inhuur een logische stap.
Voor organisaties onder de Cyberbeveiligingswet, de Nederlandse uitwerking van NIS2 die sinds 15 augustus 2026 geldt, is dit ook een bestuursvraag. Je moet passende en evenredige maatregelen nemen voor je netwerk- en informatiesystemen, het bestuur keurt die goed en houdt toezicht, en een incident meld je zo snel mogelijk, uiterlijk binnen 24 uur. Een kritiek lek met een beschikbare patch en een gedocumenteerde aanvalspoging is het soort situatie waarvan een toezichthouder later wil zien wat je deed, en wanneer.
Wat moet je nu doen?
Vraag je beheerder vandaag welke GitLab-versie draait, of het een officieel GitLab-pakket is of een eigen build, en zo ja welke Ruby-versie erin zit. Een eigen build met Ruby onder 3.3.13, 3.4.12 of 4.0.9 is kwetsbaar, ook als het GitLab-versienummer klopt.
Was je GitLab tussen 12 oktober en je update bereikbaar voor buitenstaanders, kijk dan of er in die periode workers crashten of nieuwe accounts pipelines startten. Alpine liet zien dat je bij twijfel beter kunt herbouwen en sleutels vervangen dan hopen. Daarvoor heb je iemand met DFIR-ervaring nodig.
Eerder deze maand kwam dezelfde les langs bij de PHP2Shell-kwetsbaarheden. Het patroon is hetzelfde: de update is snel gedaan, het vaststellen waar alles draait en wie het oppakt kost de tijd.
Zoek je tijdelijk een DevSecOps-specialist of iemand voor vulnerability management die dit soort patches tot de laatste server doorzet? Via MVPeople zetten we interim securityprofessionals in. Bel of mail me via de contactpagina, dan kijken we samen wat je nodig hebt.
