GitLab CVSS 10: Update für jede selbst betriebene Instanz

Was passiert ist

GitLab veröffentlicht Sicherheitskorrekturen in Patch-Releases, die mehrere Versionszweige zugleich bedienen. Das Release vom 21. Oktober 2026 bringt die Versionen 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 und 18.11.13, jeweils für die Community Edition und die Enterprise Edition. Es schließt zwölf Lücken: eine kritische, zwei hohe, fünf mittlere und vier niedrige.

Die kritische ist CVE-2026-110264, von GitLab mit CVSS 10,0 bewertet, dem höchsten Wert der Skala. GitLab beschreibt sie als Ganzzahlüberlauf im Compiler für reguläre Ausdrücke beim Verarbeiten eines eigens gebauten Ausdrucks. Die Folge nach den Worten des Herstellers: Die Lücke „could have allowed an unauthenticated user to execute arbitrary code on the GitLab server“. Betroffen sind alle Versionen ab 7.0 vor den genannten Korrekturen. Version 7.0 erschien 2014; die Lücke war also zwölf Jahre im Code.

Die beiden hohen Lücken betreffen die Anmeldung: eine fehlerhafte Authentifizierung beim Abgleich von OmniAuth-Konten mit LDAP per E-Mail-Adresse (CVE-2026-15723, CVSS 8,2) und eine Cache-Vergiftung an den Discovery-Endpunkten für OAuth und OIDC (CVE-2026-112212, CVSS 7,5). Für Instanzen, die ihre Nutzer über ein Verzeichnis oder einen Identitätsanbieter anmelden, sind auch diese beiden ein Grund, das Update nicht zu verschieben.

Es ist die zweite kritische Korrektur innerhalb von neun Tagen. Am 12. Oktober hatte GitLab mit den Versionen 19.4.2, 19.3.5 und 19.2.8 bereits 24 Lücken geschlossen, darunter CVE-2026-97229, ebenfalls CVSS 10,0, ein Ganzzahlüberlauf im Compiler für reguläre Ausdrücke in der CI/CD-Konfiguration. Diese erste Lücke betraf nur die Zweige 19.2 bis 19.4. Die zweite reicht bis 7.0 zurück, und sie steckt auch in den Versionen vom 12. Oktober. Wer damals aktualisiert hat, ist heute wieder an der Reihe.

Einen Workaround nennt GitLab nicht, und einen Angriff meldet die Seite nicht. Die Details zu den Fehlern veröffentlicht GitLab nach seiner Regel 90 Tage nach dem Release, also im Januar 2027. Bis dahin gilt: Was im Code steht, lässt sich aus dem Unterschied zwischen alter und neuer Version ablesen, und Angreifer lesen solche Unterschiede.

Wer betroffen ist

GitLab.com läuft nach Angaben des Herstellers bereits auf der korrigierten Version; GitLab Dedicated, die vom Hersteller betriebene Einzelinstanz, ebenso. Wer sein Projekt dort hält, muss nichts tun.

Alle anderen schon: jede selbst betriebene Instanz, Community oder Enterprise Edition, in jeder Version seit 2014. Für Agenturen heißt das drei Gruppen. Das eigene GitLab, oft vor Jahren aufgesetzt und seitdem zuverlässig im Dienst. Die Instanzen, die eine Agentur für Kunden betreibt oder einmal eingerichtet hat, mit oder ohne Wartungsvertrag. Und die Instanzen in Kundennetzen, auf denen die Agentur nur Gast ist, deren Ausfall oder Kompromittierung sie aber trifft, weil der Code ihrer Projekte dort liegt.

Ein Punkt verdient Nachdruck: Die Lücke braucht keine Anmeldung. Ein GitLab, das nur im Firmennetz oder hinter einem VPN erreichbar ist, ist deshalb nicht sicher, sondern nur für weniger Angreifer erreichbar. Jeder, der die Instanz im Netz ansprechen kann, kann den Fehler auslösen: ein kompromittierter Arbeitsplatz, ein Gast im WLAN, ein Partner mit VPN-Zugang. Erreichbarkeit zu begrenzen ist richtig und verkleinert das Fenster; es ersetzt das Update nicht.

Warum ein Regex-Compiler alles öffnet

