Zum Inhalt springen
Tech & Tacheles„Klartext zu KI, Security und Crypto"
← Alle Beiträge
Cybersecurity July 26, 2026

GitLab-Sicherheitslücke: RCE-Exploit trifft ungepatchte Self-Managed-Server

Ein öffentlicher Proof-of-Concept führt auf ungepatchten Self-Managed-GitLab-Servern Code als git aus – über präparierte Jupyter-Notebooks. Was betroffen ist und was jetzt zu tun ist.

GitLab-Sicherheitslücke: RCE-Exploit trifft ungepatchte Self-Managed-Server

Eine GitLab-Sicherheitslücke zeigt gerade, wie tückisch still gepatchte Fehler sind: Sicherheitsforscher Yuhang Wu von depthfirst hat am 24. Juli 2026 einen funktionierenden Proof-of-Concept veröffentlicht, der auf einem ungepatchten selbst gehosteten GitLab-Server Befehle als Systembenutzer git ausführt. Das Brisante daran: GitLab hatte den zugrunde liegenden Fehler bereits bis zum 10. Juni behoben – aber nicht als Sicherheitslücke ausgewiesen, sondern versteckt unter den Bugfixes.

Was die GitLab-Sicherheitslücke so gefährlich macht

Der Exploit braucht keine Administratorrechte, keinen CI-Runner-Zugriff und kein Zutun eines Opfers. Es genügt ein ganz normaler angemeldeter Nutzer, der in ein Projekt schreiben darf. Er committet zwei präparierte Jupyter-Notebooks (.ipynb) und ruft deren Diff-Ansicht auf – das reicht, um die Codeausführung anzustoßen.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Ursache sind zwei Speicherfehler im Ruby-JSON-Parser Oj, den GitLab beim Rendern von Notebook-Diffs einsetzt. Der Renderer schleust vom Repository kontrollierte Daten direkt in Ojs nativen Parser innerhalb des langlebigen Puma-Worker-Prozesses. Über eine tief verschachtelte JSON-Struktur überschreibt der Angreifer interne Zeiger und lenkt so den Programmablauf bis zum Systemaufruf um.

Welche Versionen betroffen sind

Verwundbar sind laut depthfirst GitLab Community Edition und Enterprise Edition (Free, Premium und Ultimate) in diesen Bereichen:

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

Die ersten korrigierten Versionen sind 18.10.8, 18.11.5 und 19.0.2. Auf Ebene der Oj-Bibliothek sind die veröffentlichten Gems 3.13.0 bis 3.17.1 anfällig; erst 3.17.3 enthält beide Korrekturen. Ruby selbst ist nicht betroffen. Der öffentliche Exploit ist auf GitLab 18.11.3 unter x86-64 zugeschnitten, die dahinterliegenden Oj-Fehler reichen aber weiter.

Silent Patch: Warum das ein Problem ist

GitLab.com war bereits bis zum 10. Juni geschützt. Für Betreiber eigener Instanzen gilt das nicht automatisch. Weder die Veröffentlichung von depthfirst noch GitLabs Release Notes vom 10. Juni nennen eine CVE-Nummer oder einen CVSS-Wert für die beiden ausgenutzten Kettenfehler. Wichtig zur Einordnung: „ohne CVE“ betrifft nur genau diese RCE-Kette – für andere Oj-Fehler aus demselben Sicherheits-Review wurden sehr wohl neun CVEs vergeben. Eine Prüfung durch The Hacker News ergab, dass GitLab den Sprung auf Oj 3.17.3 unter „Bug fixes“ auflistete – nicht in der Tabelle der Sicherheitskorrekturen – und die Notebook-Diff-RCE-Kette nicht beschrieb.

Für Administratoren heißt das: Wer nur die Sicherheits-Advisories im Blick behält, hat diesen Fix womöglich übersehen. Genau darin liegt die Gefahr eines „Silent Patch“ – die Lücke ist real, die Warnung fehlt. Bei erfolgreicher Ausnutzung läuft der Code mit den Rechten von git. Je nach Isolierung der Installation kann das Quellcode, Rails-Secrets, Dienst-Zugangsdaten, CI/CD-Daten und interne Systeme umfassen.

Was Betreiber jetzt tun sollten

  • Selbst gehostete Instanzen sofort aktualisieren auf eine unterstützte Version mit dem Fix (mindestens 18.10.8, 18.11.5 oder 19.0.2).
  • Bei Helm- und Operator-Deployments die GitLab-Version im Webservice-Image prüfen, nicht nur die Chart- oder Operator-Version.
  • Einen Workaround gibt es nicht – depthfirst und GitLab verweisen beide ausschließlich auf das Upgrade.

depthfirst gab an, bis zum 24. Juli keine Ausnutzung in freier Wildbahn zu kennen. Mit einem öffentlichen PoC steigt der Druck jedoch schnell. Wer eine eigene GitLab-Instanz im Heimnetz oder auf einem NAS oder Heimserver betreibt, sollte den Patch-Stand jetzt kontrollieren. Grundsätzlich zeigt der Fall erneut, warum zeitnahes Patchen bei selbst gehosteter Software Pflicht ist – wie zuletzt bei der wp2shell-Lücke im WordPress-Core.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden