CVE-2026-97229: das Sternchen hinter GitLabs „unauthentifiziertem“ RCE

Null Zugangsdaten auf dem Papier. Ein Konto in der Praxis.

Null. So viele Zugangsdaten verlangt GitLabs eigener CVSS-Vektor für CVE-2026-97229: AV:N/AC:L/PR:N/UI:N, eine volle 10.0, Codeausführung ohne jede Berechtigung. Eins. So viele Konten brauchten die einzigen zwei Parteien, die das tatsächlich zum Laufen brachten, unabhängig voneinander, bevor sie die Anfrage senden konnten, die überhaupt etwas bewirkte. Beide Zahlen sind richtig. Sie beschreiben zwei verschiedene Schritte im selben Angriff.

CVE-2026-97229 ist ein kritischer Integer-Overflow im CI/CD-Regex-Compiler von GitLab, behoben am 12. Oktober 2026 in den Branches 19.2, 19.3 und 19.4.[1] GitLabs eigenes Advisory beschreibt genau das, was dieser Wert nahelegt: ein präparierter regulärer Ausdruck in einer CI/CD-Konfiguration, gesendet von einem nicht authentifizierten Nutzer, wird unter bestimmten Bedingungen zu beliebiger Codeausführung auf dem Server.[1] Weniger als drei Wochen später nahm die CISA die Lücke in ihren Katalog bekannt ausgenutzter Schwachstellen auf und bestätigte damit, dass sie gegen reale Ziele eingesetzt wird.[2] Nichts davon ist falsch. Es lässt nur das eine Detail aus, das wirklich zeigt, wie exponiert man ist: Um den unauthentifizierten Schritt überhaupt zu erreichen, braucht man zuerst ein Konto.

Was GitLab tatsächlich veröffentlicht hat, und wann

GitLab datierte das Fix-Release auf den 12. Oktober 2026 und veröffentlichte 19.2.8, 19.3.5 und 19.4.2 für die drei betroffenen Branches: 19.2 vor 19.2.8, 19.3 vor 19.3.5, 19.4 vor 19.4.2.[1] GitLab.com lief bereits vor der Veröffentlichung des Advisories auf einem gepatchten Build, und GitLab-Dedicated-Kunden mussten überhaupt nichts tun.[1] Der Forscher, der die Lücke meldete, nutzte das HackerOne-Pseudonym joaxcar und meldete separat einen mittelschweren Open-Redirect-Fehler, CVE-2026-7767, der im selben Release behoben wurde.[1]

Ein Detail änderte sich nachträglich, und das sollte man kennen, bevor man die eigene Versionsnummer prüft. GitLabs ursprüngliche Release-Notes nannten für den 19.3-Branch die Version 19.3.4; am nächsten Tag berichteten Medien, dieser Build habe tatsächlich einen unabhängigen Fix für einen Merge-Request-Seitenfehler enthalten, und 19.3.5 sei das eigentliche Fix-Release für diese CVE, was das aktuelle Advisory inzwischen auch so zeigt.[8] Danach ging es schnell: Rapid7 meldete etwa einen Tag nach der Offenlegung eine unabhängige, funktionierende Reproduktion, etwa vier Tage später folgte ein öffentlicher, namentlich zugeordneter Proof of Concept, und rund siebzehn Tage nach dem ursprünglichen Patch nahm die CISA den Fall in ihre Liste bestätigter Ausnutzung auf.[1][2][4][7] Das ist nicht die Hauptgeschichte dieses Artikels. Aber es lohnt sich, kurz dabei zu verweilen: Ein CVSS-10.0-Fehler in einem Produkt wie GitLab wird schnell bewaffnet, sobald der Patch selbst Angreifern verrät, wo sie suchen müssen.

Die Regex-Engine, die Ihren Befehl ausführt statt Ihren String abzugleichen

Ich habe das nicht selbst nachgestellt. Alles Folgende stammt aus dem Proof of Concept, den Jonah Burgess (GitHub: jburgess-r7) etwa vier Tage nach dem Patch veröffentlichte und ausdrücklich als „erste PoC-Veröffentlichung“ bezeichnete, aus Rapid7s separat gemeldeter Reproduktion und aus GitLabs eigenem Advisory, alle gelesen mit Stand 2. November 2026.[1][3][4] Der Auslöser liegt hinter GitLabs CI-Lint-Endpunkt, demselben, den GitLab selbst nutzt, um eine .gitlab-ci.yml-Datei zu validieren, bevor eine Pipeline läuft. Füttert man ihn mit einem präparierten regulären Ausdruck in der CI/CD-Konfiguration zusammen mit einem Repository-Branch, dessen Pfad einen bestimmten UTF-8-Benennungstrick nutzt, läuft die interne Längenberechnung des Regex-Compilers über.[3]