Ein regulärer Ausdruck ist ein kleines Programm: eine Suchvorschrift wie ^release-.*$, die eine Bibliothek vor dem ersten Einsatz in eine interne Form übersetzt. Diese Übersetzung ist der Compiler. Er rechnet aus, wie viel Speicher die interne Form braucht, legt den Speicher an und füllt ihn. Läuft eine dieser Rechnungen über, weil der Ausdruck so gebaut ist, dass eine Zahl größer wird, als die Variable fassen kann, ist der angelegte Speicher zu klein. Das Füllen schreibt dann über sein Ende hinaus, und wer den Ausdruck geliefert hat, bestimmt, was dort landet. So wird aus einer Suchvorschrift Code, der mit den Rechten des GitLab-Prozesses läuft: mit Zugriff auf jedes Repository, jede CI-Variable und jeden Token der Instanz.

Solche Bibliotheken sind in C geschrieben, weil Suchen schnell sein muss, und C prüft Speichergrenzen nicht von selbst. GitLab ist in Ruby geschrieben, und Rubys Bibliothek für reguläre Ausdrücke heißt Onigmo. Eine der beiden Erkennungen, die GitLab für selbst betriebene Instanzen nennt, heißt „Onigmo native worker crash“: ein Absturz genau dieser Bibliothek in einem Arbeitsprozess. Die zweite heißt „Org mode render error burst“, eine Häufung von Fehlern beim Darstellen von Org-Mode-Dateien, einem Textformat, das GitLab in Repositories rendert. GitLab nennt den Angriffsweg nicht; die Namen der Erkennungen deuten aber auf ihn.

Entscheidend ist, wo in einer Anwendung fremder Text zu einem regulären Ausdruck wird. In einer Plattform wie GitLab gibt es viele solcher Stellen: die CI/CD-Konfiguration, in der Regeln Branch-Namen per Ausdruck filtern, das Rendern von Markup, das Muster im Text sucht, die Suche selbst. Die Lücke vom 12. Oktober lag nach GitLabs Angaben in der CI/CD-Konfiguration; wer eine Datei in ein Repository schreiben konnte, konnte den Ausdruck liefern. Für die Lücke vom 21. Oktober genügt offenbar weniger als ein Konto, denn GitLab stuft sie als „unauthenticated“ ein. Das ist die allgemeine Lehre dieser Klasse von Fehlern: Jede Stelle, an der Nutzereingaben eine Bibliothek in C erreichen, ist eine Grenze, und an Grenzen entstehen die schwersten Lücken.

Was Sie jetzt prüfen

Für eine Agentur mit einer oder mehreren GitLab-Instanzen ist das Update selbst der kleinere Teil der Arbeit. Der größere ist, keine Instanz zu vergessen und zu wissen, ob eine davon in der Zwischenzeit angegriffen wurde.

1. Inventar. Jede GitLab-Instanz, die Sie betreiben oder einmal eingerichtet haben: die eigene, die bei Kunden, die Testinstanz von damals, die Instanz im Kundennetz, auf der Ihre Projekte liegen. Für jede ein Name, wer sie wartet und wie sie erreichbar ist.
2. Version. Die laufende Version steht im Admin-Bereich unter Übersicht und unter /help. Alles unterhalb der korrigierten Version des jeweiligen Zweigs ist verwundbar, auch 19.4.2, 19.3.5 und 19.2.8 vom 12. Oktober.
3. Update-Pfad. GitLab lässt sich nicht beliebig weit springen; der Hersteller gibt für jede Ausgangsversion einen Pfad über Zwischenversionen vor. Für den ältesten noch versorgten Zweig ist die Korrektur 18.11.13. Eine Instanz auf einem Knoten steht während der Datenbankmigrationen still, bei mehreren Knoten gibt es ein Verfahren ohne Ausfall. Vor dem Update ein Backup, und zwar eines, dessen Wiederherstellung Sie schon einmal geprobt haben.
4. Spuren. GitLab nennt zwei Erkennungen für selbst betriebene Instanzen: Abstürze von Arbeitsprozessen in der Bibliothek Onigmo und eine Häufung von Render-Fehlern bei Org-Mode-Dateien. Suchen Sie beides in den Logs von Puma und Sidekiq für die Zeit seit dem 21. Oktober, besser seit dem 12.
5. Erreichbarkeit. Ein GitLab, das aus dem Internet erreichbar ist, gehört hinter eine Stelle, die Nutzer anmeldet, bevor eine Anfrage die Anwendung erreicht: ein VPN oder ein Proxy, der Identitäten prüft. Das verkleinert den Kreis derer, die eine solche Lücke auslösen können, von allen auf die Berechtigten. Wie so eine Stelle vor einer internen Anwendung aussieht, beschreibt der Beitrag zum internen CRM.
6. Rotation, wo Zweifel bleiben. Zeigt eine Instanz, die ungepatcht erreichbar war, eine der beiden Erkennungen, behandeln Sie sie als kompromittiert: Runner-Token, Deploy-Keys, CI-Variablen mit Secrets, Personal Access Tokens und die Zugangsdaten, die in Pipelines stecken, neu ausstellen. Wie eine Rotation in fester Reihenfolge läuft, steht im Beitrag zu Railway und Zeabur.
7. Kunden informieren. Welche Instanz betroffen war, wann sie aktualisiert wurde, ob Spuren gefunden wurden. Ein Wartungsvertrag, der Sicherheitsupdates mit Frist regelt, macht diese Nachricht zur Routine.

