GitLab Self-Managed braucht jetzt das Update gegen die CVSS-10-Lücke

Betroffen ist jede selbst betriebene GitLab-Instanz unterhalb von 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13. Die Lücke CVE-2026-110264 (CVSS 10.0) erlaubt laut CERT-EU nicht authentifizierten Angreifenden, Code auf dem Server auszuführen. GitLab.com ist bereits gepatcht, Dedicated-Tenants müssen nichts tun. Wer GitLab selbst betreibt, sollte sofort aktualisieren. Aktive Ausnutzung ist nicht gemeldet.

dm-Einordnung: Das ist kein Anlass für Hektik, wohl aber für einen vorgezogenen Wartungstermin: Die Patches sind öffentlich, und eine Bewertung von 10,0 lässt wenig Spielraum für „nächste Woche“.

Welche GitLab-Versionen betroffen sind

GitLab unterscheidet drei Betriebsformen, und nur eine davon verlangt jetzt Handarbeit. Bei „Self-Managed“ installieren und warten Sie die Software selbst, auf eigener Hardware oder in der eigenen Cloud. GitLab.com ist der von GitLab betriebene Dienst, dort läuft laut Hersteller bereits die gepatchte Fassung. GitLab Dedicated ist die von GitLab betriebene Einzelmandanten-Variante; deren Tenants sind ab Version 19.3.5-internal0 beziehungsweise 19.4.2-internal0 abgedeckt und brauchen keine eigene Aktion.

Die Schwachstelle trägt die Kennung CVE-2026-110264. Eine CVE (Common Vulnerabilities and Exposures) ist eine eindeutige Nummer, unter der eine Sicherheitslücke weltweit referenziert wird, sodass Hersteller, Behörden und Scanner dieselbe Lücke meinen. Laut GitLab sind alle Versionen ab 7.0 betroffen, und zwar jeweils bis vor die gepatchte Fassung der eigenen Reihe:

• ab 7.0 bis vor 18.11.13
• 19.0 vor 19.0.10
• 19.1 vor 19.1.9
• 19.2 vor 19.2.9
• 19.3 vor 19.3.6
• 19.4 vor 19.4.3
• 19.5 vor 19.5.1

Die Korrektur steckt in den Patch Releases vom 21.10.2026, also den Sammelupdates, die GitLab außerhalb des regulären Release-Rhythmus für Sicherheits- und Fehlerbehebungen veröffentlicht. Sie gelten für die Community Edition (CE) und die Enterprise Edition (EE). Besonders relevant sind die Backports: Der Fix wurde aus der neuesten Entwicklungslinie auf ältere Reihen zurückportiert, nämlich auf 18.11.13, 19.0.10, 19.1.9 und 19.2.9. Wer also noch nicht auf die aktuelle Hauptversion gewechselt ist, muss nicht zwingend einen Versionssprung wagen, sondern kann innerhalb der eigenen Reihe auf die jeweilige Patch-Stufe gehen.

GitLab spricht eine deutliche Empfehlung aus: Alle Self-Managed-Installationen sollten „immediately“ aktualisiert werden, im Original mit dem Zusatz „strongly recommend“. Das ist Herstellerwortlaut und damit eine Herstellerbewertung, die allerdings durch die Einstufung von CERT-EU gestützt wird, einer unabhängigen Stelle, die Sicherheitsmeldungen für die Institutionen der EU bündelt.

Für die Praxis heißt das: Prüfen Sie zuerst, welche Reihe Ihre Instanz fährt. Liegt sie unter der gepatchten Stufe Ihrer Reihe, sind Sie betroffen. Liegt Ihre Instanz in einer Reihe, die in der Liste oben nicht vorkommt, etwa einer älteren als 18.11, gibt es laut GitLab keinen Backport; dort bleibt nur der Wechsel auf eine unterstützte Reihe.

Warum CVSS 10 hier ohne Login gilt

CVSS (Common Vulnerability Scoring System) bewertet Schwachstellen auf einer Skala von 0 bis 10. Die 10,0 ist die Obergrenze und wird nur vergeben, wenn die Kombination aus Erreichbarkeit, Voraussetzungen und Auswirkung maximal ungünstig ausfällt. Im Vektor von CVE-2026-110264 stehen dafür zwei Kürzel, die den Unterschied zu vielen anderen „kritischen“ Lücken machen.

