Eine Zahl wie diese liest man selten: zwölf Jahre. So lange schlummerte eine Sicherheitslücke in GitLab, bevor sie am 21. Oktober 2026 endlich geschlossen wurde — mit der höchstmöglichen Gefahrenstufe CVSS 10,0.
DER FUND: Ein Überlauf in der Regex-Maschine
Die Lücke trägt die Kennung CVE-2026-110264 und steckt nicht in GitLab selbst, sondern in einer Komponente, die GitLab mitliefert und patcht: Onigmo, Rubys Regex-Engine. GitLab beschreibt den Fehler als Integer-Overflow bei der Kompilierung eines speziell gestalteten regulären Ausdrucks. Wer einen solchen Ausdruck an der richtigen Stelle einschleust, kommt ohne Anmeldung an die Steuerung des Servers.
Gefunden hat die Lücke der Sicherheitsforscher joaxcar — bereits der vierte Treffer in GitLabs Regex-Engine innerhalb eines einzigen Monats. Das ist kein Zufall, sondern Routine-Jagd auf eine Softwareschicht, die offenbar seit Jahren niemand gründlich durchleuchtet hat.
EHRLICH BLEIBEN: Was GitLab nicht sagt
GitLab selbst schreibt, die Ausnutzung erfordere bestimmte Bedingungen — ohne diese Bedingungen offenzulegen. Das ist ungewöhnlich zurückhaltend für eine Lücke mit Höchstwertung, aber nachvollziehbar: Je weniger Details öffentlich stehen, desto schwerer wird es für Angreifer, einen funktionierenden Exploit zu bauen, bevor alle gepatcht haben. Wer dir einen genauen Angriffsweg verspricht, spekuliert.
WER BETROFFEN IST: Praktisch die ganze Geschichte von GitLab
Betroffen sind alle Self-Managed-Installationen von GitLab CE und EE — von Version 7.0 aus dem Jahr 2014 bis unmittelbar vor den aktuellen Fix-Versionen. GitLab hat die Korrektur gleichzeitig in sieben Branches zurückportiert: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13. Dass GitLab so weit über seine reguläre Support-Politik hinaus patcht, ist selbst ein Hinweis auf den Ernst der Lage.
GitLab.com und GitLab Dedicated sind bereits sicher — nur wer GitLab selbst betreibt, muss handeln.
IMMERHIN: Noch kein Exploit im Umlauf
Die gute Nachricht zuerst: GitLab berichtet keine Hinweise auf aktive Ausnutzung, und die Lücke steht Stand 22. Oktober nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen. Ein öffentlicher Proof-of-Concept ist ebenfalls nicht bekannt. Das ändert nichts an der Dringlichkeit — es verschafft dir nur ein kleines Zeitfenster, das du nutzen solltest, bevor es zu spät ist.
SO PATCHST DU JETZT — in 5 MINUTEN
- Version prüfen: In der GitLab-Oberfläche unten links oder über
/helpdie laufende Versionsnummer nachsehen. - Branch zuordnen: Zur eigenen 19.x- oder 18.11-Linie die passende Fix-Version aus der Liste oben heraussuchen.
- Aktualisieren: Über den gewohnten Weg — Omnibus-Paket, Helm-Chart oder Docker-Image — auf die Fix-Version heben.
- Protokolle sichten: Nach ungewöhnlichen Anfragen an die CI/CD- und Repository-Endpunkte der letzten Wochen schauen, auch wenn GitLab keine aktive Ausnutzung meldet.
FAZIT: Alte Software, neue Note 10
Zwölf Jahre lang lag diese Tür offen — und erst jetzt hat jemand genau genug hingesehen. Für Admins heißt das nicht nur „patchen“, sondern auch: Wer GitLab seit Jahren im Einsatz hat, sollte sich an die eigene Update-Disziplin erinnern. Eine Lücke, die so lange überlebt, findet sich nicht zufällig in brandneuem Code.