Security Meldungen · 22.10.2026

Security Alert: Kritische GitLab-Lücke CVE-2026-110264 (CVSS 10.0) – Self-Managed-Instanzen jetzt aktualisieren

enthus blog securitywarning marker deep blue d1

GitLab hat am 21. Oktober 2026 einen Critical Patch Release für Community Edition (CE) und Enterprise Edition (EE) veröffentlicht. Er schließt zwölf Sicherheitslücken, darunter eine kritische Schwachstelle, über die unauthentifizierte Angreifer unter bestimmten Bedingungen beliebigen Code auf dem GitLab-Server ausführen können. Betroffen sind selbst betriebene Installationen. Sie sollten sofort aktualisiert werden.

Das Wichtigste in Kürze

  • Kritische Lücke: CVE-2026-110264, CVSS 10.0, Codeausführung ohne Anmeldung möglich
  • Betroffen: GitLab CE/EE ab Version 7.0 bis zu den gepatchten Releases
  • Gepatchte Versionen: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13
  • Alle zwölf Lücken geschlossen: erst ab 19.3.6, 19.4.3 oder 19.5.1
  • GitLab.com ist bereits gepatcht. GitLab Dedicated ab 19.3.5-internal0 bzw. 19.4.2-internal0 ebenfalls
  • Kein Workaround: Das Update ist die einzige Abhilfe
  • Handlungsbedarf: Self-Managed-Instanzen sofort aktualisieren, Upgrade-Pfad beachten

Was ist passiert?

Kern des Updates ist CVE-2026-110264. Die Schwachstelle entsteht durch einen Integer Overflow, wenn GitLab einen speziell präparierten regulären Ausdruck kompiliert. Unter bestimmten Bedingungen kann ein Angreifer darüber ohne Anmeldung beliebigen Code auf dem GitLab-Server ausführen. Die Bewertung liegt bei CVSS 10.0, dem Höchstwert: Der Angriff erfolgt über das Netzwerk, ist wenig komplex und erfordert weder Berechtigungen noch eine Aktion des Nutzers.

Die Lücke reicht weit zurück. Betroffen sind alle Versionen ab GitLab 7.0. Deshalb hat GitLab die Korrektur zusätzlich in ältere Release-Linien zurückportiert: 18.11.13, 19.0.10, 19.1.9 und 19.2.9. Einen Workaround hat GitLab nicht veröffentlicht. Wer nicht sofort patchen kann, hat also keine Alternative zum Update.

Zwei weitere Lücken mit hoher Kritikalität

CVE-2026-15723 (CVSS 8.2): Sind OmniAuth SAML und LDAP Auto-Linking gleichzeitig aktiviert, kann ein angemeldeter Nutzer ein bestehendes LDAP-Konto übernehmen, ohne dass das Opfer etwas tun muss. Betroffen sind Versionen ab 10.1.

CVE-2026-112212 (CVSS 7.5): Unter bestimmten Bedingungen kann ein nicht angemeldeter Angreifer das zwischengespeicherte OAuth/OIDC-Discovery-Dokument manipulieren (Cache Poisoning) und bestimmte Anmeldeabläufe auf einen externen Server umleiten. Damit der Angriff greift, muss ein Nutzer einen solchen Login-Flow durchlaufen. Betroffen sind Versionen ab 18.3.

Alle behobenen Schwachstellen im Überblick

CVESchwachstelleSchwereCVSSEditionBetroffen
CVE-2026-110264Integer Overflow im Regex-CompilerKritisch10.0CE/EEab 7.0
CVE-2026-15723Fehlerhafte Authentifizierung beim OmniAuth-LDAP-Auto-LinkingHoch8.2CE/EEab 10.1
CVE-2026-112212Cache Poisoning der OAuth/OIDC-Discovery-EndpunkteHoch7.5CE/EEab 18.3
CVE-2026-12664Zugriffskontrolle im GraphQL-Feld E-Mail-Adresse (Work Items)Mittel6.8CE/EEab 18.2
CVE-2026-16255Unvollständige Durchsetzung der SAML/LDAP-Membership-SperreMittel5.9EEab 12.0
CVE-2026-105777Offenlegung interner Zugangsdaten über interne Response-HeaderMittel4.3CE/EEab 17.6.5
CVE-2026-13319Autorisierungs-Bypass in der API für Gruppen-MeilensteineMittel4.3CE/EEab 15.10
CVE-2026-112378Kostenpflichtige AI-Features ohne gültige Lizenz nutzbarMittel4.3EEab 17.8
CVE-2026-105711Offenlegung vertraulicher Issue-Titel über gemeinsamen Fragment-Cache bei MR-DarstellungNiedrig3.5CE/EEab 15.0
CVE-2026-14288Zugriffskontrolle bei Merge-Request-Approval-PoliciesNiedrig3.1EEab 17.4
CVE-2026-112326Nutzer mit Lesezugriff können Vulnerability-Records dauerhaft löschenNiedrig3.1EEab 17.8
CVE-2026-103515Zugriffskontrolle beim Duo-Admin-Lock für Amazon-Q-EinstellungenNiedrig2.7EEab 19.2

„Betroffen“ bezeichnet die erste anfällige Version. Behoben ist jeweils in den gepatchten Releases.

Welche Version ist die richtige?

