GitLab heeft op 21 oktober een beveiligingsupdate uitgebracht voor een kritieke RCE GitLab-kwetsbaarheid: CVE-2026-110264. Volgens de leverancier kan een aanvaller onder voorwaarden zonder in te loggen code uitvoeren op een self-managed GitLab-server. De impact is groot omdat de fout teruggaat tot versie 7.0.
De kans op schade wordt bovendien versterkt door het feit dat een eerder patchmoment (op 12 oktober) niet voldoende was voor alle getroffen releases. GitLab benadrukt dat er geen betrouwbare workaround is voor zelf-hosted om omgevingsfactoren te omzeilen: de fix is de zekere bescherming.
Wat maakt deze kwetsbaarheid zo ernstig?
De fout heeft een CVSS-score van 10.0, de maximale score. GitLab koppelt het probleem aan een integer overflow tijdens het compileren van een speciaal geconstrueerde reguliere expressie. Daardoor kan de verwerking van die regex, onder bepaalde omstandigheden, leiden tot het uitvoeren van willekeurige code op de server.
Wat hierbij extra lastig is voor beheerders: GitLab heeft niet openbaar gemaakt welke exacte voorwaarden nodig zijn om de compilerroute te raken. Daardoor kun je niet met alleen configuratie-checks uitsluiten dat je omgeving kwetsbaar is.
Voor wie geldt het risico: alleen self-managed
Het advies is helder: alleen self-managed GitLab-installaties moeten actie ondernemen. GitLab.com draait al op een versie met de fix en ook GitLab Dedicated tenants draaien vanaf interne releases (19.3.5-internal0 en 19.4.2-internal0 of later) met de benodigde correcties.
Met andere woorden: als je GitLab beheert binnen je eigen infrastructuur, is de kans dat je moet updaten vrijwel onvermijdelijk zodra je binnen de relevante releasegeschiedenis valt.
Waarom eerdere patches je niet altijd beschermen
GitLab meldt dat een update van 12 oktober weliswaar een deel van de versies afdekte, maar niet het volledige spectrum. Die update dekte updates vanaf 19.2 (en later), terwijl de nieuwe vaste versies één patch boven die eerdere stand liggen.
Concreet betekent dit dat een instantie die negen dagen eerder was bijgewerkt, opnieuw binnen het risicogebied kan vallen. De boodschap: beschouw de nieuwe publicatie niet als “extra geruststelling”, maar als een echte correctie die je opnieuw moet verwerken.
Waar komt het probleem vandaan (en waarom het zo ver teruggaat)
De kwetsbaarheid zit niet in “een los GitLab-scherm”, maar in een onderdeel dat GitLab inbouwt en gebruikt: de regular-expression compiler. GitLab maakt daarbij gebruik van de ingebouwde Ruby-engine Onigmo. GitLab levert Onigmo mee in de eigen pakketten en patcht die component ook binnen zijn builds.
Omdat GitLab Onigmo op die manier in elke relevante distributie heeft meegenomen, geldt de kwetsbaarheid voor iedere release sinds 7.0. Dat is precies waarom het bereik zo breed is en waarom je niet kunt terugvallen op het idee dat “alleen recente versies” getroffen zijn.
Welke updates moet je plannen?
GitLab heeft voor meerdere releasebranches vaste versies gepubliceerd. Daarbij gaat het niet alleen om de meest recente onderhoudslijnen. In totaal noemt GitLab dat de fix is teruggeporteerd naar oudere versies buiten het reguliere patchvenster.
GitLab noemt bijvoorbeeld backports voor onder meer 18.11.13, 19.0.10, 19.1.9 en 19.2.9. Daarnaast is er een set “fixed releases” per branch die je kunt terugvinden in de advisering.
Let ook op de release-upgrade context: GitLab publiceert dat de 19.4.3 en 19.3.6-updates databasewijzigingen bevatten die tijdens de upgrade worden uitgevoerd. Voor een single-node setup resulteert dat in downtime zolang de database-afhandeling loopt.
Voor multi-node omgevingen geeft GitLab aan dat je de patch kunt toepassen zonder downtime via de zero-downtime procedure. Plan daarom je onderhoudsvenster afhankelijk van je installatietype.
Detectie: GitLab biedt regels, maar fix blijft leidend
Omdat GitLab nog geen details heeft gegeven over de exacte preconditions, kun je niet leunen op “check alleen logs” als vervanging voor patchen. Wel heeft GitLab twee detection rules gepubliceerd binnen het open-source TLDR-framework, gebaseerd op GitLab-logging.
- “Onigmo native worker crash”
- “Org mode render error burst”
Deze detecties zijn geschreven in Sigma-formaat tegen GitLab’s eigen applicatielogs. Ze kunnen je helpen om mogelijke exploitatiepogingen sneller te herkennen, maar GitLab stelt expliciet dat er geen interim workaround is die de noodzaak van de upgrade wegneemt.
Geen meldingen van misbruik (maar dat verandert niets aan je actie)
GitLab geeft aan geen aanwijzingen te hebben dat de kwetsbaarheid al is misbruikt in aanvallen. Ook staat CVE-2026-110264 (zoals gemeld) niet in de Amerikaanse CISA-catalogus van “known exploited vulnerabilities” op het moment van publicatie.
Toch is dit geen reden om de update uit te stellen. Bij kritieke RCE GitLab-kwetsbaarheden is het risico niet alleen “wat is er al gebeurd”, maar vooral “wat kan er gebeuren zodra iemand je installatie ontdekt”.
Context: GitLab heeft in korte tijd meerdere regex-gerelateerde issues
Deze publicatie past in een bredere lijn: GitLab rapporteert dat dit de vierde code-execution kwetsbaarheid is in de regular-expression engine die door dezelfde onderzoeker (met handle joaxcar) in één maand is gemeld. Eerder waren er ook issues met integer overflow in de regex-compiler, soms met andere toegangsvoorwaarden.
Belangrijk verschil: eerdere fixes stopten eerder in de versiegeschiedenis, terwijl deze nieuwe variant tot vóór versie 19.2 doorloopt. Dat maakt tijdig patchen des te belangrijker.
Praktische aanpak: zo pak je dit veilig op
Als je self-managed GitLab draait, is de meest werkbare volgorde doorgaans: inventariseren, patchen, valideren en detecteren.
- Inventariseer welke GitLab-versies je draait en of je single-node of multi-node gebruikt.
- Patch naar de door GitLab vastgestelde fixed versies voor jouw releasebranch (neem de update van 12 oktober niet als “voldoende” aan).
- Valideer na de upgrade dat de benodigde componenten op de juiste stand draaien.
- Controleer detecties met de door GitLab gepubliceerde TLDR-regels om te zien of er signalen waren vóórdat je patchte.
Als je ook breder kijkt naar recente GitLab-incidenten of compromisachtige situaties rond beheer- en accountstromen, kan dit artikel je helpen bij het structureren van je reactie: wat een gecompromitteerde login betekent en hoe je daarop reageert. Hoewel de oorzaak hier anders is, overlapt de denkwijze rond detectie en respons.
Verder is het nuttig om je patchproces te vergelijken met andere kritieke kwetsbaarheden waarbij “snel upgraden” de belangrijkste stap is—bijvoorbeeld in het geval van regex- en RCE-risico’s: PHP2Shell en de aanpak bij gelekte RCE-exploits. Dit geeft context over hoe snel exploitketens zich kunnen ontwikkelen zodra een kwetsbaarheid bekend wordt.
Conclusie
De update van GitLab voor CVE-2026-110264 is een duidelijk signaal: kritieke RCE GitLab kan in theorie zonder login leiden tot code-uitvoering op self-managed servers. Omdat GitLab geen volledige precondition-details publiceert en er geen interim workaround is, blijft patchen de belangrijkste maatregel.
Heb je recent nog geüpdatet? Controleer dan specifiek of je binnen de nieuwe “fixed” releases valt. Plan vervolgens onderhoud conform je installatiescenario en versterk je monitoring met de door GitLab gepubliceerde detectieregels.
Bron: https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html
