Welche Voraussetzungen ein Angreifer erfüllen muss, hat GitLab nicht mitgeteilt. Administratoren können sich daher nicht anhand ihrer Konfiguration als nicht betroffen einstufen; der Sicherheitshinweis nennt keinen Übergangs-Workaround, das Update ist der einzige sichere Schutz. Hinweise auf Angriffe liegen GitLab nach eigenen Angaben nicht vor, und die Lücke war mit Stand 22. Oktober auch nicht im Katalog bekannter ausgenutzter Schwachstellen der US-Behörde CISA gelistet.

Auch wer neun Tage zuvor aktualisiert hat, muss erneut handeln: Das Update vom 12. Oktober deckte nur Versionen ab 19.2 ab, und die neuen fehlerbereinigten Versionen liegen jeweils einen Patch darüber. Entsprechend aktualisierte Instanzen sind damit wieder angreifbar.

Handeln müssen ausschließlich Betreiber selbst verwalteter Installationen. GitLab.com läuft bereits auf der korrigierten Version, und GitLab-Dedicated-Mandanten mit den internen Releases 19.3.5-internal0 und 19.4.2-internal0 oder neuer enthalten den Fix ebenfalls.

GitLab hat die Lücke in sieben Versionen gleichzeitig behoben. Vier davon liegen außerhalb des üblichen Wartungsfensters: Die Richtlinie des Unternehmens deckt das aktuelle Release und die beiden vorangegangenen Monatsreleases ab, derzeit 19.5, 19.4 und 19.3. Zusätzlich wurde der Fix nach Angaben von GitLab auf 18.11.13, 19.0.10, 19.1.9 und 19.2.9 zurückportiert – ein Schritt, den das Unternehmen schweren Problemen vorbehält.

Dass die Lücke so weit zurückreicht, liegt an der betroffenen Komponente: Der Regex-Compiler ist Rubys eingebaute Engine Onigmo, die GitLab in den eigenen Paketen ausliefert und in den eigenen Builds patcht. Eine Schwäche dieser Engine steckt folglich in jedem GitLab-Release seit 7.0.

Für die Suche nach Ausnutzungsversuchen hat GitLab zwei Erkennungsregeln veröffentlicht, benannt “Onigmo native worker crash” und “Org mode render error burst”. Sie gehören zum quelloffenen TLDR-Framework des Unternehmens, das jede Erkennung im Sigma-Format gegen GitLabs eigene Anwendungsprotokolle formuliert.

Es ist bereits die vierte Schwachstelle zur Codeausführung in GitLabs Regex-Engine, die derselbe Forscher mit dem Pseudonym joaxcar binnen eines Monats gemeldet hat – und die erste, die auch Versionen vor 19.2 betrifft. Am 12. Oktober schloss GitLab CVE-2026-97229, ebenfalls ein unauthentifizierter Überlauf im Regex-Compiler mit Bewertung 10.0, in den Versionen 19.2.8, 19.3.5 und 19.4.2. Am 23. September folgten CVE-2026-93577 und CVE-2026-89078, beide mit 9.9 bewertet, die jedoch ein angemeldetes Konto voraussetzen. Die drei früheren Lücken reichten nur bis Version 19.2 zurück.

Insgesamt behebt das Release vom 21. Oktober elf Sicherheitsprobleme: eines kritisch, die übrigen hoch, mittel oder niedrig. Zwei betreffen die Authentifizierung:

  • CVE-2026-15723 (hoch, 8.2): Ein angemeldeter Nutzer kann ein fremdes Konto übernehmen – allerdings nur, wenn ein Administrator sowohl SAML- als auch LDAP-Auto-Linking aktiviert hat.
  • CVE-2026-112212 (hoch, 7.5): Eine Cache-Poisoning-Lücke in GitLabs OAuth- und OpenID-Connect-Endpunkten erlaubt es, bestimmte Anmeldeabläufe auf einen vom Angreifer kontrollierten Server umzuleiten, sofern ein gemeinsam genutzter Cache im Einsatz ist.

Das Update sollte eingeplant werden: Die Releases 19.4.3 und 19.3.6 enthalten Datenbankänderungen, die während des Upgrades ausgeführt werden. Auf Einzelserver-Installationen bedeutet das Ausfallzeit, bis sie abgeschlossen sind. Mehrknoten-Umgebungen können den Patch laut GitLab über das Zero-Downtime-Verfahren ohne Ausfall einspielen.