Il 10 settembre GitLab ha pubblicato una patch release che corregge, tra le altre cose, una vulnerabilità con punteggio CVSS 10.0. Meno di ventiquattro ore dopo, alle 06:00 UTC dell'11 settembre, i sensori di watchTowr registravano le prime scansioni in rete alla ricerca di istanze vulnerabili. È la seconda falla critica di GitLab in poche settimane, dopo la code injection GraphQL CVE-2026-19478 che era stata sfruttata quasi immediatamente.

Il punto non è la novità tecnica — un path traversal non è un'invenzione del 2026 — ma dove si trova e cosa espone.

I fatti verificati

CVE-2026-85706, CVSS 3.1 pari a 10.0, è un path traversal nell'API dei commit del repository. Secondo la descrizione di GitLab, l'origine è «improper path confinement and missing authentication enforcement»: nessun confinamento del percorso e nessuna verifica dell'autenticazione sull'endpoint. Un attaccante senza credenziali può inviare una richiesta all'API dei commit e ottenere in risposta il contenuto di file arbitrari del filesystem del server.

Versioni colpite, sia Community Edition sia Enterprise Edition:

  • tutte le versioni da 18.7 fino a prima della 19.1.8;
  • tutte le versioni da 19.2 fino a prima della 19.2.6;
  • tutte le versioni da 19.3 fino a prima della 19.3.2.

La condizione di sfruttamento è una sola, ed è quella che rende la falla pericolosa su larga scala: deve esistere almeno un progetto pubblico sull'istanza. Non serve un account, non serve un invito, non serve conoscere il nome di un repository privato.

Nelle stesse release GitLab ha corretto anche CVE-2026-87719 (CVSS 9.9), una deserializzazione insicura in GitLab EE: un utente autenticato con accesso a Duo Chat può, con un argomento di subscription GraphQL costruito ad arte, aggirare la serializzazione e ottenere configurazioni dell'Advanced Search e credenziali sensibili. Questa seconda richiede autenticazione, ma in un'istanza aziendale con centinaia di sviluppatori "autenticato" non è una barriera significativa.

Al momento della pubblicazione la CVE-2026-85706 è entrata nel catalogo KEV di CISA come vulnerabilità sfruttata. Quello che è confermato con certezza è il probing di massa; la transizione allo sfruttamento indiscriminato, secondo watchTowr, è «probabilmente non lontana».

Cosa significa per le aziende italiane

GitLab self-managed è molto diffuso in Italia proprio nelle organizzazioni che hanno scelto di non mettere il codice su piattaforme SaaS estere: PA centrale e locale, software house che lavorano per il settore pubblico, banche e assicurazioni, aziende manifatturiere con reparti R&D. In molti casi l'istanza è stata installata anni fa da un team di sviluppo, non dall'IT centrale, e da allora vive di vita propria dietro un reverse proxy — spesso raggiungibile da Internet perché "i fornitori esterni devono poterci accedere".

Il rischio concreto qui non è la lettura di un file in sé. È la catena che quella lettura apre. Un server GitLab contiene, nei suoi file di configurazione e nei suoi log, il materiale con cui si costruisce un attacco alla supply chain interna:

  • i segreti di CI/CD: token di deploy, chiavi di accesso a registry di container, credenziali di cloud provider, chiavi SSH per i server di produzione;
  • il secrets.yml e le chiavi con cui GitLab cifra le variabili — chi le ottiene può decifrare l'intero database delle variabili protette;
  • i token API presenti nei log delle richieste, che permettono di autenticarsi come utenti legittimi;
  • indirettamente, il codice sorgente di tutto ciò che l'istanza ospita.

Con quelle credenziali un attaccante non deve più "entrare" da nessuna parte: può iniettare codice in una pipeline di build e far arrivare il proprio payload, firmato e legittimo, a valle — nei sistemi di produzione dell'azienda o, se l'azienda produce software per altri, nei sistemi dei suoi clienti. È esattamente lo schema che nel corso del 2026 abbiamo visto ripetersi con i pacchetti npm avvelenati e con i repository compromessi: il server di sviluppo è diventato un obiettivo di prima fascia, non un sistema "interno" di serie B.

Vale la pena aggiungere una considerazione che ai team di sviluppo sfugge spesso. La condizione «almeno un progetto pubblico» è insidiosa perché un progetto pubblico su un'istanza self-managed è quasi sempre qualcosa di innocuo — una libreria open source rilasciata dall'azienda, un repository di documentazione, un template. Nessuno lo percepisce come una superficie d'attacco. Qui lo è, ed è l'unica condizione richiesta per leggere i segreti di tutti gli altri progetti, privati inclusi.

Il quadro normativo

Per i soggetti in perimetro NIS2 un'istanza GitLab che ospita il codice dei servizi essenziali rientra a pieno titolo tra gli asset critici, e la gestione delle vulnerabilità è una delle misure minime previste dall'articolo 21. Una compromissione che porti all'alterazione delle pipeline di rilascio è ragionevolmente un incidente significativo, con l'obbligo di pre-notifica ad ACN entro 24 ore dalla conoscenza.

Sul fronte GDPR, se dall'istanza sono esfiltrabili credenziali che danno accesso a database contenenti dati personali, la valutazione del rischio non può fermarsi al perimetro GitLab: va estesa a tutto ciò che quelle credenziali aprono. È un punto che nelle notifiche al Garante viene spesso sottovalutato, con il risultato di dichiarare un impatto "nessun dato personale coinvolto" che poi si rivela falso.

Per le organizzazioni soggette a DORA, infine, un repository che alimenta i rilasci di un sistema ICT critico rientra nel registro degli asset e la gestione della patch è tracciabile e auditabile: la finestra tra divulgazione e applicazione va documentata.

Cosa fare subito

  • Aggiornare a 19.3.2, 19.2.6 o 19.1.8, a seconda del ramo in uso. Non esistono mitigazioni parziali affidabili per un path traversal pre-auth.
  • Se l'aggiornamento non è immediato, rimuovere l'istanza da Internet o metterla dietro VPN/accesso autenticato a livello di reverse proxy. Se esiste un solo progetto pubblico e non è indispensabile, renderlo privato riduce la condizione di sfruttamento.
  • Cercare tracce di sfruttamento nei log: richieste HTTP POST verso URI del tipo /api/v4/projects/{id}/repository/commits/ contenenti parametri file.Path. È l'indicatore suggerito da watchTowr; va cercato retroattivamente almeno dal 10 settembre.
  • Se si trovano richieste sospette, partire dal presupposto che i segreti siano compromessi: ruotare token CI/CD, chiavi di deploy, credenziali di registry e di cloud provider, e le chiavi SSH usate dalle pipeline. Ruotare anche la chiave di cifratura delle variabili è la scelta prudente.
  • Verificare che l'istanza non sia stata usata come ponte: controllare i log di accesso dei sistemi raggiungibili con quelle credenziali nello stesso intervallo temporale.
  • Per l'edizione Enterprise, valutare separatamente CVE-2026-87719: se Duo Chat è abilitato, la superficie riguarda tutti gli utenti autenticati.
  • A regime: censire le istanze GitLab esposte, assegnare a ciascuna un responsabile nominato e includerle nel processo di patch management con la stessa priorità dei sistemi di produzione. Un server di sviluppo senza proprietario è la premessa di quasi ogni caso di questo tipo.