Kritische GitLab-Lücke ermöglicht Schadcode-Ausführung
GitLab hat eine Sicherheitslücke mit dem maximalen CVSS-Schweregrad 10,0 geschlossen. CVE-2026-110264 ermöglicht unter bestimmten, bislang nicht näher beschriebenen Bedingungen die Ausführung beliebigen Codes aus der Ferne. Eine Anmeldung am betroffenen GitLab-Server ist dafür nicht erforderlich.
Betroffen sind selbst verwaltete Installationen der GitLab Community Edition und Enterprise Edition. Die Schwachstelle reicht bis GitLab 7.0 aus dem Juni 2014 zurück und betrifft damit Veröffentlichungen aus einem Zeitraum von zwölf Jahren.
Die Lücke konnte unter bestimmten Bedingungen einem nicht angemeldeten Angreifer ermöglichen, durch einen Integer Overflow beim Kompilieren eines manipulierten regulären Ausdrucks beliebigen Code auf dem GitLab-Server auszuführen, so GitLab sinngemäß aus dem Englischen.
Ein Integer Overflow entsteht, wenn eine Zahl den vorgesehenen Wertebereich überschreitet und dadurch fehlerhaft verarbeitet wird. In diesem Fall tritt der Fehler beim Kompilieren speziell präparierter regulärer Ausdrücke auf.
Diese GitLab-Versionen enthalten den Patch
GitLab stellt Korrekturen für mehrere Versionszweige bereit. Betreiber älterer Installationen müssen prüfen, welcher unterstützte Upgrade-Pfad für die eigene Umgebung infrage kommt.
| Versionszweig | Version mit Sicherheitsupdate |
|---|---|
| 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 |
GitLab.com und GitLab Dedicated werden vom Anbieter verwaltet und sind bereits gepatcht. Für selbst betriebene Server hat GitLab zusätzlich zwei Erkennungsregeln veröffentlicht, mit denen sich verdächtige Aktivitäten untersuchen lassen.
| Kennzahl | Einordnung |
|---|---|
| CVSS 10,0 | Maximaler Schweregrad |
| 12 Jahre | Betroffener Veröffentlichungszeitraum |
| 50 Millionen | Registrierte Nutzer laut GitLab |
| Mehr als 50 % | Anteil der Fortune-100-Unternehmen mit GitLab laut Eigenangabe |
Code-Server wird zum Risiko für die Lieferkette
Eine kompromittierte GitLab-Instanz betrifft nicht nur den gespeicherten Quellcode. In Repositories und CI/CD-Konfigurationen liegen häufig Zugangs-Token, Deployment-Secrets, Infrastrukturdefinitionen und Verbindungen zu Produktivsystemen.
Für Unternehmen mit selbst verwalteter GitLab-Infrastruktur sind die möglichen Folgen gravierend, warnt SOC Prime sinngemäß aus dem Englischen. Ein Zugriff auf Serverebene könne den Diebstahl von Zugangsdaten, manipulierte Repositories, Angriffe auf die Software-Lieferkette und weitere Bewegungen innerhalb des Unternehmensnetzes ermöglichen.
Wie schnell gestohlene Schlüssel und manipulierte Abhängigkeiten Kosten und Folgeschäden verursachen können, zeigte zuletzt der Supply-Chain-Angriff auf LiteLLM. Auch die kritischen PHP2Shell-Lücken im PHP-Kern unterstreichen, wie wichtig kurze Patch-Zeiten für zentrale Entwicklungsplattformen sind.
Was Betreiber jetzt prüfen sollten
Der erste Schritt ist die Aktualisierung auf eine der korrigierten Versionen. Anschließend sollten die von GitLab bereitgestellten Erkennungsregeln eingesetzt sowie Protokolle, administrative Änderungen, neu angelegte Token und ungewöhnliche Repository-Aktivitäten geprüft werden.
Bislang gibt es keine bestätigten Hinweise auf eine aktive Ausnutzung der Schwachstelle. Das ist jedoch kein Grund für einen Aufschub. Nach der Veröffentlichung kritischer Lücken beginnen Angreifer erfahrungsgemäß schnell mit automatisierten Scans nach erreichbaren und ungepatchten Systemen.
Entdeckt und über das Bug-Bounty-Programm auf HackerOne gemeldet wurde der Fehler vom Sicherheitsforscher Johan Carlsson. Welche technischen Voraussetzungen neben einem verwundbaren Server für einen erfolgreichen Angriff erfüllt sein müssen, hat GitLab nicht detailliert offengelegt.
Self-Hosting verlangt operative Disziplin
Für Unternehmen im DACH-Raum ist der Fall besonders relevant. GitLab CE und EE werden häufig im eigenen Rechenzentrum oder in einer kontrollierten Cloud betrieben, um Anforderungen an Datenschutz, Governance und Compliance besser abzubilden.
Diese Datensouveränität reduziert die Abhängigkeit von einem zentralen SaaS-Anbieter. Sie verlagert jedoch die Verantwortung für Updates, Überwachung und Incident Management vollständig auf das eigene Team oder den beauftragten IT-Dienstleister.
Self-Hosting ist deshalb keine wartungsfreie Alternative zum Software-Abo. Es kann Kosten und Anbieterbindung reduzieren, setzt aber klare Zuständigkeiten, ein aktuelles Anlagenverzeichnis und belastbare Patch-Prozesse voraus. Bei einer Plattform mit Zugriff auf Quellcode und Produktivsysteme gehört die Reaktionszeit unmittelbar zur Sicherheitsarchitektur.