Wprowadzenie do problemu / definicja
Zespół Ruby opublikował poprawki usuwające trzy istotne błędy w Onigmo, czyli silniku wyrażeń regularnych wbudowanym w język Ruby. Problem ma znaczenie bezpieczeństwa, ponieważ w określonych warunkach kompilacja specjalnie przygotowanego wzorca regex może prowadzić do uszkodzenia pamięci, a w konsekwencji nawet do zdalnego wykonania kodu.
Sprawa zyskała szczególny rozgłos, ponieważ te same klasy błędów zostały wcześniej powiązane z krytycznymi podatnościami załatanymi po stronie GitLab. Oznacza to, że źródło problemu nie leżało wyłącznie w logice aplikacji, lecz w samym mechanizmie kompilacji wyrażeń regularnych używanym przez środowisko Ruby.
W skrócie
Ruby wydał wersje 4.0.9, 3.4.12 oraz 3.3.13, które eliminują błędy w kompilatorze regex. Zagrożone są przede wszystkim aplikacje dynamicznie budujące wzorce na podstawie danych kontrolowanych przez użytkownika, na przykład przez wywołania tworzące regex w locie lub przez interpolację wejścia do literału wyrażenia regularnego.
- Poprawki obejmują trzy klasy błędów w Onigmo.
- Skutkiem może być uszkodzenie pamięci, a w określonych scenariuszach RCE.
- Mechanizmy ograniczające koszt wykonania regex, takie jak timeout, nie rozwiązują tego problemu.
- Dla użytkowników GitLab kluczowe są również wydania naprawcze samej platformy.
Kontekst / historia
Punktem wyjścia były analizy prowadzone w ekosystemie GitLab, gdzie użytkownicy mogą dostarczać własne wzorce wyrażeń regularnych, między innymi w konfiguracjach CI/CD i innych konfigurowalnych mechanizmach dopasowywania. Badacze wykazali, że odpowiednio spreparowane wyrażenia mogą doprowadzić do błędów pamięci już na etapie kompilacji wzorca, zanim dojdzie do jego właściwego użycia.
W rezultacie GitLab opublikował cztery identyfikatory CVE odnoszące się do skutków tych błędów w swoim produkcie. Część wcześniejszych luk wymagała uwierzytelnienia, natomiast nowsze scenariusze obejmowały także wektory nieuwierzytelnione i zostały ocenione jako krytyczne. Następnie Ruby opublikował poprawki usuwające źródłową przyczynę problemu na poziomie silnika regex.
Istotny jest również aspekt operacyjny: dla samych błędów po stronie Ruby nie nadano odrębnych identyfikatorów CVE przypisanych bezpośrednio do języka. W praktyce może to utrudnić korelację ryzyka w organizacjach opierających monitoring wyłącznie na klasycznym mapowaniu CVE do produktów końcowych.
Analiza techniczna
Technicznie problem dotyczy ścieżki kompilacji wzorca w Onigmo. Jeżeli aplikacja przekazuje do kompilatora regex ciąg znaków kontrolowany przez atakującego, możliwe jest wywołanie stanów prowadzących do błędów zarządzania pamięcią. Wśród opisywanych klas problemów znalazły się między innymi podwójne zwolnienie pamięci oraz przepełnienia całkowitoliczbowe w logice odpowiedzialnej za kompilację wzorca.
Ruby wskazał trzy główne kategorie błędów stojących za czterema podatnościami obserwowanymi wcześniej w GitLab.
- Podwójne zwolnienie pamięci przy nieudanym parsowaniu wzorca po alternacji.
- Przepełnienie całkowitoliczbowe związane z rozmiarem skompilowanego wzorca.
- Przepełnienie wewnętrznych identyfikatorów dla wzorców zawierających bardzo dużą liczbę powtórzeń.
To ważne rozróżnienie, ponieważ nie chodzi tu o klasyczny ReDoS polegający na nadmiernym zużyciu CPU podczas dopasowania. Problem występuje wcześniej, w samym kompilatorze regex, i ma charakter pamięciowy. Z tego powodu mechanizmy takie jak ograniczanie czasu wykonania wyrażeń regularnych nie stanowią skutecznego zabezpieczenia przed tym wektorem ataku. Niewystarczające może być także proste ograniczanie długości wejściowego wzorca, ponieważ niektóre błędy można wywołać również relatywnie krótkimi ciągami.
Zakres podatności jest przy tym dość precyzyjny. Aplikacje używające wyłącznie statycznych wyrażeń regularnych zapisanych przez programistów nie są uznawane za bezpośrednio narażone na ten scenariusz. Ryzyko pojawia się tam, gdzie wzorzec jest konstruowany dynamicznie z danych pochodzących z niezaufanego źródła.
Konsekwencje / ryzyko
Najpoważniejszą konsekwencją jest możliwość zdalnego wykonania kodu w aplikacjach, które kompilują niezaufane wzorce regex. W praktyce może to oznaczać przejęcie procesu aplikacyjnego, kompromitację danych, zakłócenie działania usług oraz wykorzystanie naruszonego systemu jako punktu wyjścia do dalszego ruchu bocznego w infrastrukturze.
Szczególnie wysokie ryzyko dotyczy środowisk, w których użytkownik może wpływać na logikę dopasowywania lub definiować własne reguły.
- Platformy wielodostępne umożliwiające definiowanie reguł i pipeline’ów.
- Usługi SaaS budowane na Ruby.
- Aplikacje backendowe oferujące konfigurowalne filtrowanie i walidację.
- Środowiska self-managed GitLab, które nie zostały jeszcze zaktualizowane.
Dodatkowym problemem jest ograniczona widoczność podatności. Jeżeli organizacja śledzi ekspozycję wyłącznie przez CVE przypisane do produktu końcowego, może przeoczyć fakt, że przyczyna źródłowa znajduje się w zależności runtime’owej. To z kolei zwiększa ryzyko opóźnionego patchingu i fałszywego poczucia bezpieczeństwa.
Rekomendacje
Najważniejszym działaniem pozostaje aktualizacja Ruby do wersji 4.0.9, 3.4.12 lub 3.3.13, zależnie od używanej gałęzi. W środowiskach GitLab należy wdrożyć właściwe wydania naprawcze platformy, ponieważ produkt dostarcza własną, zintegrowaną kopię Ruby.
Z perspektywy obronnej warto przyjąć następujące kroki:
- Zidentyfikować w kodzie wszystkie miejsca dynamicznego tworzenia regex na podstawie danych wejściowych.
- Przeanalizować użycie mechanizmów odpowiadających za kompilację wzorców oraz interpolację danych użytkownika do regex.
- Wyeliminować kompilację wzorców pochodzących od użytkownika albo zastąpić ją bezpieczniejszym modelem reguł.
- Traktować timeout wyłącznie jako ochronę przed ReDoS, a nie jako zabezpieczenie przed błędami pamięci.
- Zweryfikować wersje runtime’ów osadzonych w produktach, kontenerach i obrazach wdrożeniowych.
- Przeanalizować logi i telemetrię pod kątem awarii procesu, błędów kompilacji regex oraz prób dostarczania nietypowych wzorców.
- Uwzględnić ten przypadek w procesach SBOM, zarządzania zależnościami i skanowania podatności.
Dla organizacji korzystających z niewspieranych wersji Ruby szczególnie ważne jest to, że starsze linie nie zawsze otrzymają poprawki bezpieczeństwa. W takiej sytuacji najbardziej racjonalną strategią pozostaje migracja do wspieranej wersji oraz czasowe ograniczenie funkcji opartych na niezaufanych regexach.
Podsumowanie
Poprawki Ruby dla Onigmo pokazują, że dynamiczna kompilacja wyrażeń regularnych z niezaufanego wejścia może stanowić znacznie poważniejsze zagrożenie niż klasyczny ReDoS. W tym przypadku konsekwencją są błędy pamięciowe, które w określonych warunkach mogą prowadzić do RCE.
Organizacje korzystające z Ruby i GitLab powinny potraktować aktualizację jako działanie pilne. Równolegle warto przeprowadzić audyt kodu pod kątem wszystkich miejsc, w których użytkownik wpływa na treść kompilowanego wzorca, ponieważ właśnie tam materializuje się realne ryzyko ataku.
Źródła
- Ruby: Regexp compilation fixes related to GitLab’s CVE-2026-89078, CVE-2026-93577, CVE-2026-97229 and CVE-2026-110264 — https://www.ruby-lang.org/en/news/2026/10/23/regexp-fixes-for-gitlab-cves/
- GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 — https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-5-1-released/
- The Hacker News: Ruby Fixes Three Regex Engine Bugs Responsible for Four Critical GitLab RCE Flaws — https://thehackernews.com/2026/10/ruby-fixes-three-regex-engine-bugs.html