Dieser Overflow lässt den Worker nicht nur abstürzen, wenngleich das oft ebenfalls passiert. Er lenkt die Ausführung der Regex-Engine um, direkt in eine Funktion, die einen beliebigen Befehl ausführt.[3] Der Befehl läuft unter GitLabs niedrig privilegiertem Service-Konto „git“, nicht als Administrator und nicht als Root auf dem Host.[3] Das ist eine reale Obergrenze für den Schaden, und das sollte man klar aussprechen: Es handelt sich um serverseitige Codeausführung, nicht um einen sofortigen Weg zur vollen Admin-Kontrolle. Aus einer „git“-Shell heraus hat ein Angreifer aber bereits genug in der Hand, angefangen bei Repository-Inhalten und allen CI-Secrets, die dieses Konto lesen kann.

// The CI-lint trigger, reconstructed from Burgess's public PoC. Paraphrased
// shape of the chain -- not the working payload itself.

1. Attacker-controlled branch is pushed to a public project, with a
   specially-named (UTF-8) path and a crafted regex in .gitlab-ci.yml.
2. An unauthenticated request hits GitLab's CI-lint endpoint, which
   validates that regex before any pipeline actually runs.
3. The regex compiler's internal length accounting overflows -- an
   integer wraps where it shouldn't.
4. Execution inside the regex engine is redirected into a function that
   runs an OS command, as the low-privilege "git" service account.
5. On a vulnerable build, the worker process frequently crashes right
   after (a bare HTTP 502 is a side effect, not proof by itself).

Der Schritt, der vor dem unauthentifizierten passiert

Hier ist das Detail, das jede CVSS-10-Schlagzeile auslässt. Burgess’ eigenes README nennt die Voraussetzungen klar: ein gewöhnliches Konto, das auf der Zielinstanz einen Branch in ein öffentliches Projekt pushen kann; ein Ziel, das genau auf dem offiziellen Build gitlab/gitlab-ce:19.4.1-ce.0 läuft (alles andere braucht neu erstellte Binary-Offsets); rund 9 GiB freien Speicher; und Netzwerkerreichbarkeit zu einem Listener, falls man die Ausgabe des Befehls will.[3] Die CI-Lint-Anfrage, die den Overflow tatsächlich auslöst, braucht weder Token noch Cookie noch Authorization-Header, dieser Teil ist wirklich unauthentifiziert.[3][4] Nur ist er nicht der erste Schritt.

Laut Help Net Security reproduzierte Rapid7 unabhängig eine funktionierende Codeausführung gegen ein ungepatchtes offizielles GitLab-CE-19.4.1-Image, etwa einen Tag nach der Offenlegung (dieselbe Eingabe schlug gegen das gepatchte 19.4.2-Image fehl), und beschrieb dieselbe Hürde: ein „gewöhnliches Konto“, das den präparierten Branch pusht, umsetzbar „auf selbst gehosteten Instanzen, die die Erstellung öffentlicher Projekte erlauben“.[4] Zwei getrennte Parteien, die unabhängig voneinander arbeiteten, kamen auf dieselbe Voraussetzung. Ich weise auf etwas hin, das die Belege tatsächlich nicht sagen, weil es verlockend ist, beides zu vermischen: Das GitHub-Handle des PoC trägt das Suffix „-r7“, und sein eigenes README verlinkt auf „Rapid7s technische Analyse“ derselben Lücke. Keine Quelle nennt diese Verbindung direkt, daher behandle ich Burgess’ PoC und Rapid7s Reproduktion so, wie es die Belege tatsächlich zeigen: als zwei unabhängig voneinander entstandene Bestätigungen derselben Voraussetzung, nicht als eine.

Der PoC-Autor ist auch offen über die Grenzen seiner Arbeit: 10 von 10 Versuchen gelangen gegen den einen getesteten Build mit aktiviertem ASLR, dieselbe Eingabe liefert beim gepatchten 19.4.2-Compiler false, und der Autor schreibt ausdrücklich, dass „die Analyse weiterer betroffener Konfigurationen und erreichbarer Pfade noch läuft“ und dass der PoC „keine reale Ausnutzung bei Angriffen belegt“.[3] Ein erfolgreicher Trigger liefert oft nur ein nacktes HTTP 502, weil der Worker direkt nach der Befehlsausführung abstürzt, ein 502 allein, ohne das übrige Muster, beweist also nichts.[3] Diesen Unterschied sollte man im Kopf behalten. Er entscheidet, was man aus den eigenen Logs tatsächlich herauslesen kann.

