GitLab sotto attacco: falla CVSS 10 legge file senza autenticazione

Una vulnerabilità con punteggio CVSS 10.0, sfruttabile da remoto senza autenticazione e capace di leggere file arbitrari dal server: per chi gestisce un’istanza GitLab esposta su Internet è difficile immaginare una combinazione peggiore. La falla, identificata come CVE-2026-85706, interessa GitLab Community Edition ed Enterprise Edition; CISA l’ha appena inserita nel catalogo Known Exploited Vulnerabilities (KEV) dopo aver raccolto evidenze di sfruttamento attivo; la scadenza fissata per le agenzie federali statunitensi coinvolte è addirittura fissata per oggi 14 settembre.

GitLab aveva pubblicato le correzioni il 10 settembre 2026 con le versioni 19.3.2, 19.2.6 e 19.1.8. E non si tratta certo di un bersaglio marginale: la società dichiara oltre 30 milioni di utenti registrati e una presenza superiore al 50% tra le aziende Fortune 100.

Come funziona CVE-2026-85706 e perché il path traversal è così pericoloso

La falla si trova nella Repository Commits API, l’insieme di endpoint con cui GitLab consente di creare commit e manipolare file nei repository tramite API HTTP. GitLab descrive due errori combinati: un controllo insufficiente sul percorso dei file e la mancata applicazione dell’autenticazione nelle condizioni che rendono possibile l’attacco.

Il primo problema appartiene alla famiglia dei path traversal: un’applicazione dovrebbe permettere l’accesso soltanto a file situati all’interno di una directory prevista; se non normalizza e valida correttamente il percorso ricevuto dall’utente, sequenze opportunamente costruite possono indurla a risalire la struttura delle directory e raggiungere file esterni all’area consentita. In pratica, un parametro che dovrebbe indicare un file del repository può finire per diventare uno strumento con cui chiedere al server contenuti locali che l’API non avrebbe mai dovuto restituire.

Da solo, un errore di gestione dei percorsi è già serio. Qui si aggiunge però il secondo ingrediente: GitLab conferma che, sotto determinate condizioni, la lettura può avvenire senza autenticazione: l’aggressione può in questo caso avvenire attraverso la rete, è a bassa complessità, nessun privilegio richiesto e nessuna interazione dell’utente. Sono caratteristiche che spiegano il punteggio massimo CVSS 10.0.

Perché una lettura di file su GitLab può trasformarsi in un incidente serio

Un server GitLab self-managed raramente vive isolato: dialoga con runner CI/CD, registry, database, servizi cloud, sistemi Kubernetes, repository privati e infrastrutture di deployment. Nei progetti possono inoltre comparire variabili protette, credenziali per package registry, token personali e chiavi usate dagli automatismi aziendali.

La possibilità di leggere file locali deve quindi essere valutata pensando a ciò che il server potrebbe conservare, non soltanto alla vulnerabilità presa in astratto.

Configurazioni applicative, file contenenti segreti, materiale utile per autenticarsi verso servizi collegati e informazioni sull’architettura interna possono diventare tasselli per un attacco successivo. Anche quando un determinato file non contiene direttamente una password, può rivelare host interni, percorsi, nomi di servizi o modalità di autenticazione utili per muoversi lateralmente.

Gli aggressori hanno iniziato a cercare server vulnerabili quasi subito

La cronologia è forse la parte più interessante dell’intera vicenda: GitLab pubblica le patch il 10 settembre; l’11 settembre watchTowr comunica di aver riprodotto la vulnerabilità e di osservare attività compatibili con tentativi di individuazione delle installazioni vulnerabili tramite la propria rete globale di honeypot. Nello stesso giorno CISA aggiunge CVE-2026-85706 al catalogo KEV.

L’inserimento nel KEV non significa semplicemente che esiste un proof of concept pubblico: CISA richiede prove credibili di sfruttamento reale prima di classificare una vulnerabilità in questo modo. È quindi un salto di livello rispetto alla sola disponibilità dei dettagli tecnici.

watchTowr segnala inoltre che l’attacco può concentrarsi sulle richieste HTTP POST dirette a percorsi del tipo /api/v4/projects/{id}/repository/commits/ e suggerisce di cercare nei log richieste contenenti parametri file.path anomali.

Non basta però impostare una ricerca letterale troppo rigida: proxy, reverse proxy, sistemi WAF (Web Application Firewall) e formati differenti dei log possono cambiare il modo in cui URI e parametri compaiono nei registri.