Die kritische Lücke CVE-2026-110264 ist in allen sieben gepatchten Versionen geschlossen. Die übrigen elf Schwachstellen betreffen, je nach Lücke, Versionen ab der in der Tabelle genannten Version bis vor 19.3.6, 19.4.3 bzw. 19.5.1. Wer auf einer der zurückportierten Linien bleibt (18.11.13, 19.0.10, 19.1.9 oder 19.2.9), ist gegen die kritische Lücke geschützt, nicht aber gegen alle anderen. Vollständig abgesichert sind Instanzen auf 19.3.6, 19.4.3 oder 19.5.1.

Ihre Release-LinieZielversionErgebnis
19.519.5.1alle zwölf Lücken geschlossen
19.419.4.3alle zwölf Lücken geschlossen
19.319.3.6alle zwölf Lücken geschlossen
19.2 / 19.1 / 19.0 / 18.1119.2.9 / 19.1.9 / 19.0.10 / 18.11.13kritische Lücke geschlossen; für alle Fixes anschließend geplant auf 19.3.6 oder neuer
älter als 18.11kein Patch für diese LinieUpgrade entlang des GitLab-Upgrade-Pfads auf eine gepatchte Version

Upgrade-Pfad beachten

GitLab schreibt bei größeren Versionssprüngen Pflicht-Zwischenstopps (Required Upgrade Stops) vor. Das sind Versionen, die vor jedem späteren Upgrade installiert sein müssen. In der 18er-Linie sind das 18.2, 18.5, 18.8 und 18.11, in der 19er-Linie 19.2, 19.5, 19.8 und 19.11 (19.8 und 19.11 geplant). An jedem Zwischenstopp empfiehlt GitLab den jeweils neuesten Patch-Release. Von 18.11 führt der Weg zu 19.3.6 also über 19.2.9. Zero-Downtime-Upgrades sind zudem nur Minor-Version für Minor-Version möglich.

Für 18.11-Instanzen ist der schnelle Weg daher: jetzt 18.11.13 einspielen und damit die kritische Lücke schließen, danach 19.3.6 geplant nachziehen. Den passenden Pfad für die eigene Ausgangsversion zeigt das GitLab Upgrade Path Tool.

Wer muss handeln?

  • Self-Managed (CE und EE): sofort aktualisieren.
  • GitLab.com: kein Handlungsbedarf, die Plattform läuft bereits auf der gepatchten Version.
  • GitLab Dedicated: Tenants auf 19.3.5-internal0 und 19.4.2-internal0 oder neuer enthalten die Korrekturen bereits.

Handlungsempfehlungen

  1. Version prüfen: Welche GitLab-Version läuft auf Ihren Instanzen, und handelt es sich um CE oder EE?
  2. Update einplanen: Der Patch enthält Datenbankmigrationen. Bei Single-Node-Installationen führt das Update zu einer Downtime, weil die Migrationen abgeschlossen sein müssen, bevor GitLab startet. Multi-Node-Umgebungen lassen sich mit den Zero-Downtime-Verfahren ohne Ausfall aktualisieren.
  3. Zielversion wählen: Ziel sind 19.3.6, 19.4.3 oder 19.5.1, damit alle zwölf Lücken geschlossen sind. Den Weg dorthin über die Pflicht-Zwischenstopps zeigt das GitLab Upgrade Path Tool.
  4. Konfiguration prüfen: Sind OmniAuth SAML und LDAP Auto-Linking gemeinsam aktiv, betrifft Sie CVE-2026-15723 direkt. Das Update hat hier besondere Priorität.
  5. Erkennung nutzen: GitLab Security hat für Self-Managed-Instanzen zwei Threat Detections zu CVE-2026-110264 bereitgestellt: „Onigmo native worker crash“ und „Org mode render error burst“. Sie stehen im Repository https://gitlab.com/gitlab-security-oss/tldr.
  6. Runner nicht vergessen: Updates für GitLab Runner sind separat dokumentiert.

Häufige Fragen

Wird die Lücke bereits aktiv ausgenutzt?

Dazu enthält die Veröffentlichung von GitLab keine Angaben. Wegen der Höchstbewertung CVSS 10.0 und der Ausnutzbarkeit ohne Anmeldung sollte das Update dennoch sofort erfolgen.

Reicht ein Update auf 19.2.9 oder 18.11.13?

Gegen die kritische Lücke CVE-2026-110264: ja. Die übrigen elf Schwachstellen sind erst ab 19.3.6, 19.4.3 bzw. 19.5.1 behoben.

Wann werden technische Details veröffentlicht?

Die Details zu den Sicherheitsproblemen werden 90 Tage nach dem Release im GitLab Issue Tracker öffentlich. Bis dahin sollte das Update abgeschlossen sein.

Fazit

Eine Lücke mit CVSS 10.0, ausnutzbar ohne Anmeldung und mit Wurzeln bis GitLab 7.0: Für Betreiber eigener GitLab-Instanzen hat dieses Update oberste Priorität. Wer zuerst die kritische Lücke schließt und anschließend entlang des Upgrade-Pfads auf 19.3.6, 19.4.3 oder 19.5.1 geht, schließt alle zwölf Lücken und bringt seine Entwicklungsplattform auf den aktuellen Sicherheitsstand.

Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.

← Alle Beiträge