CVE-2026-85706: falla critica in GitLab consente di rubare file senza credenziali

CVE-2026-85706: falla critica in GitLab consente di rubare file senza credenziali

In breve

GitLab ha confermato una vulnerabilità critica (CVE-2026-85706, CVSS 10.0) che consente a un attaccante senza credenziali di leggere file arbitrari dal server [1]. È inclusa nel catalogo CISA KEV delle vulnerabilità sfruttate attivamente [2]. Colpisce le istanze GitLab Community e Enterprise Edition [1]. Se la tua azienda usa GitLab, la priorità di oggi è identificare la versione installata e applicare la patch corrispondente senza indugio.

Cos'è e perché è importante

La vulnerabilità risiede nell'API dei commit dei repository di GitLab. Secondo la descrizione ufficiale, un difetto di confinamento dei percorsi ("path confinement") combinato con l'assenza di un controllo di autenticazione consente a un utente non autenticato di accedere a file arbitrari del server tramite tecniche di path traversal [1]. Il NVD l'ha classificata con gravità critica e punteggio CVSS 10.0, il massimo possibile [1], il che riflette il fatto che può essere sfruttata da remoto, senza privilegi né interazione dell'utente, e con un impatto potenzialmente totale sulla riservatezza dei dati.

Il team di intelligence di OCIRIA ha catalogato questa vulnerabilità come "Path traversal / accesso a file" e sottolinea che, non richiedendo autenticazione, qualsiasi istanza di GitLab esposta a internet è un bersaglio diretto: codice sorgente, file di configurazione con segreti, variabili d'ambiente o credenziali memorizzate nel repository potrebbero essere esposti senza lasciare traccia di accesso autenticato.

Il fatto che la vulnerabilità figuri nel catalogo CISA KEV è un dato rilevante: significa che esiste evidenza di sfruttamento attivo nel mondo reale, non solo un rischio teorico [2].

Chi è interessato

Riguarda le organizzazioni che gestiscono istanze proprie (self-managed) di GitLab Community Edition (CE) o Enterprise Edition (EE) [1]. Secondo la descrizione ufficiale del produttore, l'intervallo di versioni interessate va dalla serie 18.7 fino a versioni specifiche delle serie 19.0, 19.1, 19.2 e 19.3, ciascuna con la relativa versione corretta [1]. Data l'ampiezza dell'intervallo, qualsiasi team di sviluppo, DevOps o piattaforma che mantenga GitLab on-premise o su infrastruttura propria deve considerarsi potenzialmente esposto fino a verificare la propria versione specifica.

Le organizzazioni che usano GitLab.com (SaaS) gestito direttamente da GitLab ricevono solitamente le patch in modo centralizzato, ma conviene confermarlo con il team responsabile di quell'account in caso di dubbi sul modello di distribuzione.

Come sapere se sei vulnerabile

• Identifica la versione esatta di GitLab CE/EE che hai distribuito (visibile nel pannello di amministrazione o nell'endpoint /help).
• Confronta quella versione con gli intervalli interessati indicati dal produttore [1]: 18.7–18.11.12, 19.0–19.0.9, 19.1–19.1.8, 19.2–19.2.6 e 19.3–19.3.2.
• Verifica se la tua istanza di GitLab è accessibile da internet senza restrizioni di rete (VPN, IP allowlisting), poiché lo sfruttamento non richiede autenticazione.
• Come parte della tua igiene di sicurezza generale, è opportuno mappare quali asset e servizi della tua organizzazione sono esposti a internet; il radar di superficie di OCIRIA è pensato proprio per rilevare questo tipo di esposizione in modo continuo.

Come proteggersi

1. Aggiorna GitLab immediatamente alla prima versione corretta del tuo ramo (18.11.12, 19.0.9, 19.1.8, 19.2.6 o 19.3.2, a seconda dei casi) [1].

2. Limita l'accesso di rete all'istanza mentre completi l'aggiornamento: restringi l'accesso a IP di fiducia o VPN aziendale.

3. Controlla i log di accesso all'API dei commit durante il periodo in cui la tua istanza era su una versione vulnerabile, cercando pattern di path traversal o accessi anomali senza autenticazione.

4. Ruota credenziali e segreti che potrebbero essere memorizzati in repository o file di configurazione accessibili, come misura precauzionale in caso di possibile esposizione.

5. Dai priorità a questa patch rispetto ad altre in sospeso: la combinazione di CVSS 10.0 e presenza nel CISA KEV indica un rischio massimo e uno sfruttamento noto [1][2].

FAQ

Devo essere autenticato per essere attaccato? No. La vulnerabilità consente l'accesso a un attaccante senza credenziali, il che la rende particolarmente pericolosa [1].

Ci sono evidenze di uno sfruttamento attivo? Sì, la vulnerabilità è inclusa nel catalogo CISA KEV, che raccoglie vulnerabilità con sfruttamento attivo confermato [2].

Riguarda anche GitLab.com? La descrizione ufficiale si riferisce alle istanze GitLab CE/EE; se usi GitLab.com come servizio gestito, conferma con il tuo fornitore lo stato della patch.

Basta aggiornare o devo fare altro? Aggiornare è il passo indispensabile, ma dato il rischio di esposizione di file durante il periodo vulnerabile, controllare i log e ruotare le credenziali sensibili è una precauzione ragionevole.

Fonti

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-85706
• [2] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json