CVE-2026-85706: Grave Flaw di Traverso del Percorso in GitLab Sfruttata Attivamente

GitLab ha rilasciato aggiornamenti di sicurezza urgenti per una vulnerabilità di massima gravità nelle edizioni Community (CE) ed Enterprise (EE) che consente agli attaccanti non autenticati di leggere file arbitrari dai server vulnerabili. Seguita come CVE-2026-85706 e valutata 10,0 sulla scala CVSS, la falla risiede nell’API dei commit del repository e deriva da un confinamento inadeguato del percorso combinato con l’assenza di un’applicazione dell’autenticazione.

Il rischio è aumentato quasi immediatamente dopo la divulgazione. I ricercatori di sicurezza hanno osservato una scansione su scala mondiale di internet iniziata approssimativamente alle 06:00 UTC l’11 settembre 2026, subito dopo che GitLab ha rilasciato le patch. Successivamente CISA ha aggiunto la vulnerabilità al suo catalogo di Vulnerabilità Sfruttate Note basandosi su prove di sfruttamento attivo.

Lo sfruttamento riuscito può esporre file sensibili memorizzati sul server GitLab, inclusi dati di configurazione, credenziali, segreti, log e altre informazioni accessibili al servizio GitLab. Negli ambienti di sviluppo, quei file possono contenere segreti CI/CD, credenziali di distribuzione, token, dati relativi al codice sorgente e informazioni che potrebbero supportare compromissioni successive.

La falla è particolarmente pericolosa per le installazioni GitLab autogestite esposte a Internet perché lo sfruttamento non richiede un account, privilegi esistenti o interazione dell’utente. Secondo watchTowr, il prerequisito principale per il percorso di attacco osservato è che l’istanza GitLab contenga almeno un progetto pubblico.

Analisi CVE-2026-85706

La vulnerabilità è un problema di traversal del percorso nell’API dei commit del repository di GitLab. GitLab descrive la causa principale come un confinamento insufficiente dei percorsi dei file combinato con il mancato impiego dell’autenticazione sulla funzionalità interessata. Ciò consente alle informazioni sui percorsi controllate dall’attaccante di sfuggire alla posizione in cui GitLab si aspetta che risiedano i file del repository e fare riferimento ad altri file disponibili per l’applicazione.

Il vettore CVSS assegnato da GitLab è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Riflette una vulnerabilità sfruttabile da remoto con bassa complessità di attacco, nessun requisito di autenticazione e nessuna interazione dell’utente. GitLab assegna impatti elevati per la riservatezza e l’integrità, mentre la disponibilità non è direttamente influenzata dal primitivo di lettura dei file.

I dettagli più importanti per CVE-2026-85706 sono che gli attaccanti possono interagire da remoto con l’API dei commit del repository vulnerabile e richiedere percorsi che dovrebbero cadere al di fuori della directory del repository permessa. Se GitLab fallisce nel contenere correttamente quel percorso, il server può restituire il contenuto di un file arbitrario accessibile al processo GitLab.

Secondo watchTowr, lo sfruttamento può esporre file di configurazione specifici di GitLab e file di log contenenti credenziali, segreti e altre informazioni sensibili. A seconda della configurazione del sistema e dei permessi sui file, gli attaccanti possono anche puntare a chiavi SSH, file di ambiente, credenziali del database, token di distribuzione o altri dati sensibili dell’applicazione.

CVE-2026-85706 interessa i seguenti rilasci GitLab CE e EE:

• Tutte le versioni da 18.7 prima di 19.1.8
• Tutte le versioni da 19.2 prima di 19.2.6
• Tutte le versioni da 19.3 prima di 19.3.2

GitLab.com era già in esecuzione con la versione patchata quando il problema è stato divulgato, mentre i clienti di GitLab Dedicated non devono intraprendere alcuna azione. L’obbligo urgente di rimedio si applica principalmente alle organizzazioni che operano con istanze GitLab autogestite.

Il requisito di almeno un progetto pubblico aumenta significativamente l’esposizione delle organizzazioni che ospitano intenzionalmente repository open-source, progetti di sviluppo pubblici, risorse della comunità o altri contenuti accessibili anonimamente sulla propria infrastruttura GitLab. Un attaccante non necessita di essere membro del progetto o avere un account GitLab valido prima di tentare lo sfruttamento.

Le conseguenze possono estendersi oltre la semplice divulgazione delle informazioni. GitLab spesso si trova al centro delle pipeline di sviluppo software e memorizza materiale altamente sensibile, incluso il codice sorgente, variabili CI/CD, credenziali di distribuzione, configurazione dell’infrastruttura, token di accesso e segreti d’integrazione.

Se un attaccante ottiene tali credenziali tramite l’accesso a file arbitrari, la vulnerabilità iniziale di GitLab può diventare una base per ulteriori attività di intrusione. I segreti rubati potrebbero potenzialmente fornire accesso a repository di codice sorgente, infrastrutture CI/CD, servizi cloud, registri di container, sistemi di distribuzione o altre risorse connesse.

Questo introduce anche un rischio per la catena di fornitura del software. L’accesso a credenziali di sviluppo o infrastrutture di build potrebbe consentire a un attaccante di tentare modifiche non autorizzate ai repository, manipolare i processi di build, rubare codice proprietario o compromettere i sistemi a valle che si fidano dei manufatti prodotti attraverso l’ambiente GitLab interessato.

GitLab ha accreditato il ricercatore di sicurezza s3ntago per aver segnalato la vulnerabilità attraverso il programma di bug bounty di HackerOne dell’azienda. La data esatta di scoperta privata e di segnalazione non sono state divulgate pubblicamente. GitLab ha rilasciato versioni fisse su 10 settembre 2026 e ha documentato pubblicamente la falla come parte del suo rilascio di patch critiche.

La transizione dalla divulgazione all’attività ostile è stata estremamente rapida. WatchTowr ha dichiarato che la sua rete honeypot Attacker Eye ha rilevato sonde comportamentali mirate alla vulnerabilità approssimativamente da 06:00 UTC dell’11 settembre, indicando che attori esterni avevano già ingegnerizzato all’indietro la debolezza e iniziato a testare i sistemi GitLab accessibili da internet.

CISA ha aggiunto la falla al suo catalogo KEV più tardi l’11 settembre dopo aver confermato prove di sfruttamento attivo. Alle agenzie federali del ramo esecutivo civile è stato ordinato di porre rimedio ai sistemi interessati entro 14 settembre 2026, e CISA ha anche contrassegnato la vulnerabilità come richiedente una triage forense sotto la Direttiva Operativa Vincolante 26-04.

Un codice PoC pubblico per CVE-2026-85706 è apparso poco dopo la divulgazione, abbassando ulteriormente la barriera tecnica per gli attaccanti interessati a riprodurre il comportamento di lettura di file arbitrari. Combinato con la bassa complessità della vulnerabilità e il percorso di attacco non autenticato, la riproduzione pubblica aumenta la probabilità di un più ampio sfruttamento opportunistico.

Attualmente non esiste un set completo di IOC specifici per campagna per CVE-2026-85706, come indirizzi IP degli attaccanti, domini o hash di malware che possano identificare affidabilmente lo sfruttamento. Invece, l’indicatore più utile è la struttura delle richieste che mirano all’API vulnerabile di GitLab.

WatchTowr raccomanda di cercare richieste HTTP POST dirette a percorsi che corrispondono a:

/api/v4/projects/{id}/repository/commits/

I difensori dovrebbero prestare particolare attenzione quando quelle richieste contengono parametri di percorso file sospetti o sembrano richiedere file non correlati al repository a cui si accede.

Mitigazione CVE-2026-85706

GitLab raccomanda fortemente che tutte le installazioni autogestite interessate aggiornino immediatamente a una delle versioni fisse:

• GitLab 19.1.8
• GitLab 19.2.6
• GitLab 19.3.2

