GitLab Oj Spill RCE Exploit ist öffentlich

Die GitLab Oj Spill RCE ist jetzt öffentlich: Am 24. Juli wurden ein funktionierender Exploit-Chain und ein vollständiger technischer Bericht für eine Remote-Code-Execution-Lücke veröffentlicht, die GitLab bereits sechs Wochen zuvor, am 10. Juni, still gepatcht hatte. Läuft Ihre selbstgehostete GitLab-Instanz noch auf 18.10.7 oder älter, kann jeder Entwickler mit Commit-Rechten jetzt Befehle als Benutzer git ausführen — keine Admin-Rechte, kein Social Engineering, nur gewöhnlicher Schreibzugriff.

Was ist passiert

Die GitLab Oj Spill RCE verkettet zwei Speicherfehler, die das KI-gestützte Code-Audit-Unternehmen depthfirst in Oj entdeckt hat — dem nativen C-JSON-Parser, von dem GitLab über sein eingebundenes ipynbdiff-Gem abhängt, das Diffs von Jupyter-Notebook-Dateien rendert. Der erste Bug ist ein Out-of-Bounds-Write: Ojs Parser verfolgt die Verschachtelungstiefe in einem festen 1.024-Byte-Puffer ohne Grenzprüfung, sodass ein tief verschachteltes Notebook über den Puffer hinausschreiben und einen internen Heap-Pointer überschreiben kann. Der zweite Bug ist ein Heap-Pointer-Leak durch ein vorzeichenbehaftetes 16-Bit-Feld, das einen überlangen JSON-Schlüssel stillschweigend kürzt und dabei eine gültige Heap-Adresse über den gerenderten Notebook-Diff preisgibt.

Verkettet lokalisiert das Leak libc und libruby im Speicher und hebelt damit ASLR aus, während der Write den Parser-Callback von Oj auf system() umleitet. Ergebnis: Jeder authentifizierte GitLab-Benutzer, der eine präparierte .ipynb-Datei committen und deren Diff auf der Commit-Seite ansehen kann, löst Remote Code Execution als git innerhalb eines Puma-Workers aus. Dieser Zugriffslevel legt Quellcode, Rails-Secrets, CI/CD-Zugangsdaten, Token-Signierungsmaterial und jeden internen Dienst offen, der vom GitLab-Anwendungsserver aus erreichbar ist.

Betroffen: GitLab CE und EE Versionen 15.2.0 bis 18.10.7, 18.11.0 bis 18.11.4 sowie 19.0.0 bis 19.0.1, über alle Tiers hinweg (Free, Premium, Ultimate). Behoben in 18.10.8, 18.11.5 und 19.0.2, die alle das korrigierte Oj 3.17.3 mitbringen. GitLab.com selbst wurde bereits mit dem Release vom 10. Juni gepatcht; nur selbstgehostete Installationen bleiben exponiert. depthfirst erklärt, keine Kenntnis von aktiver Ausnutzung zum Zeitpunkt der Veröffentlichung zu haben — es handelte sich um eine koordinierte private Offenlegung —, doch das ändert sich in dem Moment, in dem Angreifer den jetzt öffentlichen Proof-of-Concept-Code nutzen.

Warum das wichtig ist

Für keinen der beiden verketteten Bugs, die in diesem Exploit genutzt werden, wurde eine CVE-Nummer beantragt — nur neun unabhängige Oj-Bugs aus derselben Untersuchung erhielten CVE-Nummern. Sicherheitsteams, die Patch-Compliance ausschließlich über CVE-Feeds verfolgen, werden diese Lücke nirgends markiert sehen — genau das Muster „Advisory ist nicht gleich gepatcht“, das DIESEC dieses Jahr bereits bei SharePoint, Veeam, PTC Windchill und Oracle PeopleSoft verfolgt hat. Selbstgehostetes GitLab ist die Standardwahl für viele DACH-Mittelstands- und regulierte Engineering-Teams, die Quellcodeverwaltung aus Datenresidenz-Gründen On-Premises betreiben — und eine RCE, die von jedem eigenen Entwickler erreichbar ist, nicht nur von einem externen Angreifer, ist ein grundlegend anderes Risikomodell als eine typische Perimeter-CVE.

Was Sie jetzt tun sollten

1. Prüfen Sie Ihre GitLab-Version gegen die oben genannten betroffenen Bereiche. Falls Sie auf 18.10.7 oder älter, 18.11.4 oder älter, oder 19.0.1 oder älter sind, aktualisieren Sie noch heute auf 18.10.8, 18.11.5 oder 19.0.2.
2. Falls Sie das Oj-Gem unabhängig von einem GitLab-Update verwalten, bestätigen Sie, dass es auf 3.17.3 oder neuer läuft — dies ist die erste Version, die beide Fixes enthält.
3. Prüfen Sie bei Helm- oder Operator-basierten GitLab-Deployments die tatsächliche GitLab-Version innerhalb des Webservice-/Puma-Images, nicht nur die Chart- oder Operator-Versionsnummer — diese können stillschweigend auseinanderdriften.
4. Solange nicht gepatcht: Erwägen Sie als Zwischenmaßnahme, einzuschränken, wer Jupyter-Notebook-Dateien in Repositories pushen darf, oder das Rendering von Notebook-Diffs zu deaktivieren.

Falls Sie nicht sofort patchen können, behandeln Sie jedes Entwickler-Commit-Konto auf der betroffenen Instanz bis zum Abschluss des Updates als potenziellen Weg zur vollständigen Kompromittierung der Anwendung — dies ist kein theoretisches Risiko, das nur externen Angreifern vorbehalten ist.

DIESEC Einschätzung

Dies ist das dritte Mal in 2026, dass DIESEC eine selbstgehostete Entwicklerplattform markiert — nach Gogs/Gitea im Mai und erneut im Juli —, bei der der Patch bereits wochenlang existierte, bevor das Risiko für Sicherheitsteams sichtbar wurde, die CVE-Feeds statt Vendor-Release-Notes verfolgen. Selbstgehostete Tools haben oft keinen klaren internen Verantwortlichen für den Patch-Rhythmus, wie es bei einem kommerziellen SaaS-Produkt der Fall wäre — genau diese Lücke lässt sechs Wochen alte Fixes wieder zu akuten Vorfällen werden, sobald ein Forscher funktionierenden Exploit-Code veröffentlicht.

Nicht sicher, ob Ihre selbstgehostete GitLab-Instanz noch für die Oj-Spill-RCE-Kette anfällig ist? Kontaktieren Sie DIESEC für eine schnelle Patch-Verifizierung und Entwickler-Zugriffsprüfung.

Quellen: depthfirst | The Hacker News
Veröffentlicht: 2026-07-28 | Kategorie: Tägliche News | ~4 Min. Lesezeit