GitLab-Warnung: Öffentlicher Exploit für kritische RCE-Schwachstelle – Fix war in gewöhnlichem Bug versteckt

Einleitung

Am 24. Juli 2026 veröffentlichte das Forschungsteam depthfirst einen vollständigen Exploit für eine kritische Remote-Code-Execution-Schwachstelle (RCE), die selbst-gehostete GitLab Community Edition (CE) und Enterprise Edition (EE) betrifft. Die Sicherheitslücke ermöglicht es einem authentifizierten Benutzer mit Push-Berechtigungen, eine Shell auf dem Server mit den Rechten des git-Prozesses zu erhalten, indem er einfach ein bösartiges Jupyter-Notebook hochlädt. Besonders alarmierend ist, dass GitLab bereits am 10. Juni einen Fix bereitgestellt hatte, diesen jedoch lediglich als gewöhnlichen „Bug-Fix“ einstufte und aus der Sicherheitsaktualisierungstabelle ausließ. Infolgedessen haben viele Administratoren den Patch möglicherweise nicht angewendet, wodurch Tausende von Instanzen einem Angriff ausgesetzt sind, der nun durch die öffentliche Verfügbarkeit des Exploit-Codes erleichtert wird.

Technische Analyse

Die Schwachstelle liegt in zwei separaten Speicherfehlern im nativen JSON-Parser Oj (Optimized JSON), einem weit verbreiteten Ruby-Gem. Versionen von Oj vor 3.17.3 verarbeiten bestimmte komplexe JSON-Strukturen fehlerhaft, was zu Überläufen und Lesezugriffen außerhalb der Grenzen führt. In GitLab verwendet die Komponente ipynbdiff – die Unterschiede zwischen Versionen von Jupyter-Notebooks (.ipynb-Dateien) anzeigt – intern Oj::Parser.usual.parse, um den Dateiinhalt zu verarbeiten. Ein Angreifer mit Schreibzugriff auf ein Repository kann ein speziell präpariertes Notebook erstellen und per Push hochladen. Wenn ein beliebiger Benutzer (einschließlich des Angreifers selbst) den Notebook-Diff in der Weboberfläche betrachtet, wird der anfällige Parser ausgeführt und die im Datei enthaltene Nutzlast übernimmt die Kontrolle.

Der von depthfirst veröffentlichte Exploit arbeitet in zwei Phasen:

1. Speicherleck: Mithilfe des ersten Fehlers zwingt die Nutzlast den Parser, Speicheradressen preiszugeben, und umgeht so ASLR (Address Space Layout Randomization).
2. Beliebige Codeausführung: Durch Heap-Spraying wird Shellcode injiziert, der den Ausführungsfluss des Puma-Prozesses (dem Applikationsserver von GitLab) verändert, um vom Angreifer gewählte Befehle auszuführen.

Der Exploit ist optimiert für GitLab 18.11.3 auf x86-64-Architektur. Bei frischen Installationen dauert der Vorgang nur wenige Minuten, auf lange laufenden Servern kann er aufgrund von Heap-Fragmentierung jedoch Stunden in Anspruch nehmen. Die Anpassung an andere x86-64-Builds ist relativ einfach (es müssen nur Offsets und ROP-Gadgets aktualisiert werden), während eine Portierung auf ARM64 eine erhebliche Neufassung erfordert.

Die anfälligen GitLab-Versionen sind:

• 15.2.0 bis 18.10.7
• 18.11.0 bis 18.11.4
• 19.0.0 bis 19.0.1

Die Korrekturen wurden mit der Veröffentlichung von Oj 3.17.3 (4. Juni 2026) eingeführt und in die nachfolgenden GitLab-Versionen integriert: 18.10.8, 18.11.5 und 19.0.2. Zusätzlich wurde in GitLab ipynbdiff so modifiziert, dass robustere Parser verwendet werden, wodurch der Angriffsvektor beseitigt wurde.

Auswirkungen

Eine Shell als Benutzer git auf dem GitLab-Server zu erhalten, bedeutet eine nahezu vollständige Kompromittierung der Plattform. Der Angreifer kann:

