Eine 10,0 im Regex-Compiler von GitLab wird angegriffen – über 1.000 Server bleiben exponiert

GitLab hat den Patch am 12. Oktober veröffentlicht. Drei Wochen später läuft der Exploit, die US-Cyberbehörde hat Bundesbehörden eine Frist gesetzt, und Shadowservers Scan des offenen Internets findet weiterhin mehr als tausend selbst betriebene GitLab-Server, auf denen er nie installiert wurde.

Die Lücke heißt CVE-2026-97229 und trägt einen CVSS-Wert von 10,0 – das Maximum. Es ist ein Integer-Overflow im CI/CD-Regex-Compiler von GitLab, also in der Komponente, die reguläre Ausdrücke aus Pipeline-Konfigurationen parst, kompiliert und auswertet. Der Compiler validierte seine Eingabe nicht ausreichend, und wer ein präpariertes Muster einschleust, erreicht beliebige Codeausführung auf dem Server – ohne jede Authentifizierung.

Genau dieser Punkt macht daraus eine 10,0 statt einer schlechten Woche. GitLabs eigenes Advisory beschreibt einen nicht authentifizierten Nutzer, der beliebigen Code "über einen speziell präparierten regulären Ausdruck in einer CI/CD-Konfiguration" ausführt. Keine Zugangsdaten, kein Runner-Token, kein Schreibrecht am Repository – die Pipeline-Definition selbst ist die Angriffsfläche. Der Overflow sitzt Berichten zufolge in Onigmo, der mit Ruby gelieferten Regex-Engine, die GitLab zum Kompilieren dieser Muster nutzt; ein Integer, der beim Kompilieren überläuft, wird zur Speicherkorruption – und Speicherkorruption in dem Prozess, der sämtliche Repositories, CI-Variablen und Deployment-Geheimnisse der Instanz hält, ist so schlimm, wie es klingt.

Die Zeitleiste ist kurz. GitLab veröffentlichte am 12. Oktober korrigierte Versionen – 19.4.2, 19.3.5 und 19.2.8 für Community und Enterprise Edition. GitLab.com war bereits gepatcht, GitLab-Dedicated-Kunden mussten nichts tun. Am Freitag bestätigte CISA die Ausnutzung in freier Wildbahn, nahm die CVE in den Katalog bekannter ausgenutzter Schwachstellen auf und verpflichtete US-Bundesbehörden per Binding Operational Directive 26-04, bis Sonntag zu remedieren.

Dann veröffentlichte Shadowserver, wie das Internet tatsächlich aussieht. Am Sonntag meldete das Scan-Projekt der gemeinnützigen Organisation mehr als 1.000 internetexponierte GitLab-Instanzen, die weiterhin für CVE-2026-97229 anfällig sind – und im selben Update mehr als 11.300, die für CVE-2026-110264 offen sind, eine RCE mit Höchstwertung im selben Regex-Compiler, die GitLab einen Monat zuvor geschlossen hatte. Der Nenner sind rund 39.000 GitLab-Instanzen, die Shadowserver täglich sieht. Golem.de setzte die größere Zahl in die Überschrift: rund 11.000 angreifbare GitLab-Instanzen im Netz.

Zwei Zehn-von-zehn-Fehler in einer Komponente innerhalb eines Monats sind kein Pech, sondern ein Designsignal. Ein Regex-Compiler ist ein Parser mit langer Geschichte von Speichersicherheitsproblemen, und GitLab hat ihn in den Pfad nicht authentifizierter Konfigurationseingaben gestellt. Ob der zweite Fehler eine Variante des ersten ist oder ein eigenständiger Irrtum: die Lehre bleibt dieselbe – die CI/CD-Kontrollschicht ist jetzt ein Perimeter, und sie wird wie einer gescannt.

Es ist die sechste GitLab-Lücke, die CISA seit November 2021 in den KEV-Katalog aufgenommen hat; eine davon wurde in Ransomware-Kampagnen genutzt. Allein 2026 gab es eine Zwei-Faktor-Umgehung (CVE-2026-0723, Januar), einen Path Traversal in der Repository-Commits-API mit 10,0 (CVE-2026-85706, September, ebenfalls ausgenutzt) und nun zwei Regex-Compiler-RCEs. Das Muster zeigt auf den Preis: Auf einem GitLab-Server treffen Quellcode, Pipeline-Geheimnisse, Cloud-Schlüssel und Deployment-Rechte zusammen. Wer einen kompromittiert, erbt die Build-Pipeline – der klassische Weg, alles stromabwärts zu vergiften.

Öffentlich bekannt ist bislang kein namentlich genanntes Opfer und keine bestätigte Supply-Chain-Kompromittierung. Diese Lücke zählt: Die Ausnutzung ist bestätigt, der Umfang nicht. Shadowservers Zahl ist eine Erhebung der Exposition, nicht der Einbrüche.

Was zu tun ist:

- Version prüfen. Alles unter 19.4.2, 19.3.5 oder 19.2.8 – bzw. unter dem entsprechenden Patchstand einer neueren Release-Linie – fällt unter die erste Lücke; die zweite wurde früher geschlossen und ist der Grund für die 11.300. - Wer unauth-patcht im offenen Internet stand, sollte CI-Variablen, Runner-Token, Deploy-Keys und Registry-Zugangsdaten als potenziell exponiert behandeln und rotieren. Ein Patch schließt die Tür, macht einen Besuch nicht ungeschehen. - Auf Pipeline-Läufe achten, die von unbekannten Konten oder aus Forks gestartet wurden und ungewöhnlich regex-lastige Konfigurationen tragen – und auf ausgehende Verbindungen des GitLab-Hosts, die dort nicht hingehören. - Wer diese Woche nicht patchen kann, nimmt die Instanz vom offenen Internet. Jeder Exploit dieser Klasse beginnt mit einer Anfrage, die nur ein erreichbarer Server überhaupt zu sehen bekommt.

Die ehrliche Zusammenfassung: Der Patch existiert seit drei Wochen, ein externer Scanner findet die Ungepatchten von außen, und Exploit-Code ist im Umlauf. Das ist der seltene kritische Fall, der vollständig vermeidbar ist – und trotzdem nicht vermieden wird.