Wie weit „unauthentifiziert“ tatsächlich reicht

Was ist es nun: unauthentifiziert oder nicht? Beides, je nachdem, welche Grenze gemeint ist. GitLabs CVSS-Vektor bewertet die verwundbare Komponente mit PR:N, keine Berechtigung erforderlich, und das stimmt genau für das, was tatsächlich bewertet wird: Die CI-Lint-Anfrage selbst prüft kein Zugangsdatum.[1] Aber „die Komponente braucht keine Authentifizierung“ und „die Angriffskette braucht keine Authentifizierung“ sind zwei verschiedene Aussagen, und die einzigen zwei namentlich genannten Parteien, die das praktisch zum Laufen brachten, Burgess und Rapid7, stimmen unabhängig voneinander darin überein, dass die Kette vor dieser Anfrage einen Schritt braucht: ein Konto, das einen Branch in ein öffentliches Projekt pushen kann.[3][4] GitLabs Schweregrad-Einstufung ist nicht falsch. Sie beantwortet nur eine engere Frage, als die Schlagzeile nahelegt.

Ob diese Voraussetzung trivial ist oder eine echte Hürde, hängt von Einstellungen ab, die die meisten Admins nicht als Schutzmaßnahme gegen diese CVE betrachten. GitLabs eigene Dokumentation sagt, dass Selbstregistrierung auf einer selbst gehosteten Instanz standardmäßig für jeden Besucher offen ist, und empfiehlt, sie auf allem öffentlich erreichbaren zu deaktivieren, das keine offene Registrierung erwartet.[5] Sie sagt auch, dass die Admin-Freigabe neuer Registrierungen seit GitLab 13.6 der Standard für neue Instanzen ist, eine halbwegs aktuelle, halbwegs sauber konfigurierte Instanz hat also bereits einen Menschen in der Schleife, bevor ein Fremder ein Konto bekommt.[5] Projektsichtbarkeit, und wer ein öffentliches Projekt anlegen darf, ist separat vom Admin konfigurierbar.[5] Nichts davon ist ein Patch. Aber all das verändert, wie viele Fremde überhaupt an die unauthentifizierte Hälfte dieser Lücke herankommen.

// For a stranger to turn this into RCE against your instance,
// three things have to be true at once:

1. Your instance allows self-registration, OR the attacker already
   holds any ordinary account on it.
2. That account (or self-registration) can create, or push a branch
   to, a PUBLIC project -- not just a private one.
3. The instance is still running an unpatched build
   (before 19.2.8 / 19.3.5 / 19.4.2) and is reachable from wherever
   the attacker is.

Close registration, restrict who can make projects public, or patch --
any one of the three breaks the chain. Patching is still the only fix
that doesn't depend on a setting staying the way you left it.

Ausnutzung bestätigt. Fast alles andere nicht.

Die CISA nahm CVE-2026-97229 am 29. Oktober 2026 unter dem Namen „GitLab Community Edition and Enterprise Edition Integer Overflow or Wraparound Vulnerability“ in ihren Katalog bekannt ausgenutzter Schwachstellen auf, mit einer Frist zur verpflichtenden Maßnahme bis zum 1. November gemäß Binding Operational Directive 26-04.[2] Dieses Aufnahmedatum ist keine Aussage darüber, wann die Ausnutzung tatsächlich begann. KEV-Einträge hinken dem realen Beginn der Ausnutzung regelmäßig hinterher, und keine der hier geprüften Quellen nennt, wann Angriffe auf diese Lücke tatsächlich anfingen. Lesen Sie „29. Oktober“ als das Datum, an dem die CISA es bestätigte, nicht als Zeitstempel der Angriffe selbst.

Hier ist der ehrliche Umfang dessen, was „bestätigte Ausnutzung“ in diesem Fall bedeutet, und es lohnt sich, hier präzise zu sein, weil der tatsächliche Kenntnisstand dünner ist, als die Schlagzeile nahelegt: Keine für diesen Artikel geprüfte Quelle, nicht der Eintrag der CISA selbst, nicht GitLabs Advisory, nicht die Berichterstattung von BleepingComputer dazu, veröffentlicht einen Kompromittierungsindikator, ein benanntes Opfer oder eine Beschreibung der beobachteten Angriffe auf Technikebene.[1][2][6] Der Folgeartikel von BleepingComputer verweist auf GitLabs eigene Threat-Detection-Veröffentlichungen und Shadowservers Zählung von rund 2.800 aus dem Internet erreichbaren GitLab-CE-Instanzen, und das ist der gesamte verfügbare öffentliche Detailgrad.[6] „Bestätigte Ausnutzung“ stützt sich hier auf den Eintrag der CISA als namentlich genannte Autorität, nicht auf Angriffsbelege, die dieser Artikel unabhängig prüfen konnte. Das ist eine legitime Grundlage für diese Einschätzung. Es ist aber auch die Obergrenze dessen, was ich ehrlich über die Angriffe selbst sagen kann.

