GitLab-Lücke mit Höchstwertung: Codeausführung ohne Anmeldung : Zwölf Jahre Versionshistorie betroffen: Betreiber müssen auch kürzlich gepatchte Server erneut ktualisieren

GitLab hat am 21. Oktober 2026 Sicherheitsupdates unter anderem gegen eine Schwachstelle veröffentlicht, die selbst betriebene Installationen seit Version 7.0 betrifft. Unter bestimmten Bedingungen können nicht-angemeldete Angreifer beliebigen Code auf dem Server ausführen (Remote-Code-Execution, RCE). Das „Common Vulnerability Scoring System“ (CVSS) bewertet die unter CVE-2026-110264 geführte Lücke mit dem Höchstwert 10,0.

Handlungsbedarf besteht für Betreiber selbst verwalteter Instanzen – GitLab.com läuft bereits mit einer korrigierten Version. Auch GitLab-Dedicated-Instanzen mit den internen Versionsständen 19.3.5-internal0 beziehungsweise 19.4.2-internal0 oder neuer enthalten die Korrektur bereits.

Regulärer Ausdruck wird zum Angriff

Die technische Ursache liegt in Onigmo, der in Ruby integrierten Engine für reguläre Ausdrücke. Solche Zeichenfolgen beschreiben Textmuster, etwa für Suchvorgänge oder die Verarbeitung von Inhalten: Bevor die Engine ein Muster auswertet, übersetzt sie es in eine intern ausführbare Form. Bei der Interpretation eines speziell präparierten Ausdrucks kann aufgrund der Schwachstelle ein Ganzzahlüberlauf auftreten – ein Rechenergebnis überschreitet also den darstellbaren Wertebereich. Fehlerhaft weiterverarbeitete Werte können anschließend sicherheitsrelevante Folgen haben – hier bis hin zur Ausführung fremden Codes auf dem GitLab-Server.

GitLab liefert die Engine innerhalb seiner eigenen Pakete aus und integriert Korrekturen in die eigenen Builds. Die betroffene Komponente erklärt damit die ungewöhnliche Reichweite: Die Schwachstelle betrifft zwölf Jahre GitLab-Versionsgeschichte. GitLab hat nicht offengelegt, unter welchen Bedingungen Angreifer die Schwachstelle ausnutzen können. Betreiber können daher anhand ihrer Einstellungen nicht sicher feststellen, ob ihr Server vor einem Angriff geschützt ist. Eine Übergangslösung bis zur Installation des Updates nennt der Hersteller nicht.

GitLab-Update vom 12. Oktober reicht nicht aus

Die neue Lücke ist von zuvor behobenen Fehlern dieses Monats zu unterscheiden, auch wenn die Randbedingungen gleich sind: Am 12. Oktober hatte GitLab bereits CVE-2026-97229 geschlossen – ebenfalls einen Ganzzahlüberlauf im Compiler für reguläre Ausdrücke, ebenfalls ohne erforderliche Anmeldung und ebenfalls mit CVSS 10,0 bewertet. Die damaligen Korrekturen stecken in den Versionen 19.2.8, 19.3.5 und 19.4.2 – diese Versionsstände schützen jedoch nicht vor CVE-2026-110264. Die jetzt erforderlichen Updates liegen jeweils mindestens einen Patchstand darüber.

Bereits die Sicherheitsupdates vom 23. September hatten mit CVE-2026-93577 und CVE-2026-89078 zwei weitere Fehler mit möglicher Codeausführung in der Engine beseitigt. Beide waren mit CVSS 9,9 bewertet, erforderten jedoch ein angemeldetes Benutzerkonto. Anders als die neue Schwachstelle betrafen diese drei früheren Lücken erst Versionen ab 19.2. Alle vier meldete der unter dem Pseudonym joaxcar auftretende Sicherheitsforscher.

Diese Versionsstände schließen die Lücke

GitLab stellt Korrekturen für sieben Versionszweige bereit. Die folgende Übersicht nennt die betroffenen Stände und die jeweils korrigierte Version:

