GitLab-Exploit ohne CVE: Wie gefährlich ist die Lücke?

GitLab-Exploit ohne CVE: Warum der entscheidende Patch als Routine-Update durchging

Markus Seyfferth

Autor Dr. Web

27. Juli 2026

5 Min. Lesezeit

Ein öffentlich verfügbarer Exploit erlaubt auf ungepatchten GitLab-Servern, Befehle als Systembenutzer git auszuführen. Der zugehörige Fix liegt seit dem 10. Juni 2026 vor, allerdings ohne CVE-Nummer und ohne Sicherheitshinweis. Betreiber, deren Patch-Prozess an CVE-Meldungen hängt, haben die Lücke deshalb gut sechs Wochen lang nicht auf dem Schirm gehabt.

drweb.de als bevorzugte Quelle auf Google hinzufügenQualitätsgeprüfte Inhalte direkt in Google News & DiscoverJetzt hinzufügen

Für den GitLab-Exploit reicht ein gewöhnliches Projektkonto mit Schreibrecht: zwei präparierte Jupyter-Notebooks im Repository, dazu ein Aufruf der Commit-Ansicht. Der Sicherheitsforscher Yuhang Wu hat die Kette am 24. Juli 2026 samt lauffähigem Angriffscode offengelegt.^[1]

Das Wichtigste in Kürze

Betroffen sind selbst gehostete GitLab-Installationen der Reihen 15.2.0 bis 18.10.7, 18.11.0 bis 18.11.4 sowie 19.0.0 bis 19.0.1.
Die Kette nutzt zwei Speicherfehler im Ruby-Parser Oj, die dort 1.753 Tage überdauert haben.
Angreifer brauchen weder Administratorrechte noch Zugriff auf einen CI-Runner, ein Push-Recht auf ein Projekt genügt.
GitLab hat die Fassungen 18.10.8, 18.11.5 und 19.0.2 am 10. Juni veröffentlicht, den entscheidenden Fix darin aber als Abhängigkeits-Update geführt.

Wie wird aus einem Notebook eine Kommandozeile?

Offener Karton mit nummerierten Ordnern und einer Notiz davor, alles auf weißem Hintergrund — Oj JSON-Parser für Ruby: Zwei kritische Fehler bei Verschachtelungstiefe über 2.132 und bei Schlüsseln über 65.565 Byte

Zwei Fehler im Parser. Oj ist ein in C geschriebener JSON-Parser für Ruby. Der erste Fehler verwaltet die Verschachtelungstiefe in einem festen 1.024-Byte-Feld, ohne die Grenze zu prüfen; ab Tiefe 2.132 überschreibt der Parser einen benachbarten Zeiger. Der zweite Fehler quetscht die Länge eines Schlüssels in ein vorzeichenbehaftetes 16-Bit-Feld, wodurch ein 65.565 Byte langer Schlüssel auf 29 Byte schrumpft und dabei eine Speicheradresse preisgibt.

Der Weg ins Produkt. GitLab stellt Unterschiede zwischen Jupyter-Notebooks über die mitgelieferte Bibliothek ipynbdiff dar, und die reicht den Inhalt der .ipynb-Datei direkt an Oj weiter. Ein Aufruf der Commit-Ansicht genügt damit, um kontrollierte Bytes in den C-Parser eines Puma-Arbeitsprozesses zu schieben.

Was danach offen liegt. Am Ende der Kette laufen Befehle unter dem Systembenutzer git. Erreichbar sind damit Quellcode, Rails-Geheimnisse, Zugangsdaten, CI/CD-Daten und das Material zum Signieren von Tokens. Wie weit ein einzelnes hinterlegtes Geheimnis trägt, hat zuletzt eine Überwachungskamera von Hanwha mit einem GitHub-Token in der Firmware gezeigt.

Warum hat der Patch keine CVE-Nummer bekommen?

Fix als Zeilennotiz. Dasselbe Patch-Release vom 10. Juni führt zwölf Sicherheitslücken mit eigener CVE-Nummer auf, darunter vier mit hohem Schweregrad.^[2] Die Notebook-Kette taucht dort nicht auf, sondern nur unter den Fehlerkorrekturen als Zeile „Update dependency oj to v3.17.3“.

