Una singola richiesta HTTP, nessuna password, nessun token. Bastava questo per leggere qualsiasi file su un server GitLab self-hosted vulnerabile, comprese le chiavi SSH e le credenziali del database. La falla si chiama CVE-2026-85706, ha un punteggio CVSS di 10.0 su 10 (il massimo possibile) ed è stata aggiunta al catalogo CISA Known Exploited Vulnerabilities (KEV) l’11 settembre 2026, tre giorni prima della scadenza fissata per le agenzie federali statunitensi. Per i team che gestiscono istanze GitLab Community Edition o Enterprise Edition in Italia e nel resto d’Europa, la finestra tra la pubblicazione della patch e le prime scansioni ostili sul web è stata questione di ore, non di giorni.
Il caso interessa chiunque lavori con pipeline CI/CD, repository privati o infrastrutture DevOps basate su GitLab self-managed. The Hacker News ha descritto le prime ore successive alla divulgazione come un periodo di sonde diffuse su scala mondiale (The Hacker News). Ripercorriamo i fatti, i dati tecnici verificati e cosa cambia per le aziende europee che ancora non hanno applicato la patch.
Cos’è CVE-2026-85706: la falla nella API dei commit di GitLab
CVE-2026-85706 è una vulnerabilità di tipo path traversal (classificata come CWE-22) che colpisce la API dei commit del repository in GitLab CE ed EE. Il problema nasce dalla combinazione di due errori distinti: un controllo insufficiente sui percorsi dei file (path confinement) e la mancata applicazione dell’autenticazione su quell’endpoint specifico. Il risultato è che un utente anonimo, senza account né token di accesso, può inviare una richiesta appositamente costruita e ottenere in risposta il contenuto di qualsiasi file leggibile dal processo GitLab sul server.
GitLab ha descritto il problema nel proprio avviso di patch critica come un caso in cui, in determinate condizioni, un utente non autenticato poteva leggere file arbitrari dal server a causa di un confinamento dei percorsi improprio unito alla mancata applicazione dell’autenticazione nella API dei commit del repository. La formulazione è tecnica ma il concetto è semplice: mancava un controllo che avrebbe dovuto impedire di uscire dalla cartella del repository per finire in qualsiasi altra parte del filesystem del server.
Il punteggio CVSS 10.0 riflette proprio questa combinazione: nessuna autenticazione richiesta, nessuna interazione dell’utente necessaria, impatto massimo sulla riservatezza dei dati. È uno dei pochi casi nel 2026 in cui un prodotto DevOps di uso quotidiano ottiene il punteggio più alto possibile sulla scala di gravità, come confermato anche dalla scheda tecnica del National Vulnerability Database.
Come funziona l’exploit: una richiesta, zero credenziali
Dal punto di vista tecnico, l’attacco sfrutta l’endpoint della API dei commit del repository (/api/v4/projects/:id/repository/commits e le sue sottorotte), che normalmente restituisce informazioni sui commit di un progetto Git. Il parametro che gestisce il percorso del file all’interno del repository non veniva normalizzato correttamente: inserendo sequenze di attraversamento di directory (i classici ../ ripetuti) è possibile uscire dalla cartella del progetto e raggiungere file di sistema, configurazioni e segreti applicativi.
SecurityAffairs ha descritto la dinamica dell’attacco parlando di una richiesta HTTP singola, senza autenticazione, capace di ottenere la lettura completa di un file, sfruttata entro 24 ore dalla divulgazione (SecurityAffairs). Il dettaglio più preoccupante non è la complessità tecnica, che anzi è bassa, ma la velocità con cui gli scanner automatizzati hanno iniziato a testare la falla non appena la patch è diventata pubblica, un comportamento ormai standard quando una vulnerabilità critica viene divulgata insieme al proprio fix.
Rapid7 e watchTowr hanno pubblicato analisi tecniche indipendenti nei giorni successivi alla divulgazione (Rapid7, watchTowr), entrambe orientate a fornire ai team di sicurezza indicazioni pratiche per la verifica delle proprie istanze piuttosto che dettagli di sfruttamento riproducibili, una scelta editoriale comune quando una falla è già sotto attacco attivo.
Cosa possono rubare gli attaccanti
Il vero problema di una falla di lettura file arbitraria su un server GitLab self-hosted è che quel server custodisce, quasi per definizione, i segreti più sensibili dell’intera catena di sviluppo. Tra i file potenzialmente esposti segnalati dalle analisi pubblicate:
- Il file
.gitlab_shell_secret, usato per l’autenticazione interna tra i componenti GitLab - Le chiavi host SSH del server
- I deploy token usati per il rilascio automatico del codice
- Le variabili delle pipeline CI/CD, spesso contenenti credenziali cloud, chiavi API e password di ambienti di produzione
- Le password del database interno di GitLab
- File di configurazione come
gitlab.rbegitlab.yml, con endpoint interni e ulteriori segreti
In pratica, qualsiasi file leggibile dall’utente di sistema che esegue GitLab è un bersaglio potenziale. Per un’azienda che usa GitLab come hub centrale per repository privati, pipeline di build e integrazioni con provider cloud, questo significa che un singolo attacco riuscito può aprire la strada a compromissioni ben più ampie, dalla sottrazione di codice proprietario fino al dirottamento di intere pipeline di distribuzione del software.
Cronologia: dalla patch alle scansioni di massa
La sequenza degli eventi, ricostruita dalle fonti tecniche disponibili, è compressa in pochi giorni. GitLab ha rilasciato le versioni corrette il 10 settembre 2026. Le prime scansioni ostili su larga scala sono state osservate attorno alle 06:00 UTC dell’11 settembre 2026, appena poche ore dopo la pubblicazione della patch, un intervallo che lascia ai team di sicurezza un margine di manovra ridotto al minimo. Lo stesso giorno, CISA ha aggiunto CVE-2026-85706 al catalogo KEV, certificando lo sfruttamento attivo in corso.
| Data | Evento |
|---|---|
| 10 settembre 2026 | GitLab rilascia le versioni 19.1.8, 19.2.6 e 19.3.2 con la correzione di CVE-2026-85706 |
| 11 settembre 2026, ore 06:00 UTC circa | Iniziano le prime scansioni automatizzate su larga scala verso istanze GitLab esposte |
| 11 settembre 2026 | CISA aggiunge CVE-2026-85706 al catalogo Known Exploited Vulnerabilities (KEV) |
| 14 settembre 2026 | Scadenza per la messa in sicurezza da parte delle agenzie civili federali statunitensi |
| 15-17 settembre 2026 | Diffusione di analisi tecniche da parte di Rapid7, watchTowr e testate specializzate; segnalazioni di probing costante sulle istanze non ancora aggiornate |
Tre giorni tra l’inserimento nel catalogo KEV e la scadenza per le agenzie federali sono un termine molto più stretto della media storica, che in passato ha spesso concesso due o tre settimane. La scelta di CISA segnala quanto la vulnerabilità sia considerata critica e già attivamente sfruttata, non solo teoricamente pericolosa.
Versioni interessate e come applicare la patch
La falla riguarda le installazioni self-managed di GitLab Community Edition ed Enterprise Edition in tre rami di versione: dalla 18.7 fino a prima della 19.1.8, dalla 19.2.0 fino a prima della 19.2.6, e dalla 19.3.0 fino a prima della 19.3.2. GitLab.com e GitLab Dedicated, le versioni ospitate direttamente da GitLab, non sono risultate interessate o erano già state messe in sicurezza prima della divulgazione pubblica, secondo quanto riportato dalle fonti tecniche consultate.
Per i team che gestiscono un’istanza self-hosted, il primo passo è verificare rapidamente la versione in uso e programmare l’aggiornamento a una delle release corrette.
# Verifica rapida della versione GitLab in esecuzione
curl -s https://tuo-dominio-gitlab.esempio/api/v4/version \
-H "PRIVATE-TOKEN: TUO_TOKEN_AMMINISTRATIVO"
# Versioni sicure a cui aggiornare:
# 19.1.8 (per il ramo 18.7 - 19.1.x)
# 19.2.6 (per il ramo 19.2.x)
# 19.3.2 (per il ramo 19.3.x)
# Controllo nei log di accesso di richieste sospette verso
# l'endpoint dei commit con sequenze di attraversamento directory
grep "repository/commits" /var/log/gitlab/nginx/gitlab_access.log \
| grep -E "\.\./|%2e%2e"Oltre all’aggiornamento, i team che sospettano un accesso non autorizzato dovrebbero ruotare immediatamente i segreti potenzialmente esposti: chiavi SSH host, deploy token, variabili CI/CD e credenziali del database interno. Un aggiornamento della versione, da solo, non annulla un eventuale furto di credenziali già avvenuto prima della patch.
L’inserimento nel catalogo CISA KEV e cosa significa
Il catalogo Known Exploited Vulnerabilities di CISA non elenca ogni falla critica, ma solo quelle per cui esistono prove concrete di sfruttamento attivo nel mondo reale. L’inclusione di CVE-2026-85706 l’11 settembre 2026 conferma che gli attaccanti non si sono limitati a testare la vulnerabilità in laboratorio, ma l’hanno già usata contro bersagli reali. Per le agenzie federali civili statunitensi, l’iscrizione al KEV comporta un obbligo di rimedio entro una scadenza fissata, in questo caso il 14 settembre 2026.
In Europa, il catalogo KEV non ha valore normativo diretto ma resta un riferimento operativo seguito da molti team di sicurezza, incluse le organizzazioni soggette a NIS2, che richiede la gestione tempestiva delle vulnerabilità critiche nella catena di fornitura del software. Le aziende italiane che rientrano nel perimetro NIS2 e usano GitLab self-hosted per lo sviluppo interno dovrebbero considerare l’inclusione nel KEV un segnale sufficiente per trattare la patch come priorità assoluta, non come manutenzione ordinaria da pianificare nelle settimane successive.
Perché un CVSS 10.0 è un evento raro
Il punteggio CVSS 10.0 è il massimo teorico della scala e viene assegnato solo quando tutti i fattori di gravità raggiungono il loro valore peggiore contemporaneamente: vettore di attacco di rete, bassa complessità, nessun privilegio richiesto, nessuna interazione dell’utente e impatto elevato sulla riservatezza dei dati esposti. Nella pratica quotidiana della sicurezza informatica, la maggior parte delle vulnerabilità critiche si ferma tra 8.0 e 9.8. Un 10.0 pieno segnala che chi assegna il punteggio considera lo scenario peggiore realisticamente raggiungibile, senza alcuna barriera intermedia.
Nel 2026 questo punteggio massimo è stato assegnato anche ad altre falle di rilievo, come la vulnerabilità in Adobe Commerce (CVE-2026-75650) e quella in Azure SQL Database (CVE-2026-56162), a conferma che i prodotti con superfici di attacco ampie e privilegi elevati restano il bersaglio preferito quando emergono errori di validazione degli input o di controllo degli accessi.
Confronto con altre falle critiche del 2026
Per inquadrare la gravità di CVE-2026-85706 è utile confrontarla con altre vulnerabilità critiche emerse nel corso del 2026 su prodotti altrettanto centrali nelle infrastrutture aziendali europee. La tabella seguente riporta i dati pubblicamente disponibili su alcune delle falle più significative dell’anno, tutte con un impatto potenziale su credenziali, dati sensibili o catena di fornitura del software.
| Vulnerabilità | Prodotto | CVSS | Autenticazione richiesta | Tipo di impatto |
|---|---|---|---|---|
| CVE-2026-85706 | GitLab CE/EE (API commit repository) | 10.0 | No | Lettura file arbitraria, furto credenziali e segreti CI/CD |
| CVE-2026-75650 | Adobe Commerce / Magento | 10.0 | No | Compromissione completa del sistema e-commerce |
| CVE-2026-82329 | JFrog Artifactory | 9,8 | No | Bypass autenticazione, creazione account admin persistenti |
| CVE-2026-84869 | ConnectWise ScreenConnect | 9,9 | No | Accesso remoto non autorizzato |
| CVE-2026-58240 | SAP NetWeaver | 9,8 | No | Esecuzione codice remoto |
Il tratto comune a queste falle non è solo il punteggio elevato, ma il fatto che nessuna richiede autenticazione: gli attaccanti possono colpire direttamente dall’esterno, senza dover prima rubare o indovinare una credenziale valida. È una tendenza che rende meno solida l’idea che tenere un pannello di amministrazione solo dietro login basti come protezione, quando l’errore risiede più in profondità, nella logica stessa dell’endpoint esposto.
Il precedente di JFrog Artifactory: una falla simile, stesso schema
Il parallelo più stretto con CVE-2026-85706 arriva da un’altra piattaforma centrale nello sviluppo software: JFrog Artifactory. Tra il 15 agosto e l’8 settembre 2026, diversi gruppi di attaccanti hanno incatenato tre vulnerabilità, CVE-2026-42018, CVE-2026-42016 e CVE-2026-82329, per generare token validi, creare account amministrativi persistenti e installare backdoor. Tutte e tre sono finite anch’esse nel catalogo CISA KEV come attivamente sfruttate. Lo schema è lo stesso osservato ora su GitLab: un errore nella logica di autenticazione di una piattaforma DevOps centrale, sfruttato in tempi rapidissimi da attori automatizzati prima ancora che molte organizzazioni completino l’inventario delle proprie istanze esposte.
Questa ripetizione di pattern, due falle critiche su due piattaforme DevOps di riferimento nel giro di un mese, suggerisce che gli strumenti di build, versionamento e distribuzione del software siano diventati un bersaglio prioritario per chi cerca di infiltrarsi nella catena di fornitura, più redditizio di un singolo endpoint applicativo perché dà accesso a centinaia o migliaia di progetti contemporaneamente.
Impatto sul mercato DevOps e sulla catena di fornitura del software
GitLab è una delle piattaforme più diffuse al mondo per la gestione del ciclo di vita dello sviluppo software, con installazioni self-hosted particolarmente diffuse tra aziende che, per motivi di conformità normativa o di controllo dei dati, preferiscono non affidarsi a servizi SaaS pubblici. Proprio questa scelta, spesso motivata da esigenze di sicurezza, espone chi non applica tempestivamente gli aggiornamenti a un rischio più alto rispetto a chi usa GitLab.com, dove le patch vengono distribuite centralmente dal fornitore.
Il rilascio della patch ha coinciso con una versione che, secondo le fonti tecniche disponibili, correggeva in totale 17 vulnerabilità di sicurezza, con CVE-2026-85706 indicata come la più grave del lotto (GitLab). Questo dato racconta una dinamica comune nel settore: le vulnerabilità critiche raramente arrivano isolate, ma emergono spesso da cicli di revisione interna o da segnalazioni di ricercatori che portano alla luce più problemi contemporaneamente durante lo stesso ciclo di audit.
Per il mercato degli strumenti DevOps, l’episodio rafforza una pressione già in atto verso una migrazione più rapida ai servizi gestiti dai fornitori, dove la responsabilità del patching tempestivo ricade sul provider stesso, e verso l’adozione più diffusa di strumenti di scansione automatica delle configurazioni esposte e di dependency scanning nelle pipeline interne.
La situazione in Italia e in Europa
Le fonti tecniche pubbliche consultate non riportano, al momento della pubblicazione di questo articolo, nomi di aziende italiane o europee confermate come vittime dirette dello sfruttamento di CVE-2026-85706. Questo non significa che il rischio sia teorico: le analisi disponibili parlano di scansioni automatizzate diffuse su scala internazionale e di sfruttamento attivo certificato da CISA, condizioni che storicamente precedono la comparsa di vittime confermate nel giro di settimane, non di mesi.
Per le aziende italiane soggette alla direttiva NIS2, che impone obblighi di gestione del rischio informatico e di notifica tempestiva degli incidenti a settori considerati essenziali o importanti, una vulnerabilità di questo tipo, se sfruttata su un’istanza GitLab che gestisce codice proprietario o pipeline di distribuzione verso l’infrastruttura di produzione, potrebbe qualificarsi come incidente significativo da notificare. Le organizzazioni che ancora non hanno completato l’inventario delle proprie istanze GitLab self-hosted, comprese quelle usate solo per progetti interni o di test, dovrebbero considerarlo un compito urgente, non secondario.
Perché gli attaccanti si muovono così in fretta
Il tempo trascorso tra il rilascio della patch e l’inizio delle scansioni ostili, poche ore secondo le analisi disponibili, non è un caso isolato ma il risultato di una prassi ormai consolidata tra gli attori malevoli: confrontare automaticamente il codice sorgente delle versioni corrette con quelle precedenti, un processo noto come patch diffing, per individuare rapidamente dove si trova la correzione e, di conseguenza, come sfruttare la falla prima che la maggior parte delle organizzazioni completi l’aggiornamento.
Per una vulnerabilità come CVE-2026-85706, con un exploit tecnicamente semplice da riprodurre una volta compreso il meccanismo, il divario tra patch disponibile ed exploit pubblico funzionante può ridursi a poche ore. È lo stesso schema osservato negli ultimi due anni per la maggior parte delle falle critiche in prodotti enterprise ampiamente diffusi, dai gateway VPN ai sistemi di gestione dei repository.
Previsioni: cosa aspettarsi nelle prossime settimane
Sulla base della cronologia osservata e dei precedenti simili nel 2026, ci sono alcuni sviluppi ragionevolmente prevedibili nelle settimane successive alla divulgazione di CVE-2026-85706.
- È probabile un aumento delle segnalazioni di compromissioni riconducibili alla falla man mano che i team forensi analizzano log storici alla ricerca di richieste sospette verso l’endpoint dei commit, anche retroattivamente rispetto a settembre 2026.
- I gruppi ransomware che già sfruttano falle di accesso iniziale su piattaforme DevOps, come osservato con JFrog Artifactory nelle settimane precedenti, potrebbero integrare CVE-2026-85706 nei propri strumenti automatizzati di scansione e accesso iniziale.
- Le aziende europee soggette a NIS2 e Cyber Resilience Act dovrebbero vedere un aumento delle richieste di audit sulla gestione delle patch per strumenti DevOps interni, con particolare attenzione ai tempi di reazione dopo la pubblicazione di CVE critiche.
- GitLab potrebbe rafforzare i controlli automatici sulle nuove API introdotte, dato che il pattern di autenticazione mancante su un endpoint specifico si è già ripetuto più volte nel settore nel 2026.
- È plausibile un aumento della domanda per strumenti di rilevamento delle istanze GitLab esposte pubblicamente, sul modello delle scansioni Shodan e Censys già usate dai ricercatori per stimare la superficie di attacco reale.
Cosa devono fare i team IT adesso
La prima priorità resta l’aggiornamento immediato a una delle versioni corrette: 19.1.8, 19.2.6 o 19.3.2 a seconda del ramo in uso. Chi non può aggiornare immediatamente dovrebbe valutare di restringere l’accesso di rete all’istanza GitLab, ad esempio limitandolo a reti VPN interne, come misura temporanea in attesa della finestra di manutenzione.
Parallelamente, è opportuno rivedere i log di accesso alla ricerca di richieste verso l’endpoint dei commit contenenti sequenze di attraversamento directory, e considerare la rotazione precauzionale dei segreti più sensibili (chiavi SSH host, deploy token, credenziali del database) se l’istanza è rimasta esposta pubblicamente e non aggiornata durante la finestra critica tra il 10 e il 15 settembre 2026. Per le organizzazioni con più istanze GitLab distribuite tra team diversi, un inventario centralizzato aggiornato in tempo reale, e non ricostruito manualmente ogni volta che emerge una CVE critica, resta la differenza pratica tra una risposta in ore e una in settimane.
Domande frequenti
Cos’è esattamente CVE-2026-85706?
È una vulnerabilità critica di path traversal nella API dei commit del repository di GitLab CE ed EE, che permette a un utente non autenticato di leggere file arbitrari sul server. Ha un punteggio CVSS di 10.0, il massimo della scala.
GitLab.com è interessato dalla falla?
No. Secondo le fonti tecniche disponibili, GitLab.com e GitLab Dedicated non sono risultati vulnerabili o erano già stati messi in sicurezza prima della divulgazione pubblica. Il rischio riguarda le installazioni self-managed.
Quali versioni di GitLab sono vulnerabili?
Le versioni comprese tra 18.7 e prima della 19.1.8, tra 19.2.0 e prima della 19.2.6, e tra 19.3.0 e prima della 19.3.2. Le versioni corrette sono 19.1.8, 19.2.6 e 19.3.2.
La falla è già stata sfruttata attivamente?
Sì. CISA ha aggiunto CVE-2026-85706 al catalogo Known Exploited Vulnerabilities l’11 settembre 2026, e le analisi tecniche pubbliche riportano scansioni ostili su larga scala iniziate poche ore dopo il rilascio della patch.
Cosa rischia un’azienda che non aggiorna GitLab in tempo?
Il rischio principale è la sottrazione di credenziali e segreti sensibili (chiavi SSH, deploy token, variabili CI/CD, password del database), che possono essere usati per compromettere ulteriormente la pipeline di sviluppo o accedere a codice proprietario e infrastrutture collegate.
Basta aggiornare la versione per essere al sicuro?
L’aggiornamento chiude la falla, ma non annulla un eventuale furto di credenziali avvenuto prima della patch. Chi ha lasciato un’istanza esposta durante la finestra critica dovrebbe anche ruotare i segreti più sensibili.
Ci sono vittime confermate in Italia o in Europa?
Al momento della pubblicazione di questo articolo, le fonti pubbliche non riportano nomi di aziende italiane o europee confermate come vittime dirette. Le analisi parlano però di scansioni diffuse a livello internazionale.
Come si collega questa falla alla normativa NIS2?
Le aziende italiane rientranti nel perimetro NIS2 hanno obblighi di gestione del rischio e di notifica tempestiva degli incidenti. Uno sfruttamento riuscito di una falla critica come questa su un’istanza che gestisce codice o pipeline di produzione potrebbe qualificarsi come incidente significativo da notificare.
