La falla di path traversal di GitLab entra nel catalogo CISA KEV: tre giorni per applicare la patch

GitLab esorta gli amministratori delle installazioni autogestite ad applicare la patch per una vulnerabilità di gravità massima che può esporre file arbitrari tramite l’API dei commit dei repository.

Tracciata come CVE-2026-85706, la falla di path traversal interessa sia GitLab Community Edition sia Enterprise Edition. In determinate condizioni, un attaccante non autenticato può sfruttarla da remoto con una singola richiesta HTTP.

CISA ha aggiunto la vulnerabilità al catalogo Known Exploited Vulnerabilities l’11 settembre 2026. Le agenzie federali statunitensi devono completare la correzione entro il 14 settembre 2026, con una finestra insolitamente ridotta a tre giorni.

GitLab ha dichiarato di non aver confermato lo sfruttamento della vulnerabilità in attacchi reali. Tuttavia, la società di sicurezza watchTowr ha osservato attività di probing su scala Internet contro server GitLab non aggiornati. L’inserimento nel catalogo KEV significa inoltre che i difensori devono considerare il problema una minaccia attiva, non una debolezza puramente teorica.

L’accesso API non autenticato può esporre i file del server

CVE-2026-85706 è causata da un confinamento insufficiente dei percorsi e dall’assenza di controlli di autenticazione nella funzionalità dei commit dei repository esposta tramite l’API di GitLab. La vulnerabilità è classificata come CWE-22, ovvero restrizione impropria di un percorso a una directory limitata.

Un attaccante può manipolare la gestione dei percorsi dei file nell’endpoint dei commit dei repository, inducendo il server GitLab ad accedere a contenuti esterni alla directory prevista. Non sono necessari né un account valido né l’interazione dell’utente, e l’attacco descritto può essere eseguito con una sola richiesta.

Lo sfruttamento riuscito può divulgare qualsiasi file leggibile dal servizio GitLab, in base alla specifica configurazione del server. Tra i possibili obiettivi rientrano:

• File di configurazione dell’applicazione e dell’infrastruttura
• Credenziali e token di accesso
• Chiavi API e altri segreti
• Codice sorgente proprietario
• Dati dei repository
• File contenenti informazioni sui servizi connessi

Le informazioni tecniche disponibili dimostrano la possibilità di leggere file arbitrari. Non dimostrano invece che CVE-2026-85706 consenta autonomamente l’esecuzione di codice da remoto o la modifica diretta dei file del server.

La vulnerabilità ha ottenuto un punteggio CVSS 3.1 pari a 10,0 e il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Questa valutazione descrive un attacco accessibile dalla rete, di bassa complessità e che non richiede né privilegi né il coinvolgimento dell’utente. Il vettore registrato indica un impatto elevato sulla riservatezza e sull’integrità, senza impatto sulla disponibilità.

Il ricercatore “s3ntago” ha segnalato la vulnerabilità tramite il programma bug bounty di GitLab su HackerOne.

Versioni esatte interessate e release sicure a cui aggiornare

La vulnerabilità interessa GitLab CE ed EE in tre intervalli di versioni:

• Dalla versione 18.7 fino alle versioni precedenti alla 19.1.8
• Dalla versione 19.2 fino alle versioni precedenti alla 19.2.6
• Dalla versione 19.3 fino alle versioni precedenti alla 19.3.2

Gli operatori devono quindi aggiornare alla 19.1.8, alla 19.2.6 o alla 19.3.2, a seconda del ramo di release distribuito.

Alcune segnalazioni hanno descritto la correzione in termini più generici, indicandola come applicabile al ramo 19.1. Gli amministratori devono considerare la 19.1.8 come il limite corretto a partire dal quale la vulnerabilità è risolta, senza presumere che qualsiasi release 19.1 sia sicura.

L’esposizione immediata riguarda le installazioni autogestite, in particolare i server raggiungibili da Internet pubblico. GitLab.com utilizzava già una versione corretta, mentre ai clienti GitLab Dedicated è stato comunicato che non dovevano intraprendere alcuna azione.

Le organizzazioni devono comunque verificare il proprio modello di distribuzione, invece di affidarsi esclusivamente al marchio GitLab associato a un servizio interno. Le istanze self-hosted gestite da unità aziendali, team di sviluppo, filiali o fornitori esterni potrebbero non rientrare nei processi centralizzati di applicazione delle patch.

Lo status CISA aumenta la priorità della risposta

CISA ha inserito CVE-2026-85706 nel catalogo KEV l’11 settembre 2026, fissando al 14 settembre 2026 il termine per la correzione da parte delle agenzie federali.

La risposta richiesta impone alle agenzie di applicare le misure di mitigazione del fornitore, nel rispetto della BOD 26-04, “Prioritizing Security Updates Based on Risk”, e dei requisiti di CISA per il triage forense. Le agenzie che utilizzano servizi cloud devono seguire le disposizioni applicabili della BOD 26-04 oppure interromperne l’utilizzo quando non sono disponibili mitigazioni efficaci. I responsabili degli asset devono inoltre valutare l’esposizione a Internet e rispettare i requisiti di applicazione delle patch basati sul rischio previsti dalla direttiva.

È importante distinguere tra le dichiarazioni pubbliche sullo sfruttamento. GitLab non aveva identificato una compromissione confermata, mentre watchTowr aveva segnalato attività di scansione e probing, non attacchi riusciti verificati. Al tempo stesso, l’inserimento nel catalogo KEV indica che CISA ritiene la vulnerabilità conforme ai propri criteri di sfruttamento noto.

Non sono stati identificati pubblicamente attori delle minacce, campagne, organizzazioni vittime, indirizzi IP malevoli, payload, user agent o percorsi di file presi di mira. L’assenza di questi dettagli limita l’attribuzione, ma non deve ritardare la correzione.

La ricognizione su scala Internet spesso precede lo sfruttamento, una volta compresi l’endpoint e la struttura delle richieste di una vulnerabilità. In questo caso, l’assenza di autenticazione e la possibilità di eseguire l’attacco con una sola richiesta riducono il costo operativo per gli attaccanti.

Cosa devono cercare i difensori

Gli amministratori devono esaminare i log dell’applicazione GitLab e tutti i record del reverse proxy, del load balancer, del web application firewall o dell’API gateway posizionati davanti al servizio.

Il modello più rilevante è una richiesta HTTP POST indirizzata a un URI con una struttura simile a:

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

Le richieste contenenti un parametro file.path meritano ulteriori verifiche. Questa combinazione può indicare un’attività di sfruttamento, anche se le informazioni disponibili non sono sufficienti per considerare inequivocabilmente malevola ogni richiesta corrispondente.

Non sono state divulgate stringhe di payload o sequenze di traversal specifiche. Ove legalmente e operativamente possibile, i difensori devono conservare i dati completi delle richieste, inclusi timestamp, indirizzi sorgente, intestazioni, parametri, codici di risposta e dimensioni delle risposte.

Se vengono individuate richieste sospette, i responsabili della risposta agli incidenti devono determinare quali file poteva leggere l’account di servizio GitLab. L’indagine deve comprendere directory di configurazione, archivi dei repository, file di ambiente, impostazioni delle integrazioni, backup, credenziali, token e segreti utilizzati per accedere a sistemi esterni.

Quando gli elementi raccolti indicano un accesso a file arbitrari, i segreti interessati devono essere considerati esposti e ruotati. I team devono inoltre esaminare i servizi downstream raggiungibili con quelle credenziali. L’applicazione della patch chiude la vulnerabilità, ma non rende inutilizzabili i dati che un attaccante potrebbe avere già acquisito.

Una seconda falla critica interessa GitLab Enterprise Edition

Gli stessi aggiornamenti di sicurezza risolvono CVE-2026-87719, una distinta vulnerabilità di insecure deserialization in GitLab Enterprise Edition.

Questa falla richiede un utente autenticato con accesso a Duo Chat. In determinate condizioni, l’utente può fornire un argomento di sottoscrizione GraphQL appositamente predisposto, aggirare la gestione prevista della serializzazione e attivare la ricerca di oggetti sul server.

L’accesso così ottenuto può esporre le configurazioni dell’istanza Advanced Search e credenziali sensibili. A differenza di CVE-2026-85706, questa vulnerabilità richiede privilegi di basso livello e non consente un attacco anonimo.

CVE-2026-87719 ha ottenuto un punteggio CVSS 3.1 pari a 9,9 e il vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. È classificata come CWE-502, deserializzazione di dati non attendibili.

Gli intervalli interessati di Enterprise Edition sono:

• Dalla versione 18.3 fino alle versioni precedenti alla 19.1.8
• Dalla versione 19.2 fino alle versioni precedenti alla 19.2.6
• Dalla versione 19.3 fino alle versioni precedenti alla 19.3.2

CVE-2026-87719 non è presente nel catalogo CISA KEV. Le organizzazioni che utilizzano Duo Chat e Advanced Search dovrebbero comunque includerla nelle proprie verifiche, soprattutto quando analizzano attività sospette eseguite da utenti autenticati.

GitLab ha dovuto affrontare ripetute falle lato server inserite nel catalogo KEV

La nuova voce del catalogo KEV segue altre vulnerabilità di GitLab che consentivano agli attaccanti di raggiungere dati o risorse interne tramite funzionalità lato server.

CVE-2023-2825 era un’altra vulnerabilità di path traversal con punteggio CVSS pari a 10,0, limitata a GitLab CE/EE 16.0.0. Consentiva la lettura non autenticata di file quando un allegato era presente in un progetto pubblico annidato in almeno cinque gruppi.

Nel 2026 sono entrate nel catalogo KEV anche due precedenti vulnerabilità di server-side request forgery. CVE-2021-39935, che interessava l’API CI Lint, è stata aggiunta il 3 febbraio 2026, con scadenza federale fissata al 24 febbraio 2026. CVE-2021-22175, relativa a richieste webhook verso reti interne, è stata inserita il 18 febbraio 2026, con correzione richiesta entro l’11 marzo 2026.

Per CVE-2026-85706 la risposta è chiara: individuare ogni istanza autogestita, aggiornare alla release corretta del relativo ramo, esaminare il traffico API e verificare la possibilità di accesso ai dati. I sistemi esposti a Internet devono avere la precedenza.