GitLab CVE-2026-85706 è già sfruttata: aggiornare subito le istanze self-managed

La vulnerabilità CVE-2026-85706 richiede un intervento immediato per chi gestisce GitLab in proprio. Si tratta di una falla di path traversal con gravità massima, CVSS 3.1 10,0, che può consentire a un utente non autenticato, in determinate condizioni, di leggere file arbitrari dal server GitLab. Non è solo un rischio teorico: CISA l’ha inserita tra le vulnerabilità note per essere sfruttate, mentre i ricercatori hanno segnalato sonde contro istanze esposte su Internet poco dopo la pubblicazione delle patch. 32122

Cosa fare subito

Se un’istanza GitLab self-managed usa una versione coinvolta, va aggiornata quanto prima a una delle release corrette:

• 19.1.8 o successiva;
• 19.2.6 o successiva;
• 19.3.2 o successiva.

Sono interessate le versioni GitLab CE/EE dalla 18.7 fino a prima della 19.1.8, dalla 19.2 fino a prima della 19.2.6 e dalla 19.3 fino a prima della 19.3.2. GitLab ha pubblicato le correzioni il 10 settembre 2026. 37

CISA, l’agenzia statunitense per la cybersicurezza e la protezione delle infrastrutture, ha aggiunto CVE-2026-85706 al catalogo Known Exploited Vulnerabilities (KEV) l’11 settembre, fissando al 14 settembre la scadenza per le agenzie federali civili USA soggette all’obbligo. Il termine non si applica automaticamente alle organizzazioni private, ma segnala l’urgenza per qualsiasi installazione self-managed raggiungibile da Internet. 3

Come funziona la falla

Il problema è nell’API Repository Commits di GitLab. La causa documentata è la combinazione tra un controllo insufficiente sui percorsi forniti dall’utente e la mancata applicazione dell’autenticazione. In queste condizioni, un richiedente non autenticato potrebbe leggere file arbitrari accessibili al servizio GitLab. 3

La vulnerabilità è soprattutto un problema di divulgazione di file. Le informazioni disponibili non dimostrano che CVE-2026-85706, da sola, consenta l’esecuzione di codice da remoto. Tuttavia, la lettura arbitraria di file può esporre elementi utili per una compromissione successiva, in base alla configurazione del server: impostazioni applicative, token, chiavi SSH, credenziali del database e altri segreti leggibili dal processo GitLab. 925

Perché lo sfruttamento attivo cambia le priorità

WatchTowr ha dichiarato di aver osservato sonde reali per la vulnerabilità, comprese richieste individuate nella propria rete di honeypot l’11 settembre. Anche l’inserimento nel KEV da parte di CISA è un segnale rilevante: il catalogo identifica vulnerabilità per cui esistono evidenze di sfruttamento nel mondo reale. 222

Le notizie pubbliche confermano attività di scansione e sfruttamento, ma non identificano un unico autore, non forniscono un numero affidabile di vittime né dimostrano una catena di post-compromissione valida in ogni scenario. L’assenza di una segnalazione di violazione non va quindi interpretata come prova che un server esposto non sia stato raggiunto.

Considerare le istanze esposte come un possibile incidente sui segreti

L’aggiornamento blocca il comportamento vulnerabile, ma non annulla l’eventuale lettura di dati avvenuta in precedenza. Per un server interessato ed esposto a Internet, è opportuno preservare le evidenze e verificare prima cosa potesse leggere l’account di servizio GitLab, quindi avviare la bonifica.

Vanno esaminati e, dove necessario, ruotati in via prioritaria:

• segreti dell’applicazione e della configurazione GitLab;
• credenziali di database, Redis, object storage, registry, SMTP, servizi di directory e provider d’identità memorizzate nella configurazione;
• variabili CI/CD, deploy token, access token, token dei runner, deploy key e credenziali montate per job o integrazioni;
• chiavi cloud, credenziali del package registry, chiavi di firma e chiavi private SSH o TLS accessibili dall’host o dal processo GitLab.

La rotazione va pianificata con attenzione. La modifica dei segreti applicativi o delle impostazioni di cifratura può invalidare sessioni e interrompere impostazioni o integrazioni cifrate. Prima vanno conservati log e configurazioni rilevanti, predisposte le procedure di ripristino e poi ruotate le credenziali più rischiose in una sequenza controllata.

Ricerca degli indicatori nei log

Un primo indicatore utile è una richiesta HTTP POST al percorso dell’API Repository Commits:

/api/v4/projects/<id>/repository/commits/

Le segnalazioni raccomandano in particolare di cercare richieste che contengano il parametro file.path. Occorre analizzare i log del reverse proxy, del bilanciatore di carico, del WAF e degli accessi GitLab Rails alla ricerca di richieste non autenticate insolite, input codificati che ricordino traversal, ID progetto inattesi, fallimenti ripetuti, schemi di enumerazione o risposte di dimensioni anomale. 212426

Va inoltre verificata l’attività successiva alla possibile finestra di esposizione: token creati o utilizzati di recente, registrazioni di runner, modifiche a variabili CI/CD o definizioni delle pipeline, importazioni insolite, attività GraphQL e connessioni in uscita inattese. Le indicazioni pubblicate attorno alla release invitano anche a riesaminare commit, sottoscrizioni GraphQL, importazioni di progetti e pipeline CI/CD. 23

Un controllo dei log senza risultati non è conclusivo: la conservazione può essere limitata, il logging applicativo potrebbe non registrare i dettagli della richiesta e i dati utili potrebbero trovarsi soltanto nei sistemi proxy o WAF.

Misure temporanee se l’upgrade è in ritardo

L’aggiornamento è la correzione necessaria. Se non può essere effettuato subito in emergenza, va ridotta l’esposizione limitando l’accesso al servizio web e API GitLab a una VPN o a reti approvate. Una regola sul reverse proxy o sul WAF che restringa severamente la route Repository Commits coinvolta può ridurre il rischio nel breve periodo, ma potrebbe interrompere automazioni legittime e non sostituisce la patch.

Per ogni server interessato, la sequenza pratica è:

1. Identificare e prioritizzare le istanze self-managed raggiungibili dall’esterno.
2. Aggiornare alla 19.1.8, 19.2.6, 19.3.2 oppure a una release più recente.
3. Verificare la versione effettivamente in esecuzione dopo l’intervento.
4. Preservare e analizzare i log alla ricerca di indicatori di sfruttamento.
5. Ruotare i segreti potenzialmente esposti in funzione degli accessi del server e dell’impatto operativo.

Le altre vulnerabilità corrette nella release

Nella stessa ondata di aggiornamenti sono stati segnalati anche due problemi di GitLab Enterprise Edition:

• CVE-2026-87719 è descritta come una vulnerabilità di deserializzazione non sicura, sfruttabile con autenticazione, con CVSS 9,9; alcune segnalazioni la associano all’esposizione di configurazioni e credenziali di Advanced Search. 6
• CVE-2026-88765 è descritta come un rischio di esecuzione remota di codice con autenticazione, legato all’importazione di un export Git di progetto appositamente predisposto, con CVSS riportato di 8,5. 625

Questi difetti hanno prerequisiti ed effetti diversi da CVE-2026-85706. Per installazioni GitLab self-managed esposte, la vulnerabilità di lettura file senza autenticazione e già sfruttata deve restare la priorità assoluta per contenimento e risposta all’incidente.