GitLab CVE-2026-110264 ist eine mit CVSS 10.0 bewertete, nicht authentifiziert ausnutzbare Remote-Codeausführung in der Community und Enterprise Edition. Die Lücke steckt in der Regex-Engine Onigmo, die GitLab in eigenen Paketen ausliefert. Betroffen sind die Zweige 7.0 bis vor 18.11.13, 19.0 vor 19.0.10, 19.1 vor 19.1.9, 19.2 vor 19.2.9, 19.3 vor 19.3.6, 19.4 vor 19.4.3 und 19.5 vor 19.5.1 (Versionsgrenzen, Behördenmeldung AL-2026-152 der Cyber Security Agency of Singapore). Version 7.0 erschien 2014, der Fehler reicht damit zwölf Jahre zurück. Am 22. Oktober stand die Lücke nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen.
GitLab CVE-2026-110264: Integer Overflow im Regex-Compiler
Nach der von GitLab kommunizierten Beschreibung entsteht die Lücke durch einen Integer Overflow, wenn der Regex-Compiler einen präparierten regulären Ausdruck verarbeitet. Onigmo ist normalerweise Teil von Ruby; GitLab liefert die Engine in eigenen Paketen mit und muss Sicherheitsfixes dort selbst nachziehen. Die Betroffenheit hängt damit am GitLab-Paket, nicht an der Ruby-Version des Systems. Unter welchen Bedingungen ein Angreifer ohne Anmeldung bis zum Regex-Compiler durchkommt, hat GitLab nicht offengelegt.
Eine Zwischenlösung gibt es nicht: GitLab nennt keinen Workaround, weder einen Konfigurationsschalter noch eine dokumentierte Absicherung auf Proxy-Ebene. Für die Erkennung im Betrieb hat das Open-Source-Projekt TLDR zwei Sigma-Regeln veröffentlicht, die GitLab-Applikationslogs auswerten: „Onigmo native worker crash" und „Org mode render error burst".
Sieben Fix-Versionen, nur drei schließen alle Lücken
GitLab hat sieben Releases veröffentlicht: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13, jeweils für CE und EE. Wer ausschließlich die kritische Lücke im Blick hat, kommt mit jedem davon weiter. Wer alle zwölf Schwachstellen loswerden will, muss auf 19.5.1, 19.4.3 oder 19.3.6 gehen – in 19.2.9, 19.1.9, 19.0.10 und 18.11.13 steckt nur der Fix für CVE-2026-110264.
GitLab versorgt regulär das aktuelle Release plus die zwei Vormonats-Releases, also 19.5, 19.4 und 19.3. Vier zusätzliche Zweige zu versorgen, behält sich das Unternehmen für schwere Fälle vor.
GitLab.com läuft bereits mit der gepatchten Version. GitLab-Dedicated-Instanzen ab 19.3.5-internal0 beziehungsweise 19.4.2-internal0 müssen nichts unternehmen.
Die weiteren Schwachstellen: LDAP-Übernahme und OAuth-Umleitung
Zwölf Lücken schließen die Updates insgesamt, davon eine kritische, zwei hohe, fünf mittlere und vier niedrige. Die beiden High-Lücken treffen vor allem Setups mit föderierter Anmeldung: CVE-2026-15723 (CVSS 8.2) erlaubt angemeldeten Nutzern die Übernahme fremder LDAP-Konten, wenn OmniAuth-SAML und LDAP-Auto-Linking gleichzeitig aktiv sind. CVE-2026-112212 (CVSS 7.5) erlaubt unauthentifizierten Angreifern, das OAuth/OIDC-Discovery-Dokument in einem Shared Cache zu manipulieren und Sign-in-Flows auf einen Server unter ihrer Kontrolle umzuleiten.
Dazu kommen fünf Medium-Lücken mit den Scores CVE-2026-12664 (6.8), CVE-2026-16255 (5.9), CVE-2026-105777 (4.3), CVE-2026-13319 (4.3) und CVE-2026-112378 (4.3) sowie vier Low-Lücken, für die kein Score genannt wird: CVE-2026-105711, CVE-2026-14288, CVE-2026-112326 und CVE-2026-103515.
Upgrade-Aufwand: Datenbankmigrationen und Downtime
Das Update kostet Wartungszeit. 19.4.3 und 19.3.6 enthalten Datenbankänderungen, die beim Upgrade laufen; auf Single-Node-Installationen bedeutet das Downtime. Multi-Node-Setups können nach GitLabs Zero-Downtime-Verfahren ohne Ausfall patchen. Wer die Wartung plant, sollte dieses Fenster einrechnen, statt den Patch zwischen zwei Deployments zu schieben.
Abgrenzung zu CVE-2026-97229 und den September-Lücken
Die Lücke ist nicht die erste dieser Art. Am 12. Oktober 2026 hat GitLab CVE-2026-97229 gestopft – ebenfalls CVSS 10.0, ebenfalls ein nicht authentifizierter Overflow im Regex-Compiler – mit den Releases 19.2.8, 19.3.5 und 19.4.2. Am 23. September folgten CVE-2026-93577 und CVE-2026-89078 (beide 9.9, authentifiziert, ab 19.2). Damit schließt GitLab innerhalb eines Monats die vierte Codeausführungslücke, CVE-2026-110264 ist die erste, die auch Versionen vor 19.2 erreicht. Wer am 12. Oktober gepatcht hat, liegt wieder im betroffenen Bereich, weil die neuen Fix-Versionen eine Patch-Stufe darüber liegen.
Eine Vermengung von CVE-2026-110264 mit dem älteren CVE-2026-97229 führt zu falschen Rückschlüssen über die Betroffenheit – insbesondere bei Instanzen, die seit dem Oktober-Patch als erledigt galten.
Fazit
Ohne Workaround bleibt nur das Update. Für den gepflegten Zweig muss mindestens dessen Fix-Version eingespielt werden; für alles vor 19.0 ist 18.11.13 die Untergrenze. Wer anschließend alle zwölf Schwachstellen geschlossen haben will, wechselt auf 19.5.1, 19.4.3 oder 19.3.6 – 18.11.13, 19.0.10, 19.1.9 und 19.2.9 enthalten nur den kritischen Fix.
Priorität haben Instanzen, die direkt aus dem Internet erreichbar sind. Die Bedingungen, unter denen ein Angreifer den Regex-Compiler erreicht, hat GitLab nicht offengelegt – eine vorgelagerte Authentifizierung oder ein Proxy sind damit kein belegbarer Schutz. Die Downtime für die Datenbankmigrationen lässt sich in ein geplantes Wartungsfenster legen; aufschieben sollte man sie nicht über den nächsten Release-Zyklus hinaus.
Quellen
- heise Security – „Kritische Codeausführung: GitLab veröffentlicht dringende Sicherheitsupdates"
- Cyber Security Agency of Singapore – „Critical Vulnerability in GitLab" (Alert AL-2026-152)
- The Hacker News – „Critical GitLab Flaw (CVSS 10.0) Could Allow Unauthenticated RCE Across 12 Years of Releases"
- Mallory – „GitLab Patches CVSS 10.0 Unauthenticated RCE Affecting Releases Back to Version 7.0"
- VulDB – CVE-2026-110264