Die Angriffskette basiert auf zwei Speicherfehlern in Oj, einem Ruby-JSON-Parser, der laut Quelltext zu großen Teilen in nativem C implementiert ist. depthfirst zufolge erkannte das eigene System die Fehler autonom, die Forscher kombinierten sie anschließend manuell zu einem Exploit. Ruby selbst ist laut Bericht nicht betroffen.
Ausgenutzt wird GitLabs Notebook-Renderer. Das In-Tree-Gem ipynbdiff übergibt demnach vom Repository kontrolliertes .ipynb-JSON an „Oj::Parser.usual.parse“ innerhalb eines langlebigen Puma-Workers. Dadurch gelangen vom Angreifer kontrollierte Daten in den manuell verwalteten C-Speicher von Oj im Anwendungskontext.
Für den Angriff legt der Angreifer zunächst ein präpariertes Jupyter-Notebook in einem Commit ab und öffnet anschließend dessen Commit-Diff. Dieser Vorgang gibt einen Heap-Zeiger preis. Mit ausreichend vielen solcher Lecks kann ein automatisierter Test die Bibliotheken im Speicher lokalisieren. Zwei weitere Notebooks lösen dann die eigentliche Nutzlast aus.
Laut depthfirst schreibt einer der Fehler über einen festen 1.024-Byte-Stack für Verschachtelungen hinaus, bis die Start-Callback-Funktion des Parsers kontrolliert werden kann. Der zweite Fehler kürzt einen 65.565 Byte langen Objektschlüssel in einem vorzeichenbehafteten 16-Bit-Feld auf 29 und gibt einen noch gültigen Heap-Zeiger zurück, den GitLab in den Diff rendert. Das Leck lokalisiert libc, und die Schreibprimitive biegt den Callback auf „system()“ um.
Betroffen sind laut Bericht alle GitLab-Ausgaben von CE und EE sowie alle Stufen von Free bis Ultimate. Die öffentliche Exploit-Implementierung ist jedoch auf GitLab 18.11.3 unter x86-64 zugeschnitten. Offsets der Gadgets, Registerzustand und das Verhalten von jemalloc stammen aus diesem Image; zudem bleibt eine ermittelte Bibliotheksbasis nur bis zum Neustart des Puma-Masters gültig. Gegen beliebige Ziele lasse sich der Exploit daher nicht einfach unverändert einsetzen. depthfirst beziffert die Speichersuche auf einer frischen Installation mit zwei Workern auf fünf bis zehn Minuten und erwartet bei länger laufenden Instanzen ein bis zwei Stunden. Die zugrunde liegenden Oj-Fehler seien allgemeiner Natur, die Portierung des Exploits bedeute aber reale Zusatzarbeit.
GitLab empfiehlt ein Upgrade auf 18.10.8, 18.11.5 oder 19.0.2. Einen Workaround nennen weder GitLab noch depthfirst. Wichtig sei bei Helm- und Operator-Installationen, die GitLab-Version im Webservice-Image mit Puma zu prüfen, nicht die Version des Charts oder Operators. Installationen von 15.2 bis 18.9 erhalten keinen Backport, weil diese Linien laut Bericht außerhalb von GitLabs sicherheitsgepflegten Patch-Zügen liegen; sie müssen stattdessen auf eine unterstützte Version wechseln.
Ausgeführt werden Befehle als Konto „git“, also als Benutzer hinter Puma. Welche Reichweite das in einer konkreten Installation hat, hängt laut Quelltext von deren Isolation ab. Genannt werden Quellcode, Rails-Secrets, Service-Zugangsdaten, CI/CD-Daten und interne Dienste, mit denen die Anwendung kommunizieren kann.
Zum zeitlichen Ablauf schreibt der Bericht: depthfirst meldete die Oj-Fehler am 21. Mai, der Maintainer übernahm die Korrekturen am 27. Mai, und Oj 3.17.3 erschien am 4. Juni. Die GitLab-Angriffskette ging am 5. Juni an GitLab, wurde am 8. Juni bestätigt und am 10. Juni gepatcht. depthfirst erklärt, keine Ausnutzung in freier Wildbahn zu kennen; zudem habe GitLab die RCE unabhängig reproduziert. Aus der breiteren Oj-Prüfung seien neun weitere CVE-Hinweise hervorgegangen, jedoch keiner für diese Kette.