GitLab heeft op 21 oktober fixes uitgebracht voor een kritieke kwetsbaarheid die in principe kan leiden tot ongeauthenticeerde remote code execution (RCE) op self-managed GitLab-servers. De issue, CVE-2026-110264, krijgt de maximale score CVSS 10.0 en raakt alle versies sinds 7.0.
Belangrijk: GitLab geeft ook aan dat eerdere updates van 12 oktober je niet automatisch uit de gevarenzone halen. Dat komt doordat de nieuwe gefixt-versies “één patch” boven de eerder gepatchte reeks liggen. Hieronder lees je wat dit betekent voor jouw omgeving en hoe je verantwoord en snel kunt handelen.
Wat is er precies mis bij deze GitLab kwetsbaarheid patchen?
Volgens GitLab kan een aanvaller, zonder in te loggen, onder bepaalde voorwaarden willekeurige code laten uitvoeren op de server. De oorzaak ligt in een integer overflow tijdens het compileren van een speciaal geconstrueerde reguliere expressie.
GitLab heeft niet bekendgemaakt welke voorwaarden precies nodig zijn om die uitkomst te bereiken. Daardoor kun je niet met zekerheid “afstrepen” dat jouw setup immuun is op basis van configuratie alleen. Voor administrators is de praktische conclusie helder: patchen is de zekerste bescherming.
Waarom raakt deze fout versies sinds 2014?
De reikwijdte is groot: GitLab meldt dat de kwetsbaarheid aanwezig is in alle releases sinds 7.0. De kern van het probleem is het regex-compilergedeelte binnen GitLab. Dit wordt verwerkt door Onigmo, een ingebouwde Ruby-regex-engine die GitLab in zijn eigen packages levert en in eigen builds kan bijpatchen.
Zolang GitLab die kwetsbare engine heeft meegeleverd, kan dezelfde zwakte terugkomen in elke uitgebrachte versie. Dat is ook de reden dat je niet alleen naar “de laatste” releases moet kijken.
Zijn er aanwijzingen van misbruik? (voor self-managed geldt: ga toch patchen)
GitLab stelt dat er geen signalen zijn dat de kwetsbaarheid al in aanvallen is gebruikt. Bovendien staat CVE-2026-110264 nog niet in de Amerikaanse CISA-catalogus van bekende, misbruikte kwetsbaarheden (zoals van 22 oktober vermeld).
Toch blijft de ernst hoog: de combinatie van CVSS 10.0, ongeauthenticeerde exploitmogelijkheden en het feit dat je niet op voorhand kunt uitsluiten dat jouw situatie in de “voorwaarden” valt, maakt dat je snel moet updaten.
Alleen self-managed: wat betekent dit voor GitLab.com en tenants?
GitLab geeft expliciet aan dat je alleen actie hoeft te ondernemen voor self-managed installaties. GitLab.com draait al op de gefixte versies.
Voor GitLab Dedicated tenants op interne releases die “in de interne kanalen” vallen (genoemd als 19.3.5-internal0 en 19.4.2-internal0 of later) geldt dat ze al gepatcht zijn.
Concreet: als jij self-managed draait, behandel dit als een urgent patch-venster, ook als je eerder deze maand al update hebt uitgevoerd.
Let op: update van 12 oktober dekt dit niet volledig
GitLab meldt dat de update van 12 oktober alleen versies vanaf 19.2 en later betrof. De nieuwe releases met fix liggen een patch boven die eerdere lijn. Dat betekent dat een instantie die op 12 oktober al “bijgewerkt” is, weer binnen bereik van de kwetsbaarheid kan vallen zodra je nog niet ook de nieuwste fix-versies toepast.
Dit is een klassiek risico bij patchbeheerschema’s: je kunt denken dat je veilig bent door een eerdere update, terwijl de juiste fix in een latere patch-tranche zit.
Welke GitLab versies zijn gefixt?
GitLab heeft fixes in zeven versies tegelijk doorgevoerd. In de publicatie koppelt GitLab per releasebranch de versie die de bug oplost. Daarnaast noemt GitLab dat een deel van deze gefixte versies ouder is dan GitLab normaal onderhoudt.
Verder geeft GitLab aan dat ze de fix hebben teruggeporteerd naar onder andere:
- 18.11.13
- 19.0.10
- 19.1.9
- 19.2.9
GitLab gebruikt deze backport-aanpak voor ernstige issues. Als jouw versie in één van deze oudere lijnen valt, is het extra belangrijk om niet alleen naar “de meest actuele branch” te kijken, maar naar de exacte build die jij draait.
Geen workaround: pak het met een upgrade aan
GitLab biedt geen interim workaround en heeft ook niet gedeeld welke preconditions precies nodig zijn. Daarmee kun je niet veilig “omzeilen” door alleen instellingen aan te passen.
De enige zekere route is: upgraden naar een gefixte GitLab-versie. Dat klinkt misschien als een standaardadvies, maar hier is het echt de enige voorspelbare bescherming.
Als je daarbij hulp wilt bij het gestructureerd voorbereiden van patchen (testen, uitrol en terugvalplan), kan dit ook aansluiten op je bestaande aanpak. Bekijk bijvoorbeeld patchen voorbereiden bij kwetsbaarheden als denkraam voor je eigen change-proces.
Detectie: GitLab publiceert twee regels om exploitsporen te vinden
GitLab heeft ook twee detectieregels gepubliceerd die self-managed administrators kunnen helpen om mogelijke exploitpogingen te herkennen. De genoemde detecties heten:
- “Onigmo native worker crash”
- “Org mode render error burst”
Deze detecties maken deel uit van het open-source TLDR-framework van GitLab. De regels zijn opgesteld in Sigma-formaat en richten zich op GitLab-toepassingslogboeken.
Let op: detectie is geen vervanging voor patchen. Het kan je wel helpen om te begrijpen of er eerder pogingen zijn gedaan, zodat je je incidentanalyse-gerichter kunt uitvoeren.
Upgrade-kosten en downtime: plan het slim
GitLab waarschuwt dat de upgrade kosten kan hebben. Met name de releases 19.4.3 en 19.3.6 bevatten databasewijzigingen die tijdens de upgrade worden uitgevoerd.
Voor een single-node setup kan dat neerkomen op downtime terwijl die taken afronden. Bij multi-node omgevingen geeft GitLab aan dat je de patch kunt toepassen met een zero-downtime procedure.
Maak dit daarom geen “even tussendoor”-update, maar zet het in je planning met duidelijk eigenaarschap: wie besluit, wie test, wie rolt uit en hoe je terugvalt.
Vergelijkbare eerdere GitLab-regexfouten: dit patroon is duidelijk
Deze kwetsbaarheid is niet de eerste in het regex-engine domein. GitLab beschrijft dat dit de vierde code-execution fout is die in de afgelopen maand is gerapporteerd door dezelfde onderzoeker (met handle joaxcar). De eerdere ontdekkingen betroffen ook de regex-engine, maar bereikten soms minder oude versies of vereisten andere voorwaarden.
Dit patroon onderstreept dat je bij GitLab niet alleen “patches volgen” moet doen, maar ook alert moet zijn op de impact van wijzigingen in onderliggende componenten zoals regexverwerking.
Wat je nu concreet moet doen
- Inventariseer exact welke GitLab-versie(s) je draait (incl. self-managed installaties en eventuele oudere releasebranches).
- Vergelijk je versie met de gefixte versies die GitLab publiceert en plan de upgrade naar een release met de fix.
- Plan downtime of kies voor een zero-downtime aanpak bij multi-node omgevingen, afhankelijk van je infrastructuur.
- Check logs met de twee detectieregels (“Onigmo native worker crash” en “Org mode render error burst”) om te zien of er eerder pogingen zijn geweest.
- Herhaal je patch-check als je eerder rond 12 oktober hebt geüpdatet: die update dekt niet automatisch deze nieuwste fix.
Conclusie
De kwetsbaarheid rond GitLab kwetsbaarheid patchen—CVE-2026-110264 met CVSS 10.0—is een zeldzaam urgent geval: ongeauthenticeerde RCE, een impact die teruggaat tot 7.0 en geen bruikbare workaround. GitLab.com is al gefixt, maar voor self-managed is het advies praktisch en onontkoombaar: upgrade naar een gefixte versie, ook als je recent al een update draaide.
Door tegelijk te kijken naar mogelijke exploitsporen via de gepubliceerde detectieregels, maak je je herstel- en verificatiestap nog sterker. Zo sluit je snel de deur én krijg je meer inzicht in je blootstelling.
Bron: https://thehackernews.com/2026/10/critical-gitlab-flaw-cvss-100-could.html