AV:N steht für Attack Vector Network: Die Schwachstelle lässt sich über das Netzwerk erreichen, ein physischer oder lokaler Zugang ist nicht nötig. PR:N steht für Privileges Required None: Es sind keine Berechtigungen erforderlich, die Angreifenden brauchen also kein Konto und kein Passwort. Zusammen bedeutet das, dass eine Instanz, die aus dem Internet erreichbar ist, die Voraussetzungen bereits mitbringt. Viele Lücken in Entwicklungsplattformen setzen dagegen ein gültiges Benutzerkonto voraus, was den Kreis möglicher Angreifender deutlich verkleinert.

Zur Fehlerklasse nennt CERT-EU in seinem Advisory 2026-019 vom 22.10.2026 einen kritischen Integer-Overflow im Regex-Compiler, der nicht authentifizierte Codeausführung ermöglicht. Mehr gehört aus Verteidigungssicht nicht in diesen Text. Ein Advisory ist dabei eine Sicherheitswarnung, die Betroffene, Risiko und empfohlene Maßnahmen bündelt; es ist keine Meldung über einen konkreten Vorfall.

Gemeldet wurde die Lücke über die Plattform HackerOne von der Forscherin oder dem Forscher mit dem Namen joaxcar. Über HackerOne läuft das Bug-Bounty-Programm, mit dem GitLab Hinweise auf Schwachstellen entgegennimmt. dm-Einordnung: Üblicherweise ist ein solcher Weg ein gutes Zeichen: Die Lücke wurde nach dem Fund an den Hersteller gegeben, der den Fix vorbereiten konnte. Ob und wann sie zuvor jemand anderes kannte, lässt sich aus den Angaben nicht ableiten.

Wichtig ist die Trennung zwischen drei Zuständen: Eine Schwachstelle existiert, ein Angriff ist theoretisch möglich, und eine Ausnutzung ist nachgewiesen. Für CVE-2026-110264 ist nur der erste Zustand belegt, ergänzt um die Einschätzung, dass ein Angriff ohne Login möglich wäre. Aktive Ausnutzung ist nicht gemeldet, ebenso wenig sind öffentlich Beispielcode oder Indikatoren genannt. Das ist keine Entwarnung, denn fehlende Meldung ist kein Beweis des Fehlens. Es erklärt aber, warum die Behörden zur schnellen Aktualisierung raten, ohne von laufenden Angriffen zu berichten.

Anders liegt der Fall bei Lücken, die bereits ausgenutzt werden, wie bei einer Schwachstelle im Cisco Secure Email Gateway mit aktiver Ausnutzung. Dort kommt zur Dringlichkeit die Frage hinzu, ob bereits etwas passiert ist; hier lautet sie vorerst nur, ob Sie schneller sind als jemand, der den Patch analysiert.

Was neben der kritischen Lücke im Patch steckt

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptFemale system administrator at night applying a security update on a laptop in a server room, focused expression, screen glow on her face. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Ein Patch Release bringt selten nur eine einzige Korrektur. Laut CERT-EU stecken in den GitLab-Updates neben der kritischen Lücke zwei Schwachstellen mit hoher Einstufung, fünf mit mittlerer und vier mit niedriger. In der Summe sind das zwölf Sicherheitslücken; GitLab listet in seinem Patch Release ebenfalls zwölf CVE-Einträge mit Einstufung und betroffenen Versionen auf.

Für die Entscheidung im Betrieb ist das mehr als eine Fußnote. Die Frage, ob man ein Update einspielt, stellt sich bei einer 10,0 praktisch nicht. Zögern Sie, weil ein Wartungsfenster nicht passt oder der Umzug auf eine neuere Reihe Tests verlangt, sollten Sie wissen, dass Sie mit dem Aufschub nicht nur eine, sondern ein ganzes Paket an offenen Lücken in Kauf nehmen. Auch hohe und mittlere Einstufungen können in Kombination relevant werden, etwa wenn ein Konto bereits kompromittiert ist. Das ist eine dm-Einordnung, keine Aussage aus dem Advisory.

Neben CERT-EU hat auch die Cyber Security Agency of Singapore (CSA) am 22.10.2026 unter der Kennung AL-2026-152 einen Alert zur selben Lücke veröffentlicht. Zwei unabhängige Behörden, die dieselbe Schwachstelle zeitgleich als warnungswürdig einstufen, sind ein belastbares Indiz dafür, dass die Einstufung nicht allein auf der Herstellerdarstellung beruht. Gleichwohl handelt es sich um die Bewertung derselben zugrunde liegenden Informationen; ein zusätzlicher Erkenntnisgewinn über Angriffe folgt daraus nicht.

