Hauptanalyse
Sicherheit & Risiko5 Min.

Öffentliche PoC enthüllt stilles RCE im GitLab: Schwachstelle ohne CVE lässt Unternehmensserver ungeschützt

Terminal de desenvolvedor com código em execução e notebook Jupyter aberto, ilustrando a cadeia de exploração da vulnerabilidade RCE no GitLab

Forscher von depthfirst veröffentlichten am 25. Juli funktionalen Exploit-Code für RCE im GitLab, sechs Wochen zuvor ohne CVE und ohne Sicherheitsankündigung behoben. Jeder Benutzer mit Push-Zugriff kann den Server gefährden.

Der Exploit und was er tut


Forscher von depthfirst veröffentlichten am 25. Juli 2026 funktionalen Exploit-Code für eine Remote Code Execution-Vulnerability im GitLab. Der Exploit führt Befehle als Benutzer git auf jedem selbstverwalteten Server in Version 18.11.3 aus, der das Patch vom 10. Juni nicht angewendet hat. Er erfordert keine Administratorrechte, keinen Zugriff auf CI/CD-Pipelines, keine Runner-Berechtigungen und keine Interaktion eines Administrators: Jeder authentifizierte Benutzer mit Push-Rechten für ein einzelnes Projekt, das Zugriffslevel, das standardmäßig jeder Entwickler in einem öffentlichen Repository hat, hat genug, um die gesamte Kette auszulösen.


Der Angreifer committet ein speziell erstellt Jupyter-Notebook und öffnet den Diff der Überprüfung im GitLab, eine Operation, die einen Heap-Pointer des Servers ausliest. Kontrollierte Wiederholungen ermöglichen es einem automatisierten Scanner, die in den Speicher geladenen Bibliotheken abzubilden. Zwei zusätzliche Notebooks lösen die Payload aus. Diese Technik hängt nicht von Schwachstellen im Kernel oder im Host-Betriebssystem ab, sondern lediglich vom vorhersehbaren Verhalten der Bibliothek Oj beim Verarbeiten des Diff von spezifischen, geschachtelten JSON-Inhalten. Die Abwesenheit von Interaktion seitens des Opfers, ohne auf Links zu klicken, Merge-Requests zu genehmigen oder Dateien zu öffnen, ist das Attribut, das das Risiko in Unternehmensumgebungen mit zahlreichen externen Mitarbeitern erhöht.


Warum es kein CVE gibt und was das bedeutet


GitLab hat die Bibliothek Oj im Release vom 10. Juni auf Version 3.17.3 korrigiert, hat die Änderung jedoch als allgemeine Fehlerbehebung und nicht als Sicherheitsaktualisierung registriert. Es wurde kein CVE ausgegeben. Das Update erschien nicht in der Tabelle der Sicherheitsfixes der Versionen 18.11.4 und 18.11.5. Das praktische Ergebnis: Patch-Management-Teams, die ausschließlich auf Warnungen mit CVSS-Score angewiesen sind, hatten 45 Tage Zeit, um einen Fix zu implementieren, der keine Dringlichkeit signalisierte, während depthfirst den funktionalen Proof of Concept vorbereitete.


Das Unternehmen entschied sich, den Exploit ohne vorherige Koordination mit dem Anbieter zu veröffentlichen. Die Begründung ist eindeutig: Der Patch war seit sechs Wochen verfügbar, und das angemessene Zeitfenster zur Behebung war abgelaufen, ohne dass GitLab das Risiko öffentlich klassifiziert hatte. Bis zum Zeitpunkt des Schreibens dieses Artikels hatte GitLab auch keine spezifische Sicherheitsankündigung zum Exploit von depthfirst herausgegeben, was auch bedeutet, dass auf CVE basierende Schwachstellenscanner den nicht aktuallisierten Server nicht als anfällig identifizieren.


Dimension des globalen Risikos


Laut einer Umfrage von Cycode mit Daten von Shodan sind über 40.000 selbstverwaltete GitLab-Server direkt im Internet zugänglich. Diese Zahl repräsentiert nur die öffentlich exponierten Instanzen; das Universum an Servern, die durch VPNs, interne Netzwerke und Reverse Proxys geschützt sind, ist erheblich größer. Das Modell der Selbstverwaltung ist in regulierten Sektoren wie Finanzen, Gesundheit und Verteidigung vorherrschend, wo interne Richtlinien die Nutzung von SaaS-Instanzen verbieten. Diese Umgebungen neigen dazu, Patch-Zyklen in Wochen zu messen, die an monatliche Wartungsfenster gebunden sind, nicht in Stunden.


Das Risiko beschränkt sich nicht nur auf amerikanische Organisationen. IT-Beratungsunternehmen in Indien, Deutschland und Brasilien hosten häufig selbstverwaltete Instanzen für Kundenprojekte, oft in gemeinsam genutzten Entwicklungsumgebungen. Ein kompromittierter Server in diesem Modell kann gleichzeitig Quellcode, Umgebungsvariablen und CI/CD-Tokens für mehrere Projekte und Kunden exponieren. Die niedrige Zugangsschwelle, das Push-Recht für jedes Repository der Instanz, vergrößert die Angriffsfläche in Organisationen mit Hunderten von externen Mitarbeitern erheblich.


Was jetzt zu tun ist


Der Fix existiert und ist eindeutig: Aktualisieren auf 18.10.8, 18.11.5 oder 19.0.2. Alle drei Versionen beinhalten das Fix der Bibliothek Oj 3.17.3. Umgebungen, die durch Reverse Proxys, VPN oder Web Application Firewalls geschützt sind, bleiben anfällig, wenn ein Angreifer über gültige Anmeldeinformationen eines beliebigen Benutzers mit Push-Rechten verfügt, sei es durch Phishing oder durch Credential Stuffing über Repositories mit externen Beiträgen.


Die Abwesenheit eines CVE darf keinesfalls als Rechtfertigung dienen, um das Patchen hinauszuzögern. Der Exploit von depthfirst ist seit dem 25. Juli öffentlich und funktioniert gegen jede nicht aktualisierte Instanz. Das Zeitfenster zwischen der Veröffentlichung eines PoC und dem Beginn aktiver Ausbeutung durch weniger anspruchsvolle Akteure wird üblicherweise in Tagen und nicht in Wochen gemessen. Teams mit monatlichen oder vierteljährlichen Wartungszyklen sollten Notfall-Patching außerhalb des regulären Kalenders in Betracht ziehen.

Hauptanalyse