Blinder Fleck im Prozess. Viele Schwachstellen-Prozesse gleichen allein die Produktversion gegen CVE-Feeds ab, und genau dieser Abgleich schlägt hier nicht an. Die Bibliothek selbst hat sehr wohl Kennungen bekommen, CVE-2026-54502 und folgende: Eine Prüfung der Abhängigkeiten hätte gewarnt, ein Blick auf die GitLab-Version nicht. Wie knapp die Reaktionszeit sonst bemessen ist, hat der Fall gezeigt, in dem Angreifer vier Tage nach dem Patch an ServiceNows Sandbox vorbeikamen.

Ein Patch ohne CVE-Nummer erreicht in vielen Unternehmen niemanden, weil die halbe Sicherheitsbranche ihre Prozesse an genau dieser Nummer aufgehängt hat. GitLab hat hier zügig geliefert und trotzdem einen blinden Fleck hinterlassen.
— Michael Dobler, Herausgeber Dr. Web

1.753

Tage im Code

So lange haben beide Speicherfehler in der Bibliothek Oj gesteckt, vom 8. August 2021 bis zum 27. Mai 2026.

Tage bis zum Exploit

Zwischen dem GitLab-Patch am 10. Juni 2026 und dem veröffentlichten Angriffscode am 24. Juli 2026.

12 zu 0

CVE-Nummern im selben Release

Zwölf Sicherheitslücken haben eine Kennung bekommen, die Notebook-Kette keine einzige.

Sonderrechte nötig

Weder Administratorkonto noch CI-Runner: Ein Push-Recht auf ein Projekt genügt für den Angriff.

Vom Fund bis zum Angriffscode

21. Mai 2026

Meldung an Oj. Der Sicherheitsforscher Yuhang Wu meldet beide Speicherfehler an das Parser-Projekt.

4. Juni 2026

Oj 3.17.3 erscheint. Die korrigierte Fassung der Bibliothek steht bereit.

5. Juni 2026

Meldung an GitLab. Der Weg über die Notebook-Ansicht geht an das Sicherheitsteam.

10. Juni 2026

Patch-Release. GitLab veröffentlicht 18.10.8, 18.11.5 und 19.0.2, den Fix als Abhängigkeits-Update.

24. Juli 2026

Veröffentlichung. Analyse und lauffähiger Angriffscode werden öffentlich.

Betroffen (Community und Enterprise Edition): 15.2.0 bis 18.10.7, 18.11.0 bis 18.11.4 sowie 19.0.0 bis 19.0.1.

Sicher ab: 18.10.8, 18.11.5 oder 19.0.2. In der Gemfile.lock sollte Oj in Fassung 3.17.3 oder neuer stehen.

Prüfen Sie zusätzlich das Audit-Log seit dem 10. Juni auf Commits mit .ipynb-Dateien und deren Diff-Aufrufe.

Was deutsche Betreiber jetzt prüfen sollten

Pflicht seit Dezember. Das NIS2-Umsetzungsgesetz ist am 6. Dezember 2025 in Kraft getreten und verlangt von den betroffenen Einrichtungen Maßnahmen zum Schutz der eigenen Systeme sowie feste Meldefristen bei Vorfällen.^[3] Ein Schwachstellenmanagement, das ausschließlich CVE-Nummern auswertet, deckt diesen Anspruch nur halb ab. Welche Folgen die Vorgaben im industriellen Umfeld haben, zeigt unser Blick auf NIS2 in der Produktionshalle.

Vier Handgriffe. Für jede selbst gehostete Instanz stehen diese Schritte jetzt an:

Die Version prüfen und mindestens auf 18.10.8, 18.11.5 oder 19.0.2 heben.
In der Gemfile.lock die Oj-Fassung kontrollieren, sicher ist 3.17.3 oder neuer.
Das Audit-Log seit dem 10. Juni auf Commits mit .ipynb-Dateien und deren Diff-Aufrufe durchsehen.
Den Schwachstellen-Prozess um einen Abgleich der Abhängigkeiten erweitern, nicht nur der Produktversion.

Etikett ersetzt keine Prüfung. Eine fehlende CVE-Nummer sagt nichts über die Tragweite eines Updates aus. Bei selbst gehosteten Entwicklungsplattformen lohnt deshalb der Blick in die vollständigen Release-Notes, auch in den Abschnitt mit den Fehlerkorrekturen. Wie viel Sicherheitsarbeit ohnehin an der eigenen Instanz hängt, hat GitLab zuletzt beim Umbau auf geprüfte KI-Agenten in Version 19.2 vorgeführt. Die Grundlagen dazu bündelt unser Überblick zu Cybersecurity für den Mittelstand.