Basta un solo progetto pubblico
La CVE-2026-85706 non richiede quasi nulla a un attaccante. La falla si trova nell'API dei commit dei repository GitLab, dove un confinamento dei percorsi difettoso e l'assenza di un controllo di autenticazione permettono a un utente non autenticato di inviare una richiesta con un parametro di percorso file e leggere file arbitrari dal server, senza bisogno di accedere. Jake Knott di watchTowr ha condensato la barriera d'ingresso in una frase: "Lo sfruttamento richiede un solo requisito, deve esistere almeno un progetto pubblico." La maggior parte delle istanze GitLab self-hosted ne ha almeno una, che il gestore la consideri esposta al pubblico o meno.
La falla ha un punteggio CVSS di 10.0, il massimo consentito dalla scala, e riguarda GitLab Community ed Enterprise Edition nelle versioni dalla 18.7 alla 19.1.7, dalla 19.2 alla 19.2.5 e dalla 19.3 alla 19.3.1. Un server esposto in questo modo non si limita a far trapelare il codice sorgente. L'API dei commit è abbastanza vicina ai file di configurazione, alle definizioni delle pipeline CI/CD e ai token di deployment che una lettura riuscita può consegnare a un attaccante le credenziali per spingersi più in profondità in ciò che quell'istanza GitLab costruisce e distribuisce.
Una correzione esisteva prima della scadenza
| Data | Evento |
|---|---|
| 10 settembre | GitLab rilascia la correzione nelle versioni 19.1.8, 19.2.6 e 19.3.2 |
| 11 settembre, 06:00 UTC | La rete di honeypot di watchTowr rileva i primi tentativi di attacco reali |
| 11 settembre | La CISA aggiunge la CVE-2026-85706 al proprio catalogo delle vulnerabilità sfruttate note |
| 14 settembre | Scadenza entro cui le agenzie federali civili statunitensi devono aver corretto la falla |
Sono trascorse meno di 24 ore tra il rilascio della correzione e i primi tentativi rilevati sugli honeypot di watchTowr. La voce nel catalogo della stessa CISA è arrivata poche ore dopo. Secondo la valutazione di watchTowr, gli attaccanti avevano già decompilato e riprodotto la vulnerabilità a partire dalla patch stessa, lo stesso schema che trasforma una divulgazione in una corsa nel momento stesso in cui diventa pubblica. La scadenza della CISA vincola solo le agenzie federali civili statunitensi, non un'azienda di Monaco o Manchester, ma la tempistica di sfruttamento a cui risponde non si ferma a quel confine.
La terza falla che Servola segue da agosto
Questa non è la prima falla critica di GitLab di quest'estate: è la terza sondata attivamente nel giro di circa quattro settimane. Servola ha trattato una falla GitLab abbinata a problemi critici in Ray e nei software Apple il 18 agosto, poi una falla di code injection GraphQL in GitLab stesso, la CVE-2026-19478, il 24 agosto, un bug a cui lo stesso articolo di TheHackerNews su questa nuova falla si collega esplicitamente come precedente caso di sfruttamento avvenuto poco dopo la divulgazione. Tre CVE critiche contro una piattaforma ampiamente self-hosted in un mese non è una coincidenza da liquidare come sfortuna. È un segnale che la superficie d'attacco di GitLab e la velocità con cui ricercatori e attaccanti ormai decompilano una patch hanno superato la frequenza con cui la maggior parte dei gestori self-hosted controlla gli aggiornamenti.
Nessuna delle tre falle condivide la stessa causa. Ciò che hanno in comune è una finestra temporale compressa: ciascuna è stata sondata o sfruttata entro pochi giorni dal rilascio della relativa patch, non nel giro di settimane. Un gestore che controllava gli aggiornamenti di GitLab con cadenza mensile avrebbe mancato la finestra di sicurezza in tutti e tre i casi.
Cosa cambia per un'azienda che gestisce GitLab self-hosted
Il passo concreto è piccolo: verificate che la vostra istanza sia alla 19.1.8, 19.2.6 o 19.3.2 o successiva, poi controllate i log di accesso per richieste POST verso l'endpoint dei commit del repository con un parametro di percorso file, l'indicatore che watchTowr consiglia di monitorare. Il passo più grande è quello che previene davvero una ripetizione. La NIS2 chiede già alle organizzazioni europee di dimostrare di poter verificare che una patch abbia raggiunto ogni sistema gestito, non solo che GitLab ne abbia pubblicata una. Un'istanza self-hosted senza nessuno incaricato di sorvegliare in tempo reale il catalogo KEV della CISA o gli avvisi di sicurezza di GitLab continuerà a scoprire le falle critiche da un articolo di cronaca invece che da un avviso di monitoraggio. In Italia questo si allinea a quanto l'ACN chiede ormai come prassi minima di verifica delle patch.
Un'azienda che tratta ciascuno di questi casi come un'esercitazione antincendio isolata se la caverà bene questa volta e mancherà la prossima alla stessa velocità. Un'azienda che assegna a qualcuno la responsabilità del ritmo di aggiornamento di GitLab, così come possiede regole per il proprio firewall, smette di essere per la terza volta di fila l'ultima a scoprirlo.
Da leggere ora: Sfruttato Prima Che PaperCut Avesse una Patch | GitLab critico colpisce il self-hosted, non il SaaS