Qualsiasi versione successiva supportata contenente la correzione di sicurezza dovrebbe anche affrontare la vulnerabilità. Gli amministratori dovrebbero verificare l’esatta versione in esecuzione piuttosto che supporre che l’aggiornamento automatico sia avvenuto.

Le organizzazioni impossibilitate a patchare immediatamente dovrebbero rimuovere l’accesso pubblico non necessario all’istanza GitLab interessata o restringere la connettività al livello del proxy inverso, firewall, bilanciamento del carico o della rete fino al completamento dell’aggiornamento. Questa è solo una misura temporanea di riduzione dell’esposizione e non dovrebbe sostituire l’installazione della versione corretta di GitLab.

La rilevazione di CVE-2026-85706 dovrebbe iniziare identificando tutte le istanze GitLab autogestite, le loro versioni esatte e se erano accessibili da internet dopo il 10 settembre. I sistemi ospitanti uno o più progetti pubblici dovrebbero ricevere una priorità di indagine particolarmente alta.

Per rilevare lo sfruttamento o la ricognizione di CVE-2026-85706, i difensori dovrebbero esaminare la telemetria di GitLab, proxy inverso, WAF e server web per:

• Richieste HTTP POST a /api/v4/projects/{id}/repository/commits/
• Richieste contenenti parametri di percorso file insoliti
• Sequenze di traversal del percorso che tentano di lasciare le directory del repository previste
• Richieste per file di configurazione o log di GitLab attraverso le API del repository
• Grandi quantità di richieste all’API dei commit del repository provenienti da fonti precedentemente sconosciute
• Accesso anonimo seguito da tentativi insoliti di recuperare risorse lato server
• Accesso inaspettato a credenziali, file di configurazione o segreti dell’applicazione
• Nuova attività di autenticazione utilizzando credenziali che potrebbero essere state esposte tramite GitLab
• Accesso inspiegabile a CI/CD, cloud, registro o infrastruttura di distribuzione dopo attività sospette su GitLab

WatchTowr raccomanda specificamente di rivedere il pattern dell’API dei commit del repository perché può fornire prove dirette di sonde o tentativi di sfruttamento contro l’endpoint vulnerabile.

Il patching dovrebbe anche essere combinato con un’indagine retrospettiva. La richiesta di triage forense di CISA riflette la possibilità che le organizzazioni possano essere state compromesse prima di implementare la correzione, in particolare dato quanto rapidamente sono iniziati gli attacchi dopo la divulgazione.

Se si identifica un’attività di lettura file sospetta, gli amministratori dovrebbero determinare esattamente quali file potrebbero essere stati accessibili. I segreti contenuti in file potenzialmente esposti dovrebbero essere considerati compromessi fino a prova contraria.

Le organizzazioni dovrebbero considerare di ruotare:

• Token di accesso e personali GitLab
• Token di distribuzione
• Variabili e segreti CI/CD
• Credenziali del database
• Chiavi SSH
• Credenziali cloud
• Credenziali del registro dei container
• Token API e di integrazione
• Segreti OAuth
• Credenziali di distribuzione e automazione

I team di sicurezza dovrebbero anche indagare sui sistemi a valle che si fidavano di quelle credenziali. L’aggiornamento di GitLab chiude il percorso vulnerabile di lettura dei file ma non può invalidare i segreti già ottenuti da un attaccante.

Per i sistemi ad alto rischio, i difensori dovrebbero confrontare l’attività recente dei repository, pipeline, account, runner e distribuzione con i record noti per identificare potenziali abusi successivi. Modifiche inaspettate alle pipeline, cambiamenti nei repository, token recentemente emessi o accessi insoliti all’infrastruttura di build dovrebbero essere oggetto di indagine.

Data la gravità CVSS 10.0, lo sfruttamento confermato, la riproduzione pubblica e la rapida transizione dalla divulgazione alla scansione, la rimessa in sicurezza dovrebbe essere trattata come un’emergenza per le installazioni GitLab autogestite esposte a Internet.