GitLab hat am 21. Oktober 2026 Korrekturen für eine kritische GitLab-Sicherheitslücke veröffentlicht, die unter CVE-2026-110264 geführt und mit 10 von 10 bewertet wird. Sie kann es einem Angreifer ohne Konto ermöglichen, eigenen Code auf dem Server auszuführen. Betroffen sind alle Versionen von GitLab Community Edition (CE) und Enterprise Edition (EE) seit Version 7.0, die 2014 erschienen ist. Schweizer Unternehmen und Verwaltungen, die GitLab selbst betreiben, müssen eine korrigierte Version installieren.
GitLab dient dazu, den Quellcode einer Organisation zu speichern und ihre Produktivsetzungen zu automatisieren. Ein kompromittierter Server setzt also den gesamten Code der Organisation aufs Spiel. Laut dem Fachportal Inside IT war am 23. Oktober 2026 noch kein Angriff beobachtet worden. Das Medium hält es jedoch für nahezu sicher, dass sich dies rasch ändert.
Was ermöglicht die GitLab-Sicherheitslücke CVE-2026-110264?
Die Lücke geht auf einen Ganzzahlüberlauf beim Kompilieren eines regulären Ausdrucks zurück, also eines Suchmusters in Text. Gemäss dem am 22. Oktober 2026 auf cve.org veröffentlichten Eintrag kann ein präparierter regulärer Ausdruck diesen Überlauf auslösen. Unter bestimmten Bedingungen kann ein nicht authentifizierter Benutzer dann beliebigen Code auf dem GitLab-Server ausführen.
Die Bewertung von 10,0 ist das Maximum der CVSS-Skala (Common Vulnerability Scoring System) in der Version 3.1. Der veröffentlichte Vektor beschreibt einen Angriff über das Netzwerk, mit geringer Komplexität, ohne Berechtigungen und ohne Zutun eines Benutzers. Die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit werden durchwegs als hoch eingestuft.
Gesichert sind somit der Schweregrad der Lücke und die Liste der betroffenen Versionen. Die genauen «Bedingungen» des Angriffs hingegen legt GitLab nicht im Detail offen. Gemeldet wurde die Lücke vom Forscher joaxcar im Rahmen des Belohnungsprogramms von GitLab auf der Plattform HackerOne.
Welche GitLab-Version ist zu installieren?
GitLab empfiehlt allen selbstverwalteten Installationen, umgehend auf eine der sieben korrigierten Versionen zu wechseln. Die Wahl hängt vom bereits installierten Zweig ab, wie die Tabelle aus den Versionshinweisen von GitLab zusammenfasst.
| Installierter Zweig | Zu installierende korrigierte Version |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
| Vor 18.11 | Keine Korrektur: auf einen korrigierten Zweig migrieren |
Für diese Lücke hat GitLab die Korrektur zusätzlich zu seinen üblichen Versionen auf die Zweige 18.11, 19.0, 19.1 und 19.2 zurückportiert. Laut Inside IT wird für Versionen vor 18.11.13 hingegen kein Update angeboten. Eine ältere Instanz muss daher den Zweig wechseln, was mehr Vorbereitung erfordert.
Das Update verläuft nicht immer reibungslos. GitLab weist darauf hin, dass es Datenbankmigrationen enthält, insbesondere in den Versionen 19.4.3 und 19.3.6. Auf einem einzelnen Server führt es zu einem Unterbruch, bis die Migrationen abgeschlossen sind. Eine auf mehrere Server verteilte Installation kann es mit dem passenden Verfahren ohne Ausfall einspielen.
Warum folgt die Ausnutzung so schnell auf eine Korrektur?
Eine veröffentlichte Korrektur macht die Lücke öffentlich, und genau das beschleunigt die Angriffe. Inside IT drückt es so aus: Mit der Veröffentlichung seiner Korrekturen hat GitLab die Lücke bekannt gemacht. Die Angreifer wissen damit, welche Software sie ins Visier nehmen müssen und welche Versionen verwundbar bleiben.
Die Versionshinweise geben übrigens einen Hinweis auf den betroffenen Bereich. Sie erwähnen für jeden Zweig eine Korrektur bei der Verarbeitung regulärer Ausdrücke in Ruby. GitLab hält die technischen Details jeder Lücke während 90 Tagen nach der Korrektur unter Verschluss, die Lücke selbst ist nun aber bekannt.
Der jüngste Fall von PHP zeigt, wie schnell es gehen kann. Bei der PHP-Sicherheitslücke PHP2Shell blockierte Cloudflare bereits neun Stunden vor der offiziellen Veröffentlichung Angriffsversuche, nachdem das Embargo gebrochen worden war. Für GitLab wurde in den konsultierten Quellen nichts Derartiges gemeldet.
Was GitLab.com nicht betrifft
Kundinnen und Kunden, die GitLab online ohne eigenen Server nutzen, müssen nichts unternehmen. GitLab.com läuft bereits mit der korrigierten Version. Kunden von GitLab Dedicated, dem gehosteten Angebot für eine einzelne Organisation, sind geschützt, wenn sie die Versionen 19.3.5-internal0 oder 19.4.2-internal0 oder neuere verwenden.
Betroffen sind also nur selbstverwaltete Installationen: Server von Unternehmen, Verwaltungen, Schulen oder Hostern. GitLab präzisiert, dass ohne gegenteiligen Hinweis alle Installationsarten betroffen sind, ob es sich um das Komplettpaket, eine Installation aus dem Quellcode oder eine Bereitstellung per Helm-Chart handelt.
Elf weitere Lücken nebenbei behoben
Dieselben Versionen beheben elf weitere Lücken, von denen zwei als hoch eingestuft sind. CVE-2026-15723, bewertet mit 8,2, ermöglicht die Übernahme eines bestehenden LDAP-Kontos, wenn zwei Anmeldeeinstellungen, OmniAuth SAML und die automatische LDAP-Verknüpfung, gleichzeitig aktiviert sind. CVE-2026-112212, bewertet mit 7,5, ermöglicht es, einen gemeinsam genutzten Cache zu vergiften, um bestimmte OAuth- oder OIDC-Anmeldungen auf einen externen Server umzuleiten. Die neun übrigen werden als mittel oder niedrig eingestuft.
Was ein KMU oder eine Verwaltung in der Schweiz tun sollte
Der erste Schritt besteht darin, herauszufinden, wer den GitLab-Server verwaltet und welche Version darauf läuft. Die weiteren Schritte ergeben sich aus den Angaben von GitLab:
- die installierte Version mit der Tabelle vergleichen und die korrigierte Version des eigenen Zweigs installieren;
- bei einer Version vor 18.11 die Migration auf einen korrigierten Zweig planen;
- auf einem einzelnen Server den kurzen Unterbruch wegen der Datenbankmigrationen einplanen;
- wenn ein Dienstleister die Instanz verwaltet, bei ihm nachfragen, ob er eine der sieben korrigierten Versionen installiert hat;
- die beiden von GitLab veröffentlichten Erkennungsregeln nutzen, um Ausnutzungsversuche aufzuspüren; sie heissen «Onigmo native worker crash» und «Org mode render error burst»;
- die Benachrichtigungen von GitLab zu Korrekturen abonnieren, per E-Mail oder per RSS-Feed.
Diese Schritte entsprechen den Grundmassnahmen der IT-Sicherheit eines KMU, die mit raschen Updates beginnen.
Was noch nicht bekannt ist
Mehrere Punkte bleiben in den konsultierten Quellen offen:
- die genauen Bedingungen, die den Angriff ermöglichen, sind nicht veröffentlicht;
- die Zahl der selbstverwalteten GitLab-Instanzen in der Schweiz und der Anteil, der noch verwundbar ist, sind nicht bekannt;
- bis zum 23. Oktober 2026 war keine Ausnutzung gemeldet, die Lage kann sich seither aber geändert haben;
- keine der Quellen erwähnt eine Warnung des Bundesamts für Cybersicherheit (BACS) zu dieser Lücke.
