Requisiti

• Docker + docker compose, python3, git, curl sull'host.
• ~8 GB di RAM libera (due istanze GitLab, ~4 GB ciascuna) e ~10 GB di disco. Primo avvio: 4–8 min/istanza.
• Eseguire solo contro queste istanze di laboratorio locali. Test autorizzato/difensivo di software di tua proprietà.

Esecuzione

Risultato atteso:

Altri sottocomandi:

Come funziona l'oracolo (niente barare con HTTP-200)

Sia il server vulnerabile sia quello corretto rispondono alla pubblicazione malevola con HTTP 200 {"status":"processing"} — il file viene scritto dopo, nel worker di finalizzazione. Quindi lo stato HTTP non è un oracolo. exploit/poc.py --verify-docker <container> invece interroga dentro il container per verificare la presenza del file controllato nel percorso attraversato e ne confronta lo SHA-1:

• vulnerabile → /var/tmp/CVE_2026_10053_PROOF-1.0.0.tgz appare (proprietario git:git, i nostri byte) → exit 0.
• corretto → il file non appare mai; il worker registra Gitlab::PathTraversal::PathTraversalAttackError: Invalid path → exit 2.

L'exploit in sé non è altro che la richiesta autenticata PUT …/packages/npm/:pkg; la traversal vive interamente nel campo name del body JSON (file_name = "#{name}-#{version}.tgz", sottoposto solo a controllo di vuotezza). Le chiamate docker exec sono verifica e setup, mai parte delle capacità dell'attaccante.

Scope

• Dimostrato: un utente autenticato (Developer+ può pubblicare pacchetti; questo laboratorio usa un root PAT per comodità di setup) scrive byte controllati dall'attaccante in qualsiasi percorso scrivibile da git. I file finiscono con 0644.
• Non dimostrato qui: RCE. Il basename memorizzato è forzato a terminare con -<semver>.tgz (NUL è rifiutato dal kernel, la newline non tronca), quindi nessun target con nome esatto (secrets.yml, authorized_keys, un .rb, i binari di gitaly) può essere sovrascritto. L'unico esecutore indipendente dal nome, custom_hooks/<hook>.d/, esegue qualsiasi file ma solo se eseguibile — e questa scrittura è 0644. Sovrascrivere un file preesistente 0755 non aiuta: lo store sostituisce l'inode, riportandolo a 0644. Quindi la RCE richiede una primitiva separata di bit di esecuzione / esecuzione che questo PoC non fornisce.

./run.sh rce-gate dimostra esattamente questo in modo onesto: pianta un hook pre-receive.d tramite la traversal, fa push e mostra che l'hook 0644 non viene eseguito. ./rce_gate_demo.sh --illustrate-gate imposta inoltre +x tramite docker exec chmod (un'azione docker-root fuori banda, non una capacità dell'attaccante) solo per mostrare che gitaly lo eseguirebbe — sottolineando che la leva mancante è il bit di esecuzione.

Causa principale e correzione

Vedi ANALYSIS.md per l'analisi completa. In breve: app/uploaders/gitlab_uploader.rb validava il percorso di storage solo before :cache; in before :store il file_name derivato dal modello (controllato dall'attaccante, non validato) veniva scritto letteralmente. La correzione aggiunge before :store, :protect_from_path_traversal!.

File