• Den gesamten gehosteten Quellcode lesen und verändern.
• Auf Rails-Geheimnisse (Verschlüsselungsschlüssel, Sitzungstoken) und Service-Zugangsdaten (Datenbanken, externe Integrationen) zugreifen.
• CI/CD-Umgebungsvariablen, Zugriffstoken sammeln und sich potenziell lateral auf andere vom Host aus erreichbare Dienste bewegen.
• CI/CD-Pipelines verändern, um bösartige Nutzlasten zu verteilen oder Daten in großem Umfang zu exfiltrieren.

Obwohl der angegriffene Prozess auf den Benutzer git beschränkt ist, hängt das Ausmaß des Schadens von der Isolierung des Containers oder der virtuellen Maschine ab, auf dem GitLab ausgeführt wird. Instanzen, die auf nicht mehr unterstützten Versionen (15.2 bis 18.9) laufen, erhalten keine Backports: Sie bleiben ohne offizielle Korrektur anfällig, es sei denn, es erfolgt eine Migration auf eine unterstützte Version. Am 24. Juli wurden noch keine aktiven Angriffe in freier Wildbahn registriert, doch die Veröffentlichung des Exploits verändert die Bedrohungslandschaft grundlegend.

Abwehrmaßnahmen

Die höchste Priorität hat die sofortige Installation des Updates auf eine der Versionen, die die Korrektur enthalten:

• GitLab 18.10.8
• GitLab 18.11.5
• GitLab 19.0.2 (oder höher)

Administratoren, die sich ausschließlich auf die zusammenfassende Tabelle der „Security Fixes“ in den Release-Notizen verlassen, haben den Patch vom 10. Juni möglicherweise nicht installiert, da GitLab ihn als „Bug Fix“ klassifizierte. Es wird daher empfohlen, die verwendete Version manuell zu überprüfen, insbesondere in Umgebungen mit selektiven Update-Richtlinien.

Bei Helm- oder Operator-Installationen auf Kubernetes ist es entscheidend, die Image-Version des Webservice-Dienstes (der Puma ausführt) zu prüfen und nicht die des Charts oder Operators, da letztere eine veraltete Komponente verschleiern könnte.

Es gibt keine offizielle oder validierte Problemumgehung für diejenigen, die nicht sofort aktualisieren können. Die Beschränkung des Zugriffs auf Repositories und das Rendern von Notebook-Diffs auf streng vertrauenswürdige Benutzer verringert die Angriffsfläche, GitLab bietet jedoch keine dokumentierte Option, um den verwundbaren Pfad vollständig zu deaktivieren. Für spezifische Hinweise wird empfohlen, den GitLab-Support zu kontaktieren.

FAQ

1. Welche GitLab-Versionen sind genau betroffen?
Anfällig sind alle selbstverwalteten Versionen von 15.2.0 bis 18.10.7, von 18.11.0 bis 18.11.4 und von 19.0.0 bis 19.0.1. Versionen vor 15.2.0 verwenden andere Parser und sind nicht exponiert. Die Versionen 18.10.8, 18.11.5, 19.0.2 und höher enthalten die Korrektur.

2. Wie kann ich überprüfen, ob meine Instanz bereits kompromittiert wurde?
Derzeit wurden noch keine öffentlichen Kompromittierungsindikatoren (IoCs) veröffentlicht. Aufgrund der Art des Angriffs (beliebige Befehlsausführung als git) wird jedoch empfohlen, die Systemprotokolle auf ungewöhnliche Prozesse, anomale ausgehende Netzwerkverbindungen oder unerwartete Änderungen an GitLab-Konfigurationsdateien zu überwachen. Das Fehlen von Anzeichen garantiert nicht, dass das System sauber ist: Die zeitnahe Aktualisierung bleibt die wesentliche Gegenmaßnahme.

3. Warum hat GitLab keine Sicherheitswarnung mit einer CVE veröffentlicht?
Zum Zeitpunkt der Exploit-Veröffentlichung hatte GitLab sich noch nicht zur Entscheidung geäußert, den Fix als „gewöhnlichen Bug“ einzustufen. Normalerweise erhalten Schwachstellen dieser Schwere eine CVE-Kennung und werden im Sicherheitsabschnitt der Release-Notizen aufgeführt. Der Mangel an Transparenz hat die Expositionsdauer für viele Administratoren wahrscheinlich verlängert. Weitere offizielle Stellungnahmen werden erwartet.