gitread

CVE-2026-85706 · Lettura di file non autenticata in GitLab CE/EE · PoC di ricerca con modalità oracle, enumerazione dei fd e targeting a livelli del loot

Come funziona

Tre endpoint delle API dei repository si trovano dietro il requestBodyUploader di Workhorse:

L'handler Rails chiama File.open(params['file.path']) prima di authenticate!. Quattro condizioni rendono questo sfruttabile:

1. L'autenticazione scatta dopo la lettura del file. require_gitlab_workhorse! controlla solo l'header JWT Gitlab-Workhorse-Api-Request. Workhorse appone quell'header su ogni richiesta che proxa, inclusi i semplici passthrough. Il vero authenticate! risiede dentro authorize_push_to_branch!, che viene eseguito dopo che file_params_from_body_upload ha già letto il file dal disco.

2. file.path proviene direttamente dalla richiesta. file_params_from_body_upload legge params['file.path'] come percorso assoluto senza alcuna validazione. Nel flusso previsto Workhorse scrive l'upload in un file temporaneo e inietta da sé quel parametro. Un attaccante lo invia semplicemente in modo diretto come parametro di query string che punta a qualsiasi punto del filesystem.

3. Il route matching di Workhorse non decodifica mai il percent-encoding. Workhorse confronta le route di upload con EscapedPath(), i byte grezzi dell'URL così come ricevuti. Puma decodifica le sequenze %XX prima di instradare verso Grape. Quindi codificare un carattere in un segmento statico fa sì che Workhorse salti la sua regola di rewrite mentre Rails instrada comunque verso l'handler vulnerabile:

4. Rack rimanda il contenuto del file nella risposta di errore. Con Content-Type: application/x-www-form-urlencoded, il contenuto del file viene passato a Rack::Utils.parse_nested_query. Qualsiasi % isolato non seguito da due cifre esadecimali solleva InvalidParameterError: invalid %-encoding (<content>). Tutto ciò che precede il primo & nel file viene rimandato nel body 400.

I file senza % isolati vengono comunque letti pre-auth. La risposta 401 dal ramo urlencoded e una 500 dal ramo multipart confermano entrambe che il file esiste ed è leggibile dall'utente git, rendendole utili come oracolo di esistenza.

Richiesta di exploit:

Funzionalità

• --file legge qualsiasi singolo file; ricade automaticamente sull'oracolo se non c'è un trigger di echo
• --loot esegue 36 target su 7 tier, ordinati per probabilità confermata di trigger di echo
• --oracle esegue una sonda a doppio ramo (urlencoded + multipart) su file senza echo e ti dice se ciascuno è leggibile, mancante o non leggibile
• --proc enumera /proc/self/fd/0-31 per trovare file descriptor aperti, poi legge i target di recon standard in /proc
• --shell apre una shell interattiva di lettura file con i comandi cat, loot, oracle, project e curl
• --pipe legge i target da stdin e gestisce output di subfinder, testo httpx, JSON httpx, JSON nuclei e righe host grezze
• --list accetta un file di target uno per riga
• --threads per la scansione bulk concorrente
• --proxy instrada tutto attraverso Burp o mitmproxy
• --raw scrive byte grezzi su stdout senza decorazioni, utile per il piping verso un file
• --full esegue loot, oracle e proc in un'unica passata
• Output di report JSON e JSONL tramite -o
• Fingerprint della versione di GitLab con controllo dell'intervallo interessato
• Supporto ai colori del terminale Windows

Installazione

Richiede Python 3.10 o superiore. Nessun'altra dipendenza.

Utilizzo

Target singolo

Pipeline

stdin viene rilevato automaticamente quando non è un TTY, quindi --pipe è opzionale nella maggior parte dei casi.

Shell

Verdetti delle risposte

Tier del loot

Flag

Codici di uscita: 0 leak confermato, 1 solo oracolo o nessun leak in pipeline, 2 nulla trovato.

Patch

Corretto nel commit master 0d9ce3e7, backportato come 1fe30154 / b43c8b26 / 0ff7b6b2.

Tre cose sono state modificate contemporaneamente:

1. authenticate! è stato spostato prima di file_params_from_body_upload in tutti e tre gli endpoint, così il file non viene mai letto per una richiesta non autenticata
2. file.path ora è accettato solo da un oggetto UploadedFile tipizzato prodotto dal middleware multipart, che richiede un JWT valido firmato da Workhorse, non da un parametro di query string grezzo
3. InvalidParameterError non interpola più e.message nel body della risposta, così il canale di echo è chiuso anche se qualcuno trovasse un modo per aggirare i primi due fix

Il bug è stato introdotto in GitLab 18.7 (dicembre 2025) quando è stata aggiunta la variante body-upload dell'API dei commit.

fatto con amore da @plur1bu5 -- se lo trovi utile, una stella è apprezzata