CVE-2026-85706 è una vulnerabilità critica di GitLab CE ed EE con punteggio CVSS 10.0 che può permettere a un utente non autenticato di leggere file arbitrari dal server GitLab. GitLab ha pubblicato le correzioni il 10 settembre 2026 e raccomanda di aggiornare immediatamente le installazioni self-managed interessate. L’urgenza è aumentata l’11 settembre, quando CISA ha inserito la falla nel catalogo delle vulnerabilità note come sfruttate attivamente.
Se utilizzi GitLab.com, non devi installare nulla: GitLab dichiara che il servizio è già sulla versione corretta. Anche i clienti GitLab Dedicated non devono intervenire. Il controllo riguarda soprattutto chi gestisce una propria istanza GitLab su server, VPS, cloud o infrastruttura aziendale.
CVE-2026-85706: quali versioni di GitLab sono vulnerabili
Nella patch release ufficiale del 10 settembre 2026, GitLab indica come interessate le installazioni CE ed EE nei seguenti intervalli.
| Ramo GitLab | Versioni vulnerabili | Versione corretta |
|---|---|---|
| 18.7, 18.8, 18.9, 18.10, 18.11, 19.0 e 19.1 | Dalla 18.7 fino alle versioni precedenti alla 19.1.8 | 19.1.8 o ramo supportato più recente |
| 19.2 | Dalla 19.2.0 alla 19.2.5 | 19.2.6 |
| 19.3 | Dalla 19.3.0 alla 19.3.1 | 19.3.2 |
Non basta quindi controllare di avere “GitLab 19”. Anche release recenti dei rami 19.1, 19.2 e 19.3 sono vulnerabili se non hanno ricevuto la patch indicata. Se stai ancora usando un ramo più vecchio, verifica il percorso di aggiornamento ufficiale di GitLab invece di saltare versioni senza controllare i requisiti intermedi.
Cosa permette di fare la falla
GitLab descrive CVE-2026-85706 come un problema di path traversal nella repository commits API. In determinate condizioni, la combinazione di confinamento non corretto dei percorsi e controlli di autenticazione mancanti può permettere a un aggressore remoto non autenticato di leggere file arbitrari dal server.
Il punto più importante per un amministratore non è riprodurre tecnicamente l’exploit, ma capire l’impatto: un’istanza GitLab self-managed può contenere configurazioni, token, credenziali di integrazione e altri dati sensibili utilizzati da repository e pipeline. La possibilità di leggere file che non dovrebbero essere accessibili rende la patch prioritaria, soprattutto per le istanze esposte a Internet.
GitLab assegna alla vulnerabilità il massimo punteggio CVSS 10.0 e indica un vettore di attacco di rete, senza privilegi e senza interazione dell’utente. Questo è sufficiente per trattare l’aggiornamento come urgente anche prima di osservare sintomi visibili sul server.
La falla è già sfruttata: cosa significa l’inserimento nel CISA KEV
L’11 settembre 2026 CISA ha aggiunto CVE-2026-85706 al catalogo Known Exploited Vulnerabilities (KEV). L’inserimento nel KEV indica che l’agenzia dispone di evidenze sufficienti per considerare la vulnerabilità sfruttata nel mondo reale, non soltanto teoricamente sfruttabile.
Il catalogo CISA KEV fissa per le agenzie federali civili statunitensi una scadenza di remediation al 14 settembre 2026. Quella data non è un obbligo universale per aziende e utenti privati, ma è un segnale molto chiaro sulla priorità della patch.
Anche ricercatori indipendenti hanno segnalato attività di scansione e tentativi di sfruttamento dopo la divulgazione. Per un amministratore, quindi, la strategia corretta non è aspettare un ulteriore aggiornamento: se la versione è vulnerabile, va portata subito a una release corretta.
GitLab.com è vulnerabile?
GitLab.com è già stato aggiornato. La stessa advisory ufficiale specifica che il servizio cloud gira su una versione corretta e che i clienti GitLab Dedicated non devono eseguire azioni specifiche.
| Tipo di utilizzo | Cosa fare |
|---|---|
| Account su GitLab.com | Nessuna patch manuale richiesta |
| GitLab Dedicated | Nessuna azione richiesta secondo GitLab |
| GitLab self-managed vulnerabile | Aggiornare immediatamente |
| GitLab self-managed già su 19.1.8, 19.2.6 o 19.3.2 | Verificare l’esito dell’update e continuare il monitoraggio |
Come controllare la versione installata
Prima dell’aggiornamento serve il numero completo della release, non soltanto il ramo principale. Puoi verificarlo dall’interfaccia amministrativa di GitLab oppure con gli strumenti previsti dal metodo di installazione utilizzato.
- Identifica se l’istanza è self-managed, GitLab.com o Dedicated.
- Annota il numero completo della versione, per esempio 19.3.1.
- Confrontalo con gli intervalli vulnerabili pubblicati da GitLab.
- Se rientra tra le release interessate, pianifica l’aggiornamento immediato alla patch corretta.
- Dopo l’upgrade, ricontrolla la versione e lo stato dei servizi.
Se l’istanza è su un ramo non più supportato, non fermarti all’idea di “installare la patch della stessa serie”: potrebbe non esistere una build corretta per quel ramo. Segui invece il percorso di upgrade documentato verso una versione supportata.
Attenzione al downtime: questa patch include migrazioni database
La release 19.3.2/19.2.6/19.1.8 contiene anche migrazioni del database. GitLab avverte che questo dettaglio può incidere sulla procedura di aggiornamento.
- Istanza single-node: GitLab indica che durante l’upgrade ci sarà downtime perché le migrazioni devono completarsi prima del riavvio del servizio.
- Istanza multi-node: è possibile seguire la procedura ufficiale di zero-downtime upgrade, se l’architettura e il percorso di aggiornamento lo consentono.
Questo non è un motivo per rimandare la patch. Significa piuttosto che l’amministratore deve preparare backup, finestra di manutenzione e piano di rollback secondo le procedure della propria infrastruttura.
Aggiornare basta? I controlli da fare dopo la patch
Applicare la correzione chiude la vulnerabilità, ma non dimostra che un server esposto mentre era vulnerabile non sia stato interrogato prima dell’update. Per questo, soprattutto sulle istanze raggiungibili da Internet, ha senso eseguire una verifica post-patch.
- controlla log HTTP e applicativi per richieste anomale nel periodo precedente all’aggiornamento;
- verifica accessi amministrativi, account e token creati o modificati senza spiegazione;
- controlla configurazioni CI/CD, integrazioni e credenziali utilizzate dal server;
- se emergono indicatori compatibili con un accesso non autorizzato, ruota token, chiavi e password potenzialmente esposti;
- verifica che runner e sistemi collegati non mostrino attività inattese.
Non è necessario assumere che ogni istanza vulnerabile sia stata compromessa. La presenza nel CISA KEV cambia però il livello di prudenza: non siamo più davanti a una falla soltanto teorica.
CVE-2026-85706 è diversa dalla precedente falla GitLab di agosto
Ad agosto avevamo seguito CVE-2026-19478, la vulnerabilità GitLab che poteva consentire modifiche o cancellazioni di progetti pubblici senza login. CVE-2026-85706 è un problema distinto: riguarda la lettura arbitraria di file attraverso la repository commits API e richiede quindi una nuova patch.
Questo è importante per evitare un errore comune: aver installato la correzione di agosto non protegge automaticamente dalla falla di settembre. Le versioni da verificare oggi sono 19.1.8, 19.2.6 e 19.3.2, oppure una release successiva supportata che includa la correzione.
Il problema si inserisce in un quadro più ampio di sicurezza delle piattaforme DevOps. Sul sito abbiamo approfondito anche i rischi dei repository Git esposti e delle credenziali lasciate nei progetti: quando il repository e le pipeline sono collegati a sistemi di produzione, proteggere il server che li gestisce diventa parte della sicurezza dell’intera infrastruttura.
Cosa fare subito se amministri GitLab
- Controlla la versione completa dell’istanza.
- Se è vulnerabile, prepara backup e finestra di manutenzione.
- Aggiorna a 19.1.8, 19.2.6 o 19.3.2 in base al ramo, oppure a una release supportata più recente seguendo il percorso ufficiale.
- Ricontrolla che l’upgrade sia completato e che i servizi siano operativi.
- Analizza i log del periodo in cui l’istanza era esposta.
- Se trovi segnali sospetti, ruota le credenziali potenzialmente accessibili e amplia l’indagine ai sistemi collegati.
La risposta breve è quindi semplice: se gestisci un GitLab self-managed compreso negli intervalli vulnerabili, non aspettare il prossimo ciclo ordinario di patch. CVE-2026-85706 ha CVSS 10.0, è stata inserita nel CISA KEV ed è già coperta dalle versioni correttive pubblicate da GitLab.
Domande frequenti su CVE-2026-85706
Quali versioni correggono CVE-2026-85706?
GitLab ha pubblicato le versioni 19.1.8, 19.2.6 e 19.3.2. Chi usa rami precedenti deve verificare il percorso di upgrade verso una release supportata e corretta.
GitLab.com deve essere aggiornato dall’utente?
No. GitLab dichiara che GitLab.com è già sulla versione corretta. Anche i clienti GitLab Dedicated non devono applicare manualmente la patch.
CVE-2026-85706 viene già sfruttata negli attacchi?
Sì. CISA l’ha inserita nel catalogo Known Exploited Vulnerabilities l’11 settembre 2026, quindi la vulnerabilità soddisfa i criteri dell’agenzia per lo sfruttamento noto nel mondo reale.
La patch richiede downtime?
GitLab avverte che le installazioni single-node avranno downtime durante le migrazioni database. Le configurazioni multi-node possono seguire, quando applicabile, la procedura ufficiale di zero-downtime upgrade.