Für Teams, die ohnehin ein Inventar ihrer Software und deren Lücken pflegen, ist der Fall ein Praxistest: Können Sie in Ihrem Bestand schnell beantworten, welche GitLab-Instanzen in welcher Reihe laufen und welche aus dem Internet erreichbar sind, sind Sie in Minuten fertig. Wie ein solches Inventar im Zusammenhang mit der KEV-Liste der bekanntermaßen ausgenutzten Lücken geführt wird, entscheidet am Ende darüber, ob aus einer Advisory-Meldung ein Nachmittag oder ein Wochenende Arbeit wird.

Zur Einordnung der Dringlichkeit hilft eine einfache Unterscheidung. Die kritische Lücke bestimmt den Zeitplan, denn sie benötigt weder Konto noch Interaktion. Die übrigen elf bestimmen den Umfang: Nur ein vollständiges Einspielen der Patch-Release-Version beseitigt sie alle. Einzelne Gegenmaßnahmen wie das Sperren von Funktionen sind nicht beschrieben und sollten deshalb nicht als Ersatz für das Update gelten.

Wie Sie prüfen, ob die Instanz angegriffen wurde

CERT-EU empfiehlt, schnellstmöglich zu aktualisieren, dabei internetexponierte Assets zuerst zu behandeln und anschließend ein Assessment auf kompromittierte Assets durchzuführen. „Assets“ meint hier jede betroffene Instanz, vom produktiven Server bis zur vergessenen Testinstallation. Internetexponiert heißt: Die Instanz ist ohne VPN oder Vorschaltschutz von außen erreichbar. Gerade bei Self-Managed-Installationen gibt es oft mehr davon, als im Inventar steht, etwa eine Instanz für ein Altprojekt oder einen Dienstleister.

Eine Kompromittierungsprüfung ist notwendig, weil ein Update nur die Lücke schließt, nicht aber nachträglich beseitigt, was zuvor geschehen sein könnte. Für diese Lücke ist keine aktive Ausnutzung gemeldet, und es sind keine Indikatoren veröffentlicht, an denen sich ein Befall festmachen ließe. Die Prüfung ist damit eine Vorsichtsmaßnahme und kein Hinweis auf einen Verdacht.

GitLab liefert für Self-Managed-Instanzen zwei Detections. Eine Detection ist eine Erkennungsregel, die in Logs oder Überwachungssystemen nach einem bestimmten Muster sucht und einen Alarm auslöst. Die beiden Regeln heißen „Onigmo native worker crash“ und „Org mode render error burst“. Beide lassen sich über die Hinweise des Herstellers einbinden; Details zu den Mustern stehen dort, und hier sind sie bewusst nicht wiedergegeben. Wichtig ist die Grenze solcher Regeln: Ein ausbleibender Alarm beweist nicht, dass nichts geschah, und ein Alarm ist nicht automatisch ein Angriff, sondern zunächst ein Anlass zur Untersuchung.

Aus Verteidigungssicht ergibt sich folgende Reihenfolge, als dm-Einordnung auf Basis der CERT-EU-Empfehlung und ohne weitere Quelle für die einzelnen Schritte:

1. Inventar und Versionen klären: Welche Instanzen laufen, in welcher Reihe, welche sind aus dem Internet erreichbar?
2. Internetexponierte Instanzen zuerst auf die gepatchte Stufe ihrer Reihe heben: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 oder 18.11.13.
3. Die beiden GitLab-Detections einrichten und die Logs der vergangenen Tage auf Auffälligkeiten durchsehen, insbesondere auf unerklärliche Abstürze oder Fehlerhäufungen.
4. Zugangsdaten bewerten: Wo ein Verdacht besteht, Zugriffstoken, Deploy-Keys und in CI/CD hinterlegte Secrets rotieren; ohne Verdacht den Wechsel nach Risiko planen.
5. Interne und nicht exponierte Instanzen nachziehen und das Ergebnis dokumentieren.

Der Grund für diese Reihenfolge liegt im Ablauf: Erst das Update stoppt neue Versuche, danach lässt sich in den Logs aufräumen, ohne dass während der Analyse weitere Spuren entstehen, und erst mit klarem Befund lohnt sich der Aufwand, Zugangsdaten zu erneuern.