Angreifer nutzen eine kritische Schwachstelle in selbstverwalteten GitLab-Instanzen aktiv aus. Die US-Sicherheitsbehörde CISA hat die unter CVE-2026-97229 geführte Lücke deshalb in ihren Katalog bekanntermaßen ausgenutzter Schwachstellen aufgenommen. Sie erreicht den maximalen CVSS-Wert von 10,0 und ermöglicht unter bestimmten Bedingungen eine nicht authentifizierte Ausführung von Code auf dem GitLab-Server.
Konkret gefährdet sind ungepatchte Installationen von GitLab Community Edition und Enterprise Edition. GitLab hat die Schwachstelle bereits am 12. Oktober 2026 mit den Versionen 19.4.2, 19.3.5 und 19.2.8 geschlossen. Für Betreiber ist die Lage dennoch nicht mit einem flüchtigen Versionsvergleich erledigt: Wer GitLab mit einer eigenen Ruby-Installation betreibt, muss zusätzlich deren Patchstand kontrollieren.
CISA verlangt von betroffenen US-Bundesbehörden eine Absicherung bis Sonntag, den 1. November 2026. Diese Frist ist für private Unternehmen nicht verbindlich. Die Aufnahme in den Known Exploited Vulnerabilities Catalog bedeutet aber, dass es nicht mehr nur um eine theoretisch ausnutzbare Schwäche geht. Aktive Ausnutzung ist bestätigt.
Eine präparierte Regex führt bis zur Codeausführung
Die Schwachstelle steckt im CI/CD Regular Expression Compiler von GitLab. Diese Komponente verarbeitet, kompiliert und bewertet reguläre Ausdrücke aus Pipeline-Konfigurationen. Nach den vorliegenden Angaben kann ein speziell gestalteter regulärer Ausdruck einen Integer Overflow auslösen. Ursache ist eine unzureichende Validierung der Ausdrücke.
Angriffsweg und notwendige Updates bei CVE-2026-97229
Die Grafik zeigt den Weg von einer präparierten Regex über den Integer Overflow im CI/CD-Compiler bis zur nicht authentifizierten Codeausführung sowie die erforderlichen GitLab- und Ruby-Updates.
Ein Angreifer kann darüber beliebigen Code auf der betroffenen Instanz ausführen, ohne sich zuvor anmelden zu müssen. Die zugrunde liegende Schwachstelle liegt in Onigmo, der von Ruby verwendeten Engine für reguläre Ausdrücke. Entdeckt und über das HackerOne-Programm von GitLab gemeldet wurde das Problem von einem Sicherheitsforscher mit dem Pseudonym „joaxcar“.
Die bestätigte Ausnutzung sagt noch nicht, wie viele Systeme tatsächlich kompromittiert wurden. Ebenso liefern die vorliegenden Informationen keinen Beleg dafür, dass ein öffentlicher Proof of Concept oder ein frei verfügbarer Exploit existiert. Belegt sind jedoch beobachtete Angriffsversuche und die Einstufung durch CISA als aktiv ausgenutzte Schwachstelle.
Der Patchstand hängt auch von Ruby ab
GitLab hat CVE-2026-97229 in drei unterstützten Versionszweigen behoben. Betreiber sollten mindestens auf 19.2.8, 19.3.5 oder 19.4.2 aktualisieren – abhängig davon, welchen Zweig sie einsetzen. Ältere Installationen sollten auf eine entsprechend gepatchte, unterstützte Version gebracht werden.
Eine zusätzliche Bedingung gilt für Umgebungen, in denen GitLab mit einer eigenen Ruby-Installation statt mit den vom Hersteller vorgesehenen Komponenten betrieben wird. Dort ist auch Ruby auf 3.3.13, 3.4.12 oder 4.0.9 beziehungsweise eine neuere Version zu aktualisieren. Genau diese Abhängigkeit macht die operative Prüfung wichtiger als die bloße Feststellung, dass ein GitLab-Paket eingespielt wurde.
GitLab.com und GitLab-Dedicated-Instanzen sind nach den verfügbaren Angaben bereits geschützt. Der akute Handlungsbedarf betrifft daher vor allem selbstverwaltete Systeme. Shadowserver erfasst knapp 2.800 aus dem Internet erreichbare GitLab-CE-Instanzen. Diese Zahl ist jedoch nicht mit der Zahl verwundbarer Server gleichzusetzen, weil ihr jeweiliger Patchstand daraus nicht hervorgeht.
Ein fehlgeschlagener Angriff ist bereits dokumentiert
Auf eine GitLab-Instanz des Alpine-Linux-Projekts wurde am 20. und 21. Oktober versucht, die Schwachstelle auszunutzen. Der Angriff war nicht erfolgreich, soll der Ausführung aber nahegekommen sein. Der Vorfall ist damit kein bestätigter Einbruch, liefert jedoch ein konkretes Beispiel dafür, dass Angreifer die Lücke bereits kurz nach Veröffentlichung der Patches gegen reale Ziele eingesetzt haben.
GitLab stellt für Kunden mit selbstverwalteten Instanzen zusätzlich Bedrohungserkennungen bereit. Solche Erkennungen sind relevant, weil ein Update zwar die Schwachstelle schließt, aber eine mögliche frühere Kompromittierung nicht rückgängig macht. Wurde ein ungepatchter Server öffentlich angeboten, sollte die Reaktion deshalb nicht beim Einspielen der neuen Version enden.
GitLab ist nicht nur ein weiterer öffentlich erreichbarer Server
Eine Codeausführung auf einer GitLab-Instanz ist besonders kritisch, weil die Plattform häufig Quellcode, Pipeline-Konfigurationen und Zugangsdaten für nachgelagerte Systeme zusammenführt. Welche Ressourcen ein Angreifer tatsächlich erreicht, hängt von den Berechtigungen des GitLab-Prozesses, gespeicherten CI/CD-Geheimnissen und der Netzanbindung des Servers ab. Die RCE bedeutet daher nicht automatisch die vollständige Übernahme der gesamten Entwicklungsumgebung. Sie schafft aber einen Einstiegspunkt an einer Stelle, die oft weitreichende Vertrauensbeziehungen besitzt.
Betreiber sollten zunächst alle selbstverwalteten GitLab-Instanzen inventarisieren und ihren Versionsstand prüfen. Öffentlich erreichbare Systeme haben Priorität. Danach sind gegebenenfalls die separate Ruby-Laufzeit zu aktualisieren und die von GitLab bereitgestellten Erkennungen auszuwerten. Bei Hinweisen auf eine Kompromittierung gehören eine Untersuchung des Servers sowie die Erneuerung potenziell offengelegter Zugangsdaten und CI/CD-Geheimnisse zur Reaktion.
Der entscheidende operative Punkt liegt damit nicht allein im verfügbaren GitLab-Patch. Individuell angepasste Installationen verschieben einen Teil der Sicherheitsverantwortung auf Komponenten, die außerhalb des üblichen Updatepfads liegen. Wer eine eigene Ruby-Laufzeit verwendet, muss zwei Patchstände kontrollieren – ausgerechnet bei einer Schwachstelle, die bereits aktiv angegriffen wird.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