Selbst betreiben oder nicht

Die Woche eignet sich, die Frage ehrlich zu stellen. Ein selbst betriebenes GitLab hat gute Gründe: Der Code liegt dort, wo Sie ihn haben wollen, bei Kundenprojekten oft eine vertragliche Vorgabe; die Instanz hängt an keinem fremden Konto und keiner fremden Preisliste; Runner, Netz und Backup sind Ihre Sache. Diese Kontrolle kostet eine Pflicht: GitLab veröffentlicht regelmäßig Patch-Releases und kritische Korrekturen, sobald sie fertig sind, im Oktober zwei innerhalb von neun Tagen. Jede davon ist für den Betreiber eine Aufgabe von Stunden, mit Backup, Update-Pfad, Migrationen und Nachkontrolle, und sie kommt ohne Rücksicht auf den Kalender.

Der Unterschied dieser Woche in einem Satz: GitLab.com war gepatcht, bevor die Lücke öffentlich wurde; eine selbst betriebene Instanz ist gepatcht, wenn ihr Betreiber handelt. Wer die Instanz behält, sollte die Pflicht in den Betrieb einbauen: eine Person, die die Release-Mitteilungen liest, ein geprobtes Update-Verfahren, ein Backup, dem man traut, und eine Erreichbarkeit, die nur Berechtigte einschließt. Wer das nicht leisten will, ist mit einer vom Hersteller betriebenen Instanz besser bedient und sollte die Datenlage dort vertraglich klären, statt sie durch eigenen Betrieb zu erzwingen.

Was das für obhut heißt

Der Quellcode von obhut liegt in einem Projekt auf gitlab.com, das GitLab vor der Veröffentlichung der Lücke gepatcht hat. Eine eigene GitLab-Instanz betreibt obhut nicht. Der CI-Runner in der EU, den wir aufbauen, ist ein Runner, der mit gitlab.com spricht, kein GitLab-Server; er führt keinen GitLab-Servercode aus, den diese Lücke betreffen könnte. Unser Release-Prozess verlangt einen signierten Commit und führt die Prüfungen auf genau dem Baum aus, der ausgeliefert wird; er hängt nicht davon ab, ob GitLab erreichbar ist.

Häufige Fragen

Mein GitLab ist nur im Firmennetz erreichbar. Muss ich trotzdem sofort aktualisieren?

Ja. Die Lücke braucht keine Anmeldung, nur Erreichbarkeit. Ein kompromittierter Arbeitsplatz im Firmennetz, ein Gast im WLAN oder ein Partner mit VPN-Zugang reicht aus. Die Begrenzung auf das Firmennetz verkleinert den Kreis möglicher Angreifer und ist richtig; sie ersetzt das Update nicht.

Ich habe am 12. Oktober aktualisiert. Reicht das?

Nein. Die Versionen vom 12. Oktober, 19.4.2, 19.3.5 und 19.2.8, schließen die erste kritische Lücke, enthalten aber die zweite. Nötig sind 19.4.3, 19.3.6 oder 19.2.9, oder die jeweils neuere Version des eigenen Zweigs.

Gibt es einen Workaround, bis das Update eingeplant ist?

GitLab nennt keinen. Was Sie bis zum Update tun können, ist die Erreichbarkeit einschränken und die Logs auf die beiden Erkennungen prüfen. Beides verkleinert das Fenster; schließen tut es nur das Update.

Woran erkenne ich, ob jemand die Lücke bei mir versucht hat?

An den beiden Erkennungen, die GitLab nennt: Abstürze von Arbeitsprozessen in der Bibliothek Onigmo und eine Häufung von Fehlern beim Darstellen von Org-Mode-Dateien. Beides steht in den Logs der Anwendung. Weitere Details veröffentlicht GitLab 90 Tage nach dem Release, also im Januar 2027.