Voraussetzungen

• Docker + docker compose, python3, git, curl auf dem Host.
• ~8 GB freier Arbeitsspeicher (zwei GitLab-Instanzen, ~4 GB jeweils) und ~10 GB Speicherplatz. Erster Start: 4–8 Min./Instanz.
• Nur gegen diese lokalen Laborinstanzen ausführen. Autorisiertes/defensives Testen von Software, die Sie kontrollieren.

Ausführen

Erwartetes Ergebnis:

Weitere Unterbefehle:

Wie das Orakel funktioniert (kein HTTP-200-Schummeln)

Sowohl der verwundbare als auch der gepatchte Server antworten auf die bösartige Veröffentlichung mit HTTP 200 {"status":"processing"} – die Datei wird später im Finalize-Worker geschrieben. HTTP-Status ist also kein Orakel. exploit/poc.py --verify-docker <container> fragt stattdessen innerhalb des Containers nach der kontrollierten Datei am traversierten Pfad und vergleicht deren SHA-1:

• verwundbar → /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz erscheint (Besitzer git:git, unsere Bytes) → Exit 0.
• gepatcht → Datei erscheint nie; der Worker protokolliert Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → Exit 2.

Der Exploit selbst ist nichts anderes als die authentifizierte PUT …/packages/npm/:pkg-Anforderung; die Traversal befindet sich vollständig im JSON-Body name (file_name = "#{name}-#{version}.tgz", nur auf Leerheit geprüft). Die docker exec-Aufrufe sind Verifikation und Einrichtung, niemals Teil der Fähigkeiten des Angreifers.

Scope

• Bewiesen: ein authentifizierter Benutzer (Developer+ können Pakete veröffentlichen; dieses Labor verwendet aus Bequemlichkeit ein Root-PAT für die Einrichtung) schreibt angreiferkontrollierte Bytes in jeden git-beschreibbaren Pfad. Dateien landen mit 0644.
• Nicht bewiesen hier: RCE. Der gespeicherte Basisname wird gezwungen, auf -<semver>.tgz zu enden (NUL wird vom Kernel abgelehnt, Zeilenumbruch kürzt nicht), daher kann kein exakt benanntes Ziel (secrets.yml, authorized_keys, eine .rb, Gitaly-Binärdateien) überschrieben werden. Der einzige dateinamenunabhängige Ausführungsmechanismus, custom_hooks/<hook>.d/, führt jeden Dateinamen aus, aber nur wenn ausführbar – und dieser Schreibvorgang ist 0644. Das Überschreiben einer vorhandenen 0755-Datei hilft nicht: Der Store ersetzt den Inode und setzt ihn auf 0644 zurück. RCE benötigt also eine separate Executable-Bit-/Ausführungsprimitive, die dieser PoC nicht liefert.

./run.sh rce-gate demonstriert genau dies ehrlich: Es platziert einen pre-receive.d-Hook über die Traversal, pusht und zeigt, dass der 0644-Hook nicht ausgeführt wird. ./rce_gate_demo.sh --illustrate-gate setzt zusätzlich +x über docker exec chmod (eine Out-of-Band-Docker-Root-Aktion, keine Angreiferfähigkeit), nur um zu zeigen, dass Gitaly ihn ausführen würde – was unterstreicht, dass der fehlende Hebel das Exec-Bit ist.

Grundursache & Fix

Siehe ANALYSIS.md für die vollständige Analyse. Kurz gesagt: app/uploaders/gitlab_uploader.rb validierte den Speicherpfad nur before :cache; bei before :store wurde der modellabgeleitete file_name (angreiferkontrolliert, unvalidiert) wörtlich geschrieben. Der Fix fügt before :store, :protect_from_path_traversal! hinzu.

Dateien