Achtung: Für ältere Installationen bezeichnet die Tabelle einen korrigierten Zielstand, keinen pauschal zulässigen direkten Versionssprung. Der erforderliche Upgradepfad hängt vom vorhandenen Versionsstand ab!

GitLab stellt auch für die älteren Versionsreihen 18.11, 19.0, 19.1 und 19.2 Sicherheitsupdates bereit. Das geht über die übliche Updateversorgung hinaus: Normalerweise erhalten nur die aktuelle und die beiden vorherigen monatlichen Versionen Korrekturen – am 22. Oktober also 19.5, 19.4 und 19.3. Damit können Betreiber vier weitere Versionsreihen gegen die Schwachstelle absichern.

Protokolle können Hinweise auf Angriffsversuche liefern

Zum Veröffentlichungszeitpunkt meldete GitLab keine Hinweise auf eine aktive Ausnutzung. Fehlende Angriffsmeldungen erlauben jedoch keine Aussage darüber, ob eine einzelne Installation bereits angegriffen wurde.

Für die Untersuchung selbst betriebener Instanzen stehen zwei Erkennungsregeln bereit:

• „Onigmo native worker crash“: Hinweise auf Abstürze eines nativen Onigmo-Workers
• „Org mode render error burst“: Hinweise auf gehäuft auftretende Fehler beim Rendern von Org mode-Inhalten

Die Regeln gehören zum quelloffenen Framework Threat, Logs, Detection, Respond (TLDR) – die Dokumentation zur Angriffserkennung erläutert dessen Einsatz. Die Erkennungslogik verwendet das Sigma-Format und wertet die jeweils benötigten GitLab-Protokolle aus.

Die Regeln helfen dabei, mögliche Angriffsversuche zu erkennen; das Sicherheitsupdate bleibt natürlich trotzdem erforderlich. Auch wenn kein Alarm ausgelöst wird, ist das wie üblich kein Beleg dafür, dass ein Server nicht angegriffen wurde: Möglicherweise fehlen Protokolldaten oder die Regeln sind nicht korrekt eingerichtet.

Weitere GitLab-Lücken betreffen die Anmeldung

Die jetzige Veröffentlichung schließt außerdem Schwachstellen in der Kontoverknüpfung und in Anmeldeverfahren: CVE-2026-15723 ist mit CVSS 8,2 bewertet. Ein bereits angemeldeter Benutzer könnte ein anderes Konto übernehmen, wenn die automatische Kontoverknüpfung sowohl für die „Security Assertion Markup Language“ (SAML) als auch für das „Lightweight Directory Access Protocol“ (LDAP) aktiviert ist. Betroffen ist damit eine bestimmte Kombination von Identitätsfunktionen.

CVE-2026-112212 erreicht CVSS 7,5 und betrifft die Discovery-Endpunkte von OAuth und OpenID Connect (OIDC). Diese liefern Informationen, die Clients für die jeweiligen Anmeldeverfahren benötigen. In Umgebungen mit einem gemeinsam genutzten Cache könnten Angreifer manipulierte Antworten im Zwischenspeicher hinterlegen. Bestimmte Anmeldeabläufe ließen sich dadurch auf einen extern kontrollierten Server umleiten.

Jetziges Update erfordert Betriebsplanung

Die Updates auf 19.4.3 und 19.3.6 verändern zudem auch die Datenbank. Läuft GitLab auf einem einzelnen Server, ist der Dienst während dieser Arbeiten vorübergehend nicht verfügbar. Für Installationen auf mehreren Servern bietet GitLab ein Verfahren ohne Betriebsunterbrechung an.

Betreiber sollten vor dem Update prüfen, welche Version installiert ist, welche Zwischenschritte die Aktualisierung erfordert und ob eine Ausfallzeit eingeplant werden muss. Da GitLab die genauen Bedingungen für einen Angriff nicht veröffentlicht hat, bietet nur das Update auf eine korrigierte Version verlässlichen Schutz vor den neuen Lücken.