L'agenzia americana CISA segnala lo sfruttamento attivo di una falla critica nei server GitLab gestiti in autonomia. Le istruzioni per verificare e aggiornare i sistemi aziendali.
L'agenzia statunitense per la sicurezza delle infrastrutture e della cybersicurezza (CISA) ha diramato un allarme urgente riguardante i server GitLab gestiti in autonomia dalle aziende. L'11 settembre 2026, l'agenzia ha inserito la vulnerabilità identificata dal codice CVE-2026-85706 nel proprio catalogo delle falle di sicurezza sfruttate attivamente dagli aggressori informatici. GitLab aveva pubblicato le correzioni software il 10 settembre 2026, ma già il giorno successivo i ricercatori di sicurezza hanno rilevato scansioni automatizzate su scala globale per individuare e colpire i server non ancora aggiornati esposti su Internet. La situazione ha spinto la CISA a imporre alle agenzie federali l'aggiornamento immediato entro il 14 settembre 2026, estendendo l'avviso di massima urgenza anche al settore privato.
I dettagli della vulnerabilità CVE-2026-85706
Il difetto di sicurezza ha ricevuto un punteggio CVSS di 10.0, il livello massimo di gravità previsto dalla scala di valutazione. Il problema tecnico risiede in una vulnerabilità di attraversamento delle cartelle (nota tecnicamente come path traversal) combinata con una mancata verifica dell'autenticazione nell'interfaccia di programmazione (API) dedicata alla gestione dei salvataggi di codice (commit).
Nella pratica, un aggressore remoto non ha bisogno di possedere un account sul server per sferrare l'attacco. È sufficiente inviare una singola richiesta HTTP POST all'indirizzo /api/v4/projects/{id}/repository/commits/ inserendo parametri specifici per riuscire a leggere file arbitrari presenti sul server. L'unica condizione necessaria affinché l'attacco vada a buon fine è che sull'istanza GitLab sia presente almeno un progetto impostato come pubblico.
I rischi per le imprese italiane
Le aziende che scelgono di installare e gestire internamente il proprio server GitLab (modalità self-managed o on-premise) lo fanno spesso per mantenere il controllo totale su beni digitali di alto valore. Questi server ospitano il codice sorgente del software proprietario, ma anche file di configurazione, chiavi crittografiche, credenziali di accesso ai database e token utilizzati per i rilasci automatici in produzione.
Se un server vulnerabile è raggiungibile da Internet, chiunque può estrarre questi dati in pochi secondi. Il furto di queste informazioni espone l'azienda a conseguenze severe: dal furto di proprietà intellettuale all'infiltrazione profonda nelle reti aziendali, fino alla compromissione della catena di fornitura del software. Un simile incidente comporta inoltre pesanti ripercussioni sul piano della continuità operativa e della conformità alle normative vigenti, come il GDPR per la protezione dei dati personali e la Direttiva NIS2 per la sicurezza delle reti.
Versioni a rischio e sistemi sicuri
Il problema riguarda esclusivamente le installazioni gestite in autonomia, sia nella versione gratuita (Community Edition) che in quella a pagamento (Enterprise Edition).
Le versioni vulnerabili sono le seguenti:
- Dalla versione 18.7 alle versioni precedenti la 19.1.8.
- Dalla versione 19.2.0 alle versioni precedenti la 19.2.6.
- Dalla versione 19.3.0 alle versioni precedenti la 19.3.2.
Le versioni che contengono la correzione di sicurezza sono la 19.1.8, la 19.2.6 e la 19.3.2. Le aziende che utilizzano i servizi gestiti direttamente dal produttore, ovvero GitLab.com (SaaS) e GitLab Dedicated, non devono intraprendere alcuna azione in quanto i sistemi sono già stati messi in sicurezza dal fornitore.
Le azioni da intraprendere sui server aziendali
- Verificare la versione in uso: accedere all'area di amministrazione del proprio server GitLab o visitare la pagina
/helpdell'istanza per controllare il numero di versione installato. - Aggiornare immediatamente: se la versione rientra tra quelle a rischio, applicare subito l'aggiornamento alla release di sicurezza corrispondente al proprio ramo di sviluppo (19.1.8, 19.2.6 o 19.3.2). Il produttore non ha fornito soluzioni temporanee: l'aggiornamento è l'unico modo per chiudere la falla.
- Limitare l'accesso di rete: se l'applicazione della patch richiede tempi tecnici incompatibili con l'urgenza, isolare immediatamente il server da Internet. Rendere l'istanza raggiungibile esclusivamente tramite la VPN aziendale o limitare l'accesso a una lista ristretta di indirizzi IP autorizzati.
- Analizzare i registri di sistema: esaminare i log di accesso per individuare eventuali chiamate HTTP POST sospette dirette verso l'indirizzo
/api/v4/projects/*/repository/commits/che contengano sequenze tipiche dell'attraversamento delle cartelle (come ad esempio../o le sue varianti codificate). - Ruotare le credenziali: se l'analisi dei log rivela tentativi di accesso andati a buon fine, o se il server è rimasto esposto alla rete pubblica senza protezioni nei giorni successivi al 10 settembre 2026, è necessario agire come se i dati fossero stati compromessi. Revocare e generare nuovamente tutti i token API, i certificati, le password di sistema e le chiavi di accesso archiviate sul server.