Der Patch, die Regeln, und was diese Woche zu prüfen ist

Der Fix ist exakt versioniert: 19.2.8, 19.3.5 und 19.4.2, alle veröffentlicht am 12. Oktober 2026.[1] Zeigt Ihr 19.3-Branch 19.3.4, hat dieser Build einen unabhängigen Merge-Request-Seitenfehler behoben, nicht diese CVE; 19.3.5 ist die Version, die Sie tatsächlich brauchen.[8] Zusammen mit dem Patch veröffentlichte GitLab sechs neue Threat-Detection-Regeln für selbst gehostete Instanzen, die namentlich genau auf dieses Problem zugeschnitten sind: Onigmo native worker crash, GraphQL cilint hostile regexp, ci regexp oversized non-ascii path, ci regexp guard rejection, ci lint workhorse worker crash und ci lint scripted client error burst.[1] Zeigt Ihr eigenes Monitoring oder GitLabs Erkennungen eine davon an, behandeln Sie das als Signal, dem man nachgehen sollte, nicht als Rauschen.

GitLabs eigene Offenlegungsrichtlinie veröffentlicht vollständige Issue-Tracker-Details für eine behobene Schwachstelle 90 Tage nach dem Fix-Release, was nach einfacher Rechnung alles über den Advisory-Text hinaus auf etwa Mitte Januar 2027 legt, kein Datum, das GitLab selbst nennt, sondern nur das, was aus der eigenen 90-Tage-Regel folgt.[1] Bis dahin ist hier, was der öffentliche Kenntnisstand tatsächlich an Prüfungen stützt.

Patch and verify, in order:
  [ ] Confirm the build actually RUNNING, not just what the changelog
      says: 19.2.8 / 19.3.5 / 19.4.2 or later.
  [ ] If self-managed, review sign-up restrictions: is self-registration
      open, and is admin approval of new accounts actually enabled?
  [ ] Review who can create or push to a PUBLIC project on your instance
      -- that setting is the other half of this bug's real exposure.
  [ ] Enable and watch GitLab's six named threat detections for this CVE,
      especially "ci lint workhorse worker crash" and "ci regexp guard
      rejection".
  [ ] Check CI-lint access logs for requests with no auth header paired
      with recently-pushed branches on public projects -- that pairing
      is this chain's fingerprint, a bare HTTP 502 is not.

Ein CVSS-Wert bewertet die Lücke. Nicht Ihre Instanz.

CVE-2026-97229 ist eine echte kritische Schwachstelle, und die Einschätzungen von GitLab und der CISA sind beide richtig. Was die Zahl allein nicht verrät, ist, ob Ihre Instanz die weit offene Art ist, für die diese Kette gebaut wurde, oder die Art, bei der Registrierung geschlossen und Projektsichtbarkeit gesperrt ist. Die zweite Instanz ist ein deutlich kleineres Ziel, selbst für eine aktiv ausgenutzte CVSS-10.0-Lücke. Der Schweregrad bewertet eine Komponente. Die Angriffsfläche ist eine Eigenschaft Ihrer Konfiguration, und die bewertet niemand für Sie.

Genau das ist die Lücke, nach der ich bei einer Web-Application- oder CI/CD-Pipeline-Prüfung suche: nicht nur „ist das gepatcht“, sondern „was bringt die unauthentifizierte Hälfte einer bestimmten Lücke einem Angreifer hier wirklich, angesichts dessen, wie diese Instanz tatsächlich konfiguriert ist“. Wenn Sie GitLab selbst hosten, oder irgendeine CI/CD-Oberfläche mit öffentlich erreichbaren Teilen betreiben, und lieber jemanden diese Grenze mit Ihnen durchgehen lassen als dem CVSS-Wert einfach zu vertrauen, ist das genau die Art von Prüfung, die ich anbiete. Sagen Sie mir, wie Ihre Instanz tatsächlich konfiguriert ist, und wir stecken ab, was zählt.