La risposta breve
GitLab self-managed contiene una falla di lettura file non autenticata di gravità massima — CVE-2026-85706, CVSS 10.0 — che consente a un attaccante remoto senza alcun account di leggere qualsiasi file sul server. La causa è un errato confinamento dei percorsi e l’assenza di controllo di autenticazione nell’API dei commit del repository: una singola richiesta HTTP POST a /api/v4/projects/{id}/repository/commits/ con un parametro di percorso artefatto esce dalla directory prevista e restituisce file arbitrari. Sono interessati GitLab CE ed EE dalla 18.7 alla 19.1.7, oltre a 19.2.0–19.2.5 e 19.3.0–19.3.1. Le correzioni arrivano in 19.3.2, 19.2.6 e 19.1.8.
In pratica: qualsiasi istanza GitLab self-managed raggiungibile da una rete non attendibile e con anche un solo progetto pubblico è esposta — e gli attaccanti la stanno già sondando. Aggiornate a una versione corretta come modifica d’emergenza, poi ruotate ogni segreto che l’istanza poteva contenere. Trattare il server del codice sorgente come un’infrastruttura cloud e DevOps sicura per impostazione predefinita e segmentata è la soluzione duratura dietro alla patch immediata.
Che cos’è CVE-2026-85706?
GitLab è il luogo in cui la maggior parte dei team di sviluppo custodisce i propri gioielli: codice sorgente, merge request, pipeline CI/CD e i segreti che quelle pipeline richiedono per arrivare in produzione. Il 10 settembre 2026 GitLab ha pubblicato una release di sicurezza che corregge CVE-2026-85706, una vulnerabilità critica di path traversal nell’API dei commit del repository, valutata al massimo CVSS 10.0. Interessa sia la Community Edition gratuita sia la Enterprise Edition a pagamento su un’ampia fascia di versioni recenti.
La falla risiede nell’API che serve i dati di commit del repository. A causa di un errato confinamento dei percorsi e dell’assenza di controllo di autenticazione, un attaccante può inviare un singolo POST HTTP a /api/v4/projects/{id}/repository/commits/ con un parametro di percorso che esce dal repository e punta a qualsiasi file leggibile dal processo GitLab. Nessun login, nessun token, nessuna interazione — la richiesta riceve risposta prima che l’autenticazione venga applicata. L’unico prerequisito è che sull’istanza esista almeno un progetto pubblico, cosa vera per la stragrande maggioranza delle installazioni reali. Trattandosi di infrastruttura lato server, il suo irrobustimento è una questione di DevOps e piattaforma tanto quanto applicativa.
GitLab.com, il SaaS gestito dal fornitore, è già corretto: il pericolo si concentra quindi sulle stimate oltre 20.000 istanze GitLab self-managed in esercizio nel mondo — i server on-premise e self-hosted che le aziende gestiscono in proprio. GitLab ha corretto il problema nelle release 19.3.2, 19.2.6 e 19.1.8, che impongono un corretto confinamento dei percorsi e l’autenticazione sull’endpoint dei commit.
Come una richiesta legge qualsiasi file
Il path traversal è una delle classi di bug web più antiche, e CVE-2026-85706 ne è un esempio da manuale con un raggio d’impatto moderno. Un’API dovrebbe confinare l’accesso ai file a una directory precisa — qui, i dati di un determinato repository. Quando il codice che risolve un percorso fornito dal chiamante non lo normalizza né lo confina, sequenze che risalgono l’albero delle directory consentono alla richiesta di uscire dalla cartella prevista e di riferirsi a file altrove sul disco. L’API dei commit accettava un parametro di percorso e lo usava senza confinare a sufficienza dove potesse puntare.
Ciò che trasforma un bug comune in un’emergenza CVSS 10.0 è la combinazione dei fattori. L’endpoint risponde prima che l’autenticazione venga applicata, quindi non servono credenziali. Richiede una singola richiesta POST, quindi l’attacco è banale da automatizzare su scala Internet. E gira con i privilegi del processo GitLab, che può leggere i file di log e di configurazione del server. È esattamente lì che si trova ciò che conta: stringhe di connessione al database, chiavi dell’object storage, il segreto dell’istanza usato per firmare i token e frammenti di credenziali che finiscono nei log. Leggerli, e l’attaccante non ha più bisogno del bug di lettura file — ha chiavi valide.
Non è teoria. Una rete di honeypot watchTowr ha osservato tentativi di sfruttamento in the wild a partire dalle ~06:00 UTC dell’11 settembre 2026, circa sei ore dopo la divulgazione. Lo stesso giorno la CISA ha aggiunto CVE-2026-85706 al suo catalogo Known Exploited Vulnerabilities ai sensi della Binding Operational Directive 26-04, dando alle agenzie federali civili statunitensi tempo fino al 14 settembre 2026 per rimediare. Quando una falla di gravità massima passa dall’avviso alla scansione attiva nell’arco di una mattinata, la finestra per applicare la patch con calma è già chiusa.
Cosa significa per i team software in Italia
Tolto il numero di CVE, restano tre lezioni durature. Primo, il vostro server del codice sorgente è infrastruttura di produzione, non una comodità per sviluppatori. I team accumulano autenticazione, WAF e rate limiting sulle app rivolte ai clienti, poi fanno girare un GitLab self-hosted su una rete permissiva perché «sono solo i nostri repo». Ma quella macchina custodisce le credenziali del vostro cloud e il codice che diventa produzione. Merita lo stesso modello di minaccia del vostro perimetro — e la stessa urgenza di patch.
Secondo, una lettura di file è una lettura di segreto, e una lettura di segreto è un evento di supply chain. Il motivo per cui questa falla è valutata alta quanto un’esecuzione di codice da remoto è che i file che espone contengono le chiavi di tutto ciò che sta a valle. Una volta trapelati variabili CI/CD, token di deploy o materiale di firma, un attaccante può entrare nei vostri account cloud o manomettere gli artefatti che consegnate ai clienti. Per questo la sola patch qui non basta: se l’istanza era raggiungibile, dovete presumere che i segreti siano usciti e ruotarli.
Terzo, l’esposizione di rete è il moltiplicatore, e il tempo è il nemico. La differenza tra «CVE critica corretta con calma» e «incidente» sta quasi sempre nel fatto che il servizio vulnerabile fosse raggiungibile da dove si trova l’attaccante, e nella rapidità della vostra reazione. Sapere con precisione quali servizi interni sono raggiungibili da Internet, e poterli correggere in poche ore, è il controllo a maggior rendimento su cui investire.
Cosa fare ora
- Aggiornate subito a una release corretta. Portate qualsiasi GitLab self-managed su una versione interessata — 18.7–19.1.7, 19.2.0–19.2.5 o 19.3.0–19.3.1 — a 19.3.2, 19.2.6 o 19.1.8. Trattatela come una modifica d’emergenza, non come manutenzione ordinaria.
- Ruotate i segreti presumendo l’esposizione. Se l’istanza era raggiungibile da Internet, ruotate variabili CI/CD, token di deploy e di accesso, credenziali di database e object storage, il segreto dell’istanza GitLab e qualsiasi chiave cloud memorizzata nelle pipeline. La patch ferma le letture future; non annulla ciò che è già stato prelevato.
- Togliete GitLab dalle reti non attendibili. Un server del codice sorgente dovrebbe essere raggiungibile solo da sottoreti fidate o dietro VPN o proxy zero-trust. Se l’accesso pubblico a Internet non è un requisito stringente, rimuovetelo — questo da solo neutralizza questa classe di attacco.
- Cercate segni di sfruttamento. Esaminate i log di accesso per richieste
POSTa/api/v4/projects/{id}/repository/commits/con parametri di percorso insoliti o di tipo traversal, e cercate cloni di repository inattesi o token appena creati. Conservate i log prima che ruotino. - Includete il livello DevOps nei test di sicurezza. GitLab self-hosted, registry e runner CI vengono spesso lasciati fuori ambito pur custodendo gli asset più sensibili. Includeteli nel prossimo penetration test e verificate i servizi interni adiacenti alla ricerca di percorsi pre-autenticazione simili.
Domande frequenti
Che cos’è CVE-2026-85706 in GitLab?
CVE-2026-85706 è una vulnerabilità critica di path traversal nell’API dei commit di GitLab, valutata CVSS 10.0. A causa di un errato confinamento dei percorsi e dell’assenza di autenticazione, una singola richiesta HTTP POST non autenticata a /api/v4/projects/{id}/repository/commits/ può leggere file arbitrari dal server — log e file di configurazione contenenti credenziali, segreti e token. Basta che sull’istanza esista un progetto pubblico perché l’endpoint sia raggiungibile.
Quali versioni sono interessate e quali sono le correzioni?
Sono interessate Community ed Enterprise Edition: GitLab 18.7 fino alla 19.1.7, 19.2.0 fino alla 19.2.5 e 19.3.0 fino alla 19.3.1. GitLab ha rilasciato le release corrette 19.3.2, 19.2.6 e 19.1.8. GitLab.com è già corretto, quindi l’esposizione riguarda le stimate oltre 20.000 istanze self-managed. Aggiornate subito il GitLab self-managed interessato; se non potete applicare la patch immediatamente, limitate l’accesso di rete pubblico.
CVE-2026-85706 viene sfruttata attivamente?
Sì. Reti di honeypot hanno osservato tentativi di sfruttamento dalle ~06:00 UTC dell’11 settembre 2026 — nell’arco di ore dalla divulgazione. La CISA ha aggiunto la falla al suo catalogo Known Exploited Vulnerabilities lo stesso giorno ai sensi della BOD 26-04, con scadenza al 14 settembre 2026 per le agenzie federali civili statunitensi. Presumete una scansione opportunistica di qualsiasi istanza esposta.
Abbiamo applicato la patch — abbiamo finito?
Non necessariamente. Una lettura file non autenticata significa che i segreti potrebbero essere stati esfiltrati prima dell’aggiornamento. Dopo la patch, presumete la compromissione su qualsiasi istanza raggiungibile da Internet e ruotate variabili CI/CD, token di deploy e di accesso, credenziali di database e object storage, il segreto dell’istanza GitLab e le chiavi cloud. Esaminate i log di accesso dell’API dei commit alla ricerca di parametri di percorso sospetti e di cloni o token inattesi.
Perché una falla di lettura file è valutata CVSS 10.0?
Il vettore CVSS è raggiungibile via rete, a bassa complessità, senza privilegi né interazione, con alto impatto sulla riservatezza e conseguenze su integrità e disponibilità. Su un server GitLab, i file leggibili includono credenziali e il segreto dell’istanza — chiavi che consentono a un attaccante di spostarsi nel vostro cloud, avvelenare la pipeline o iniettare codice malevolo. Accesso banale più impatto a valle catastrofico determinano il punteggio massimo.
Fonti
The Hacker News — GitLab CVSS 10 File-Read Flaw Draws In-the-Wild Probes After Disclosure
Forkast — GitLab’s CVSS 10 Commits-API Flaw Hits Active Exploitation Within Hours
CISA — Known Exploited Vulnerabilities Catalog