Chi gestisce un’istanza GitLab raggiungibile da Internet stavolta ha avuto poco tempo per reagire. GitLab è stata colpita da una grave vulnerabilità ed ha pubblicato una patch il 10 settembre 2026, ma già l’11 si sono registrate scansioni attive contro la vulnerabilità appena resa pubblica, intercettate da reti honeypot distribuite. Lo stesso giorno CISA ha inserito il bug nel catalogo Known Exploited Vulnerabilities, imponendo alle agenzie federali statunitensi di correggere entro il 14 settembre. Tra l’annuncio della correzione e lo sfruttamento documentato sono passate ore, non settimane (come spesso succede), ed è proprio questo scarto temporale a rendere la vicenda interessante quanto la falla stessa.

Sappiamo tutti quanto sia essenziale GitLab e quanto sia pericolosa una vulnerabilità su questa piattaforma.

GitLab ospita il codice sorgente aziendale, orchestra le pipeline CI/CD e in molte organizzazioni rappresenta il punto da cui parte ogni deployment verso produzione. Spesso conserva anche token verso registry esterni e cluster Kubernetes. Compromettere un’istanza self-managed equivale ad ottenere un accesso privilegiato a un’intera catena che va dal commit fino al rilascio in produzione. Con oltre 30 milioni di utenti registrati e una diffusione che supera il 50% tra le aziende Fortune 100, una falla di gravità massima su questo tipo di piattaforma coinvolge rapidamente un numero enorme di organizzazioni.

La vulnerabilità, identificata come CVE-2026-85706, vive nella Repository Commits API, la parte di GitLab che espone via HTTP la possibilità di creare commit e toccare file nei repository in modo automatizzato. Per capire il problema aiuta pensare a come dovrebbe funzionare un endpoint di questo tipo: riceve un percorso di file indicato dal chiamante, lo confronta con la cartella del repository a cui ha diritto di accedere, e nega tutto ciò che esce da quel path. GitLab ammette che qui questo controllo avviene in modo scorretto: il percorso ricevuto non viene normalizzato né validato a sufficienza, e una sequenza di caratteri costruita ad hoc riesce a “risalire” fuori dalla cartella prevista fino a file arbitrari sul filesystem del server. È la stessa famiglia di errore che si vede spesso in bug più contenuti, ma qui manca anche la seconda barriera che normalmente lo renderebbe innocuo: in determinate condizioni la richiesta bypassa completamente il controllo di autenticazione. Un difetto di percorso da solo richiede quantomeno un account valido per essere sfruttato. Senza login a proteggerlo, l’endpoint diventa interrogabile da chiunque sulla rete. Questa combinazione di due assenze contemporanee spiega il punteggio CVSS pieno, 10.0, e l’intervallo di versioni interessate è ampio: dalla 18.7 alla 19.1.7, dalla 19.2.0 alla 19.2.5 e dalla 19.3.0 alla 19.3.1.

Dato che questa vulnerabilità permette di leggere qualunque file dal filesystem, attacchi sulle istanze GitLab possono restituire come risposta dei file di configurazione della macchina, credenziali salvate, chiavi SSH o riferimenti a host interni. watchTowr riferisce che il traffico sospetto osservato si concentra su richieste POST verso percorsi come /api/v4/projects/{id}/repository/commits/, con un parametro file.path che, come si vede nei log, assume valori fuori dal normale.

I nostri sistemi di honeypot basati su Krawl hanno emulato la path /api/v4/projects/1/repository/commits/ e sono riusciti a catturare il 12 settembre 2026 alle 10:20 il seguente attacco lanciato da un attore malevolo che sfrutta la vulnerabilità di GitLab:

È possibile vedere come, sottolineato in verde, si tenti un attacco dove si cerca di leggere il contenuto di /proc/self/environ ovvero il file virtuale che mostra le variabili d’ambiente del processo in esecuzione. Il tutto è stato lanciato in modalità URL encoded e su un sottodominio “.git“. Questo tipo di file è molto spesso target di attacchi di questo tipo o di Local File Inclusion. A seguito di questo attacco, molteplici campagne e variazioni dello stesso payload sono state lanciate su altri dei nostri honeypot, avendo sempre come target la CVE-2026-85706.

GitLab è stata abbastanza veloce nell’aggiornare le istanze. Durante la correzione della CVE, sono state corrette altre 17 vulnerabilità. Tra queste spicca anche CVE-2026-87719, CVSS 9.9, limitata a Enterprise Edition: una deserializzazione insicura nel meccanismo che gestisce le subscription GraphQL, sfruttabile da chiunque abbia accesso a Duo Chat, funzionalità ormai diffusa in buona parte delle installazioni aziendali. Da lì si può costruire un argomento GraphQL malevolo ed estrarre credenziali e configurazioni di Advanced Search.

I bug che sono stati risolti sono molteplici: un buffer overflow nella conversione Unicode che può portare a esecuzione di codice durante l’importazione di un progetto, un accesso indebito a variabili CI/CD protette da parte di sviluppatori che non dovrebbero vederle, cross-site scripting nel rendering delle tabelle Markdown in formato JSON, uno scoping errato delle variabili d’ambiente CI/CD, due denial-of-service nel limitatore di complessità GraphQL, oltre a un bypass del login SSO via SAML e a credenziali esposte tra le correzioni di media gravità. Ambiti diversi, API, GraphQL, gestione dei permessi sulle variabili, che tornano con una regolarità che racconta la superficie (di attacco) accumulata da una piattaforma di questo tipo negli anni, tra funzionalità AI aggiunte, API sempre più estese e livelli di permessi via via più complessi.

Ma alla fine quale è stato l’impatto?

GitLab.com e GitLab Dedicated erano già protetti lato fornitore prima ancora dell’annuncio pubblico, quindi il rischio resta concentrato sulle istanze self-managed non ancora aggiornate. Uno scanner automatico o un attacco come quello visto in precedenza può provare la CVE su migliaia di istanze in poche ore, mentre un ciclo di patch aziendale organizzato su base mensile o trimestrale è pensato per un ritmo di disclosure molto più lento di quello attuale. GitLab avvisa inoltre che alcune migrazioni del database incluse in questo aggiornamento possono causare downtime sulle installazioni a nodo singolo: applicare la patch richiede quindi una pianificazione almeno minima. Resta comunque l’azione con la priorità più alta, da completare prima di comunicare la finestra di manutenzione agli utenti, perché con un CVSS 10.0 già sotto sfruttamento attivo il rischio dell’attesa supera nettamente quello di un breve disservizio programmato.