Una vulnerabilità critica di GitLab per la lettura di file sfruttata entro un giorno dalla divulgazione della patch

Secondo i ricercatori che monitorano le attività di sfruttamento, gli autori delle minacce hanno iniziato a sondare una vulnerabilità critica di GitLab appena un giorno dopo che l’azienda aveva annunciato gli aggiornamenti di sicurezza.

La vulnerabilità, identificata come CVE-2026-85706, consente a un attaccante non autenticato di leggere file arbitrari da un server GitLab autogestito. Lo sfruttamento richiede una sola richiesta HTTP appositamente predisposta, rendendo le installazioni esposte e non aggiornate obiettivi pratici per le scansioni automatizzate.

CVE-2026-85706 ha un punteggio CVSS pari a 10 ed è già inclusa nel catalogo delle vulnerabilità note e sfruttate della Cybersecurity and Infrastructure Security Agency statunitense. CISA l’ha aggiunta l’11 settembre 2026 e ha concesso alle agenzie federali tempo fino al 14 settembre 2026 per mettere in sicurezza i sistemi interessati.

La release di GitLab associata risolve altre diciassette vulnerabilità, tra cui una seconda falla critica e sei problemi ad alta gravità. Gli amministratori dovrebbero quindi distribuire l’aggiornamento completo, invece di considerare l’incidente come una vulnerabilità di path traversal isolata.

Il path traversal senza autenticazione raggiunge i file del server

CVE-2026-85706 è una vulnerabilità di path traversal nell’API dei commit dei repository GitLab. Il confinamento inadeguato dei percorsi dei file, combinato con l’assenza di controlli di autenticazione, consente alle richieste di uscire dal percorso previsto e accedere ad altri file presenti sul server.

Non è necessario disporre di un account GitLab valido. L’attacco può essere eseguito con un’unica richiesta HTTP.

Il vettore CVSS è CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:N. Indica una vulnerabilità sfruttabile da remoto, con bassa complessità d’attacco, che non richiede privilegi né interazione dell’utente e ha un impatto elevato sulla riservatezza.

Secondo questo vettore di valutazione, la vulnerabilità non ha un impatto diretto sulla disponibilità. Tuttavia, l’accesso a file arbitrari può esporre informazioni utili per attacchi successivi. I file presenti su un host GitLab possono contenere configurazioni dell’applicazione, credenziali, token di accesso, codice sorgente, segreti per le integrazioni o dettagli sull’infrastruttura connessa.

Le conseguenze dipendono dai file accessibili e dalla configurazione di ogni installazione. Le segnalazioni pubbliche non hanno identificato i file specifici recuperati durante i tentativi di sfruttamento osservati, né hanno reso note compromissioni successive confermate riconducibili a tali tentativi.

WatchTowr ha osservato tentativi reali un giorno dopo l’annuncio delle patch da parte di GitLab e prevede un’estensione dello sfruttamento. L’intervallo ridotto lascia pochissimo tempo tra la divulgazione della vulnerabilità, il reverse engineering, le scansioni e i tentativi di compromissione.

Versioni esatte di GitLab CE ed EE interessate

La vulnerabilità interessa le installazioni autogestite di GitLab Community Edition ed Enterprise Edition nei seguenti intervalli di versione:

• GitLab CE ed EE dalla 18.7 prima della 19.1.8
• GitLab CE ed EE dalla 19.2 prima della 19.2.6
• GitLab CE ed EE dalla 19.3 prima della 19.3.2

Gli amministratori dovrebbero eseguire l’upgrade alla release corretta per il ramo installato:

• 19.1.8 o successive
• 19.2.6 o successive
• 19.3.2 o successive

Le organizzazioni che utilizzano rami precedenti o gestiti separatamente dovrebbero procurarsi la release corretta supportata dal fornitore. Non sono state rese note versioni interessate specifiche per i servizi cloud né istruzioni di mitigazione.

Le istanze autogestite esposte su Internet corrono il rischio più immediato di scansioni, ma non bisogna ignorare l’esposizione interna. Un attaccante che abbia già accesso alla rete aziendale potrebbe prendere di mira un server GitLab raggiungibile internamente utilizzando la stessa richiesta non autenticata.

I sistemi GitLab occupano inoltre una posizione sensibile negli ambienti di sviluppo. In genere si collegano a runner, piattaforme di deployment, registry, provider di identità, sistemi di ticketing e infrastrutture cloud. L’accesso ai file presenti sull’host potrebbe quindi esporre credenziali utilizzabili oltre i confini di GitLab.

Le ricerche nei log possono rivelare tentativi di sfruttamento

Gli amministratori GitLab dovrebbero esaminare i log HTTP alla ricerca di richieste POST inviate all’API dei commit dei repository:

/api/v4/projects/{id}/repository/commits/

Le richieste che contengono un parametro file.path richiedono ulteriori verifiche, perché potrebbero rappresentare tentativi di sfruttamento di CVE-2026-85706.

Questo schema, da solo, non dovrebbe essere automaticamente considerato una prova di compromissione. Gli investigatori dovrebbero correlare le richieste corrispondenti con gli indirizzi IP di origine, i timestamp, i codici di risposta, gli accessi anomali ai file, l’attività degli account e le modifiche successive ai repository o alle pipeline.

