Zum Inhalt springen
EilmeldungDev-Tools

GitLab 19.5.1 behebt eine Codeausführungslücke mit CVSS 10.0

GitLab hat am 21. Oktober 2026 Korrekturen für CVE-2026-110264 veröffentlicht, eine Lücke mit CVSS 10.0, über die Angreifer ohne Anmeldung Code auf selbst betriebenen Servern ausführen können.

Von Tech AI Wire Team

3 Min. Lesezeit

XLinkedIn
GitLab Docs page titled GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13, with a list of CVEs in the sidebar.

Die Zahlen

CVSS score of CVE-2026-110264
10.0
vulnerabilities fixed in the release
12
GitLab version lines patched
7
exposed GitLab CE instances tracked by Shadowserver
2,700+

GitLab hat am 21. Oktober 2026 Patches für CVE-2026-110264 veröffentlicht, eine Lücke mit dem Wert 10.0, dem Höchstwert auf der CVSS-Skala. Ein Fehler im Regex-Compiler von GitLab konnte es einem Angreifer ohne Konto erlauben, Code auf einem GitLab-Server auszuführen. GitLab.com ist bereits gepatcht, aber jede selbst betriebene Installation braucht ein Update.

Worum es bei der Lücke geht

Ein regulärer Ausdruck, kurz Regex, ist ein Muster zum Suchen und Abgleichen von Text. GitLab übersetzt diese Muster in Anweisungen, bevor es sie ausführt. Hier kommt es im Compiler zu einem Integer-Überlauf: Eine Zahl wächst über das hinaus, was ihr Speicherplatz fassen kann, und springt um, was den Speicher beschädigen kann.

Laut dem Patch-Release von GitLab löst ein speziell gestalteter Regex den Überlauf aus. Das „hätte es einem nicht authentifizierten Nutzer ermöglichen können, beliebigen Code auf dem GitLab-Server auszuführen“. Die Lücke betrifft sowohl die Community Edition als auch die Enterprise Edition und reicht bis GitLab 7.0 zurück.

Der Angriff funktioniert über das Netzwerk und braucht weder Berechtigungen noch eine Aktion von Nutzern, berichtet GBHackers. Eine Person mit dem Namen joaxcar meldete die Lücke über das HackerOne-Bug-Bounty-Programm von GitLab. Keine Quelle berichtet von Angriffen in freier Wildbahn oder einem öffentlichen Exploit. GIGAZINE merkt an, dass der Fehler nicht auf der CISA-Liste bekannter ausgenutzter Schwachstellen steht.

Welche Versionen die Lücke schließen

GitLab hat sieben Release-Linien auf einmal gepatcht:

Release-LinieKorrigierte Version
19.519.5.1
19.419.4.3
19.319.3.6
19.219.2.9
19.119.1.9
19.019.0.10
18.1118.11.13

Die vier ältesten Linien erhielten die Korrektur für CVE-2026-110264 als Backport. Kunden von GitLab Dedicated mit 19.3.5-internal0, 19.4.2-internal0 oder neuer haben die Korrekturen bereits.

Die anderen 11 Korrekturen

Das Release behebt insgesamt 12 Schwachstellen: eine kritische, zwei hohe, fünf mittlere und vier niedrige. Alle 12 sind in 19.3.6, 19.4.3 und 19.5.1 behoben.

Die beiden Fehler mit hohem Schweregrad betreffen Teams mit Single Sign-on. CVE-2026-15723 mit 8,2 ist ein Authentifizierungsfehler beim automatischen Verknüpfen von OmniAuth mit LDAP, aber nur, wenn SAML und das automatische LDAP-Verknüpfen beide eingeschaltet sind. CVE-2026-112212 mit 7,5 erlaubt Cache Poisoning an den Discovery-Endpunkten von OAuth und OpenID Connect.

Ein voller Monat für die GitLab-Sicherheit

Es ist nicht GitLabs erster kritischer Patch im Oktober. Zehn Tage zuvor warnte GitLab vor CVE-2026-97229, einer weiteren 10.0-Lücke im Regex-Compiler von CI/CD, berichtet BleepingComputer. Laut GIGAZINE behob der Patch vom 12. Oktober 24 Probleme, doch Server mit nur diesem Patch sind weiterhin für den neuen Fehler anfällig.

BleepingComputer zitiert außerdem Shadowserver, das mehr als 2.700 aus dem Internet erreichbare GitLab-CE-Instanzen zählt. Das misst die Angriffsfläche, nicht bestätigte Angriffe.

GitLabs Empfehlung ist deutlich: „Wir empfehlen dringend, alle selbst verwalteten GitLab-Installationen sofort auf eine dieser Versionen zu aktualisieren.“

Was das für Entwickler bedeutet

Ein selbst betriebener GitLab-Server enthält den Quellcode und die CI-Geheimnisse eines Unternehmens, deshalb ist ein Codeausführungsfehler ohne Anmeldung so ernst, wie es nur geht.

  • Heute aktualisieren und die Ausfallzeit planen. 19.3.6 und 19.4.3 enthalten Datenbankmigrationen. Installationen mit einem Knoten brauchen währenddessen eine Ausfallzeit, Setups mit mehreren Knoten können GitLabs Verfahren ohne Ausfallzeit nutzen.
  • Die ältesten Zweige verlassen. GitLab nennt alle 12 Korrekturen nur für 19.3.6 und neuer. Die älteren Linien, 18.11.13 bis 19.2.9, werden für die kritische Korrektur genannt.
  • Nach Angriffsspuren suchen. GitLab hat zwei Erkennungsregeln für selbst verwaltete Instanzen veröffentlicht, onigmo_native_worker_crash und org_mode_render_error_burst. Durchsuchen Sie Ihre Logs danach.
  • Die Angriffsfläche verkleinern. Wenn Ihr GitLab nicht im öffentlichen Internet stehen muss, setzen Sie es hinter ein VPN oder ein Single-Sign-on-Gateway.
  • Im Zweifel Geheimnisse austauschen. Ein kompromittierter GitLab-Server legt CI/CD-Variablen und Deploy-Schlüssel offen. Wenn Sie Spuren eines Einbruchs finden, tauschen Sie sie alle aus.

Quellen

  1. GitLab Critical Patch Release: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 - GitLab
  2. GitLab warns of new max severity code execution vulnerability - BleepingComputer
  3. GitLab Patches Critical 10.0 RCE Vulnerability Allowing Unauthenticated Remote Code Execution - GBHackers
  4. 12-Year-Old GitLab Vulnerability Allows Remote Code Execution on Self-Managed Server - Cyber Security News

Ähnliche Artikel