Ein Regex-Compiler wird zum Einfallstor
GitLab hat am 12. Oktober CVE-2026-97229 behoben, einen Integer-Überlauf mit CVSS 10,0 im Compiler, der reguläre Ausdrücke in der CI/CD-Pipeline-Konfiguration verarbeitet. Unter bestimmten Bedingungen, so GitLabs Sicherheitshinweis, konnte ein nicht authentifizierter Nutzer über einen präparierten regulären Ausdruck in einer CI/CD-Konfiguration beliebigen Code auf dem GitLab-Server ausführen.
Der Hinweis nennt diese Bedingungen nicht, und keiner der drei Berichte, die wir gelesen haben, tut es. Ein Forscher mit dem Kürzel joaxcar meldete die Lücke über GitLabs HackerOne-Bug-Bounty-Programm. GitLab.com läuft bereits mit der gepatchten Version, GitLab-Dedicated-Kunden müssen nichts tun, Administratoren selbst betriebener Instanzen dagegen sofort aktualisieren. Laut heise hatte GitLab bis zum 13. Oktober keine Angriffe gemeldet.
| Release-Linie | Verwundbar | Behoben in |
|---|---|---|
| GitLab 19.2 | Vor 19.2.8 | 19.2.8 |
| GitLab 19.3 | Vor 19.3.5 | 19.3.5 |
| GitLab 19.4 | Vor 19.4.2 | 19.4.2 |
Im selben Release wurden drei Lücken mit hohem Schweregrad behoben. CVE-2026-92883 (8,7) ist eine Cross-Site-Scripting-Lücke. CVE-2026-16301 (8,5) erlaubt Nutzern mit der Developer-Rolle, Pipelines auf geschützten Branches auszuführen. CVE-2026-14814 (8,2) kann zwischengespeicherte Antworten vergiften und geschützte Umgebungsvariablen offenlegen. Heise zählt insgesamt fünf Lücken mit hohem Schweregrad.
Drei kritische GitLab-Lücken in wenigen Wochen
CVE-2026-97229 ist GitLabs dritte kritische Lücke in den vergangenen Wochen, und die vom September zeigte, wie schnell Angreifer reagieren.
| CVE | CVSS | Komponente | Berichtete Folge |
|---|---|---|---|
| CVE-2026-85706 | 10,0 | GitLab CE und EE | Auslesen sensibler Daten wie Zugangsdaten und Geheimnisse ohne Anmeldung, mit Sondierungen binnen Stunden nach Bekanntgabe und einer CISA-Listung einen Tag nach dem Fix |
| CVE-2026-90970 | 9,9 | AI Gateway | Ein angemeldeter Nutzer mit Zugriff auf die Duo Agent Platform konnte aus der Prompt-Template-Sandbox ausbrechen und Befehle ausführen |
| CVE-2026-97229 | 10,0 | Regex-Compiler der CI/CD | Codeausführung ohne Anmeldung, bis zum 13. Oktober ohne gemeldete Angriffe |
Nach der Septemberlücke gab die CISA US-Bundesbehörden drei Tage, ihre Systeme abzusichern. Sie hat seit November 2021 fünf GitLab-Lücken als in Angriffen missbraucht markiert, eine davon von Ransomware-Gruppen genutzt. Bis zum 13. Oktober waren keine Angriffe auf die neue Lücke gemeldet, doch das Tempo vom September ist das, womit man planen sollte.
Warum ein Pipeline-Server ein lohnendes Ziel ist
Ein CI/CD-Server sitzt zwischen Quellcode und Produktion, weshalb Codeausführung auf ihm für Angreifer mehr wert ist als auf den meisten Firmenservern.
Er hält in der Regel die Geheimnisse, die Pipelines zum Bauen, Testen und Ausliefern brauchen, etwa Zugriffstoken und Deploy-Schlüssel, und er kann ändern, was bei Kunden ankommt. GitLab sagt, es habe mehr als 30 Millionen registrierte Nutzer, und mehr als 50 Prozent der Fortune 100 setzten es ein. Selbst zu hosten tauscht Bequemlichkeit gegen Kontrolle darüber, wo Code und Daten liegen, und verlagert die Patch-Pflicht auf Sie. Für Teams mit Datenresidenz-Anforderungen kann das eine bewusste Entscheidung sein, und es macht den Patch-Tag des Herstellers zu Ihrer Frist.
Ein 72-Stunden-Plan für selbst betriebene Instanzen
Behandeln Sie das als 72-Stunden-Aufgabe für jede aus dem Internet erreichbare Instanz und beginnen Sie mit dem Versionscheck.
Erstens lesen Sie Ihre installierte Version aus und vergleichen sie mit 19.2.8, 19.3.5 und 19.4.2, dann bestätigen Sie die genauen Buildnummern in GitLabs eigenem Hinweis. Zweitens planen Sie das Upgrade binnen 72 Stunden, zuerst für jede aus dem Internet erreichbare Instanz. Drittens begrenzen Sie bis dahin, wer den Server erreicht und wer CI/CD-Konfigurationsdateien ändern darf.
Viertens rotieren Sie, wenn Sie eine Offenlegung nicht ausschließen können, die als Pipeline-Variablen gespeicherten Geheimnisse, sobald der Patch eingespielt ist. Fünftens abonnieren Sie GitLabs Sicherheitshinweise, damit der nächste am selben Tag bei einem Menschen ankommt. Die 72 Stunden sind unser Vorschlag für das Zeitfenster und keine Frist von GitLab.
Weiterlesen: Neue NetScaler-Lücke: Zwei Zeilen zeigen Ihr Risiko | GitLabs am schlechtesten bewertete Schwachstelle braucht nur ein öffentliches Projekt