La verifica dovrebbe inoltre includere:

• Commit e modifiche ai repository in prossimità della richiesta sospetta
• Accessi alle variabili CI/CD e ai segreti dei progetti
• Definizioni delle pipeline e job avviati di recente
• Attività dei runner e operazioni di build inattese
• Deploy key, token di accesso personali o dei progetti e integrazioni
• Modifiche relative a utenti, autorizzazioni, webhook o branch protetti
• Artifact di build generati o alterati di recente
• Autenticazioni effettuate con credenziali memorizzate sull’host GitLab
• Attività negli ambienti di deployment e nei package environment a valle

Le credenziali e i segreti potenzialmente esposti dovrebbero essere ruotati. Quando non è possibile escludere una compromissione, i team dovrebbero convalidare le definizioni delle pipeline e ricostruire gli artifact sensibili a partire da stati del codice sorgente considerati affidabili.

L’applicazione della patch chiude la vulnerabilità nota, ma non rimuove un eventuale attaccante che abbia già ottenuto credenziali o modificato risorse di sviluppo. I sistemi che mostrano richieste sospette richiedono un’analisi forense, oltre all’aggiornamento.

CISA fissa al 14 settembre la scadenza per le agenzie federali

CISA ha inserito CVE-2026-85706 nel catalogo KEV l’11 settembre 2026. L’inclusione conferma che lo sfruttamento è in corso al di fuori degli ambienti di ricerca controllati e trasforma il problema da esposizione teorica a priorità operativa immediata.

Le agenzie civili federali statunitensi devono completare la correzione entro il 14 settembre 2026.

CISA impone alle organizzazioni interessate di applicare le mitigazioni del fornitore, in conformità con le indicazioni BOD 26-04 per la definizione delle priorità degli aggiornamenti di sicurezza in base al rischio. Le agenzie devono inoltre rispettare i Forensics Triage Requirements di CISA.

Per i servizi cloud, le organizzazioni devono seguire le indicazioni BOD 26-04 applicabili oppure interromperne l’utilizzo quando non sono disponibili mitigazioni efficaci. Ogni responsabile deve valutare l’esposizione dell’asset a Internet e applicare i requisiti di aggiornamento pertinenti.

Non è stata individuata alcuna soluzione alternativa in grado di offrire una protezione equivalente. L’installazione immediata della release corretta di GitLab è quindi la principale misura difensiva.

L’aggiornamento risolve un’altra vulnerabilità critica di GitLab

La stessa release di sicurezza risolve CVE-2026-87719, una vulnerabilità di insecure deserialization nel serializzatore delle sottoscrizioni GraphQL di GitLab.

La vulnerabilità ha un punteggio CVSS pari a 9,9 e il vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. A differenza di CVE-2026-85706, lo sfruttamento richiede privilegi di basso livello, ma i potenziali effetti riguardano riservatezza, integrità e disponibilità.

Un attaccante potrebbe accedere alle configurazioni dell’istanza Advanced Search e a credenziali sensibili. Le versioni 19.1.8, 19.2.6 e 19.3.2 di GitLab CE ed EE risolvono il problema.

La release risolve inoltre sei vulnerabilità ad alta gravità che possono consentire l’esecuzione di codice da remoto, l’accesso a variabili CI/CD protette, cross-site scripting o denial of service. Qui non sono disponibili dettagli sugli altri problemi corretti né su tutti gli intervalli di versione interessati.

È importante distribuire la release completa. Un sistema aggiornato soltanto per correggere il vettore del path traversal potrebbe rimanere esposto attraverso uno degli altri componenti corretti.

Lo sfruttamento rapido segue un precedente caso GitLab

L’attività più recente non è l’unico episodio recente di sfruttamento quasi immediato per GitLab. In precedenza, i ricercatori avevano osservato attacchi rapidi contro CVE-2026-19478, una vulnerabilità critica di code injection in GraphQL.

CVE-2026-19478 ha un punteggio CVSS pari a 9,4 ed è classificata come CWE-94. In determinate condizioni, un attaccante non autenticato potrebbe abusare di una direttiva GraphQL per modificare o eliminare da remoto progetti pubblici e dati degli utenti.

Gli intervalli interessati erano:

• GitLab CE ed EE dalla 18.2 prima della 18.11.11
• Dalla 19.0 prima della 19.0.8
• Dalla 19.1 prima della 19.1.6
• Dalla 19.2 prima della 19.2.4

La ricorrenza di questi episodi dimostra con quale rapidità gli attaccanti possano trasformare in strumenti operativi le vulnerabilità di GitLab, soprattutto quando sono raggiungibili senza autenticazione. Le piattaforme di sviluppo concentrano in un unico luogo codice, segreti e controlli di automazione di grande valore.

Gli amministratori dovrebbero correggere immediatamente CVE-2026-85706, conservare i log pertinenti e analizzare il traffico sospetto verso l’API dei commit dei repository. Qualsiasi evidenza di accesso ai file dovrebbe comportare la rotazione delle credenziali e una verifica più ampia di pipeline, runner, integrazioni, artifact e deployment a valle.