Ruby heeft nieuwe versies uitgebracht om Ruby regex bugs in de Onigmo-regexengine te herstellen. De aanleiding is ernstig: de problemen liggen achter vier kritieke beveiligingslekken die GitLab de afgelopen maand heeft gepatcht. Met name scenario’s waarin GitLab (of andere apps) regexpatronen compileert die afkomstig zijn van tekst die een aanvaller kan beïnvloeden, kunnen leiden tot geheugenbeschadiging en uiteindelijk code-uitvoering.
In dit artikel zetten we op een rij wat er precies aan de hand is, welke actiestappen belangrijk zijn voor GitLab-beheerders en hoe je risico’s beperkt als upgraden (nog) niet direct kan.
Wat zijn de Ruby regex bugs precies?
Ruby publiceerde versies 4.0.9, 3.4.12 en 3.3.13 om drie bugs in Onigmo te fixen. Die bugs beïnvloeden hoe Ruby regexpatronen compileert.
Volgens de advisering kunnen speciaal vervaardigde patronen tijdens het compileren geheugen corrumperen. Afhankelijk van de omstandigheden kan dit resulteren in code execution op de server waar de regex wordt gecompileerd.
Waarom koppelt dit aan vier GitLab RCE-kwetsbaarheden?
GitLab ontdekte dat gebruikerspatronen binnen bijvoorbeeld CI/CD-configuraties kunnen worden doorgegeven aan Ruby om regex te compileren. Wanneer een aanvaller die patronen kan beïnvloeden, ontstaat een route richting de kwetsbaarheden die Ruby veroorzaakte in het compilatieproces.
GitLab heeft in totaal vier CVE’s uitgebracht in de periode van 23 september tot 21 oktober. In advisories is te zien dat twee van die kwesties een ingelogde account vereisen, terwijl twee (waaronder de later aangekondigde die breed door alle relevante GitLab-versies raakt) geen account vereisen.
Welke GitLab-versies moeten aandacht krijgen?
De kern voor zelf-gehoste GitLab-installaties is het fixen van CVE-2026-110264. GitLab meldde dat de nodige release op 21 oktober is geleverd en dat er backports beschikbaar zijn. Concreet gaat het om de volgende GitLab-versies:
- 19.5.1
- 19.4.3
- 19.3.6
- 19.2.9
- 19.1.9
- 19.0.10
- 18.11.13
GitLab.com draait volgens GitLab al op de gepatchte versie. Ook geldt: GitLab Dedicated tenants op recente interne releases zouden geen actie nodig hebben, omdat GitLab een ingebouwde Ruby gebruikt die al is aangepast.
Wanneer ben je geraakt? (niet elke regex is een probleem)
Ruby maakt het onderscheid duidelijk: een applicatie is alleen beïnvloed als zij een regex compileert uit tekst die een aanvaller kan controleren. Dat betekent niet dat elke reguliere expressie automatisch gevaarlijk is.
De compilatiestappen waarbij het mis kan gaan, zijn bijvoorbeeld:
- Het aanroepen van Regexp.new, Regexp.union of Regexp.compile met een door een aanvaller beïnvloedde string
- Het opnemen van de input in een pattern via interpolatie, zoals /#{input}/
Gebruik je uitsluitend regex die je eigen ontwikkelaars hebben geschreven en die niet door een aanvaller zijn beïnvloed, dan valt die use case doorgaans buiten de beschreven impact.
Waarom compenseren van upgrades mogelijk niet voldoende is
Ruby geeft beheerders en ontwikkelaars duidelijke signalen over mogelijke “noodremmen”. Twee maatregelen die op het eerste gezicht logisch lijken, blijken in deze situatie niet betrouwbaar:
- Regexp.timeout stopt deze specifieke bugs niet.
- Het afkappen of cap’en van de patroonlengte werkt ook niet als sluitende verdediging. Kortere patronen kunnen namelijk nog steeds problemen triggeren.
Als je nog niet kunt upgraden, adviseert Ruby om te stoppen met het compileren van regex uit niet-vertrouwde input. Dat vraagt dus vooral om het aanpassen van de applicatielogica of het isoleren van inputbronnen.
Welke Ruby versies moet je installeren?
Ruby brengt de fixes alleen aan in de genoemde nieuwe releases. Ruby 3.2 en eerder krijgen geen update, omdat Ruby 3.2 op 1 april 2026 end-of-life ging; 3.2.11 was de laatste versie in die reeks.
Ruby adviseert om te migreren naar 3.4 of 4.0. Voor het patchen van de genoemde problemen zijn specifiek de volgende versies bedoeld:
- Ruby 4.0.9
- Ruby 3.4.12
- Ruby 3.3.13
Let op: Ruby’s advies is niet alleen “upgrade, maar later”. Voor GitLab is de impact direct gekoppeld aan de gepatchte versies in je GitLab-platform.
Detectie en opvolging bij GitLab
GitLab rapporteerde ook dat het detectieregels publiceerde voor zelf-gehoste omgevingen. Daarmee kunnen beheerders signalen onderzoeken die kunnen wijzen op pogingen om misbruik te maken van de kwetsbaarheden.
Deze detectie is geen vervanging van patchen, maar helpt om de status in je omgeving beter te duiden—zeker als je niet meteen volledig inzicht hebt in waar precies regexcompilatie met door gebruikers beïnvloedde patronen plaatsvindt.
Als je intern wilt vergelijken of je omgeving al op het juiste niveau zit, helpt het om je GitLab-versie te koppelen aan de hierboven genoemde vaste releases en vervolgens de detectieregels te testen op logdata uit de relevante periode.
Praktische checklist voor GitLab-beheerders
- Upgrade GitLab naar een van de versies met de fix voor CVE-2026-110264 (zoals vermeld door GitLab).
- Controleer CI/CD en gebruikerspatronen waar regex wordt gecompileerd uit configuratie of input die van gebruikers kan komen.
- Gebruik Ruby fixes waar van toepassing als je eigen services Ruby gebruiken voor regexcompilatie op niet-vertrouwde input.
- Leun niet op timeouts of patroonlengte-caps als “definitieve” bescherming; treat ze als onvoldoende.
- Activeer en beoordeel detectieregels om te zien of er in jouw omgeving al exploitatiepogingen zijn geweest.
Wil je breder kijken naar hoe supply chain en toolchains soms kwetsbaarheden introduceren in ecosystemen rondom development en security tooling? Lees dan ook LiteLLM supply chain aanval: PyPI en Docker.
Conclusie: pak Ruby regex bugs en GitLab RCE nu aan
De boodschap is helder: Ruby regex bugs in de Onigmo-engine kunnen leiden tot geheugenbeschadiging tijdens regexcompilatie, en GitLab heeft die vertaald naar vier kritieke RCE-kwetsbaarheden. Voor zelf-gehoste GitLab-omgevingen betekent dit dat je de versies met de fix voor CVE-2026-110264 moet installeren. GitLab.com en recente Dedicated-instanties draaien volgens de publicatie al gepatcht.
Kun je nog niet upgraden? Neem dan Ruby’s advies ter harte: stop met het compileren van regex op basis van niet-vertrouwde input. Daarna kun je alsnog plannen voor een volledige migratie naar de juiste releases.
Bron: https://thehackernews.com/2026/10/ruby-fixes-three-regex-engine-bugs.html
