GitLab CVE-2026-110264: anche LDAP injection e request smuggling

Il 22 ottobre ARX News ha trattato la CVE-2026-110264 di GitLab Community Edition (CE) ed Enterprise Edition (EE), l’integer overflow nel compilatore delle espressioni regolari con punteggio CVSS 10, sulla base degli avvisi del CERT-EU e del NCSC-NL. Nelle ore successive hanno pubblicato i loro avvisi la KISA/KrCERT coreana, la CSA di Singapore (SingCERT) e l’INCIBE-CERT spagnolo; ne hanno scritto anche The Hacker News e heise Security. Di seguito le novità che contano per chi gestisce istanze GitLab self-managed.

Cosa confermano i nuovi avvisi

Le versioni colpite e quelle corrette coincidono in tutte le fonti: GitLab CE ed EE dalla 7.0 in poi, con prime versioni non colpite 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1. È il motivo del titolo di The Hacker News, che parla di dodici anni di release coinvolte.

Secondo SingCERT il punteggio è 10 su 10 in CVSS v3.1: un attaccante non autenticato che sfrutta la vulnerabilità può eseguire codice arbitrario e arrivare alla compromissione del sistema. L’avviso chiede di aggiornare immediatamente.

L’INCIBE-CERT aggiunge due precisazioni:

• l’overflow avviene durante la compilazione di un’espressione regolare costruita ad arte e permette l’esecuzione di codice senza autenticazione «in determinate condizioni», che l’avviso non descrive;
• nella sua tabella la vulnerabilità risulta non sfruttata. Nessuna delle altre fonti segnala attacchi in corso.

Le fonti non dicono se la CVE-2026-110264 sia collegata alla CVE-2026-97229 corretta a inizio ottobre, anch’essa un integer overflow nel compilatore delle espressioni regolari.

Le altre vulnerabilità del rilascio

Il CERT-EU contava, oltre alla vulnerabilità critica, 2 vulnerabilità di gravità alta, 5 medie e 4 basse, senza identificativi. L’avviso della KISA ne nomina due:

• CVE-2026-15723, LDAP injection in GitLab CE/EE: colpite le versioni dalla 10.1 precedenti alla 19.3.6, la 19.4 precedente alla 19.4.3 e la 19.5 precedente alla 19.5.1;
• CVE-2026-112212, HTTP request/response smuggling: colpite le versioni dalla 18.3 precedenti alla 19.3.6, la 19.4 precedente alla 19.4.3 e la 19.5 precedente alla 19.5.1.

La KISA non indica la gravità di queste due vulnerabilità né le condizioni di sfruttamento. L’INCIBE-CERT, dal canto suo, scrive che il rilascio corregge anche vulnerabilità di gravità alta di autenticazione e di cache poisoning negli endpoint di discovery OAuth/OIDC, senza indicarne gli identificativi. Le fonti non permettono di dire se si tratti delle stesse vulnerabilità elencate dalla KISA.

Un punto pratico: per queste due CVE la tabella della KISA riporta versioni corrette solo per i rami 19.3, 19.4 e 19.5. Per i rami 18.11, 19.0, 19.1 e 19.2, che per la CVE-2026-110264 hanno una versione corretta propria, la KISA non indica una correzione. Le altre fonti non entrano nel dettaglio: va verificato nel bollettino di GitLab della patch release 19.5.1.

Nello stesso avviso la KISA riprende anche due vulnerabilità della patch release 19.4.1, un integer overflow (CVE-2026-93577) e un double free (CVE-2026-89078), corrette nelle versioni 19.2.7, 19.3.3 e 19.4.1. Chi ha già installato le versioni indicate negli articoli di ottobre le ha già corrette.

GitLab.com e GitLab Dedicated

Secondo l’INCIBE-CERT, che riporta le indicazioni del produttore, GitLab.com usa già una versione corretta. Le istanze GitLab Dedicated con la 19.3.5-internal0, la 19.4.2-internal0 o successive includono già la correzione. L’intervento riguarda quindi soprattutto le installazioni self-managed.

Impatto per le aziende europee e italiane

Per la CVE-2026-110264 restano valide le priorità già indicate: un server GitLab custodisce codice sorgente, pipeline e credenziali, e l’intervallo colpito comprende in pratica ogni installazione non aggiornata alle versioni del 21 ottobre.

Le due CVE identificate dalla KISA riguardano funzioni comuni nelle installazioni aziendali: l’integrazione con le directory LDAP e il traffico HTTP che attraversa proxy e bilanciatori davanti a GitLab. Le fonti non dicono quali configurazioni siano esposte, quindi conviene non dare per scontato di esserne fuori.

Per i soggetti che rientrano nella NIS2 vale quanto già scritto: gestione delle vulnerabilità, sicurezza della catena di fornitura del software e, in caso di incidente significativo, notifica allo CSIRT Italia dell’ACN.

Cosa fare subito

1. Aggiorna ogni istanza self-managed almeno alla prima versione non colpita del suo ramo (18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 o 19.5.1), partendo da quelle esposte su Internet.
2. Preferisci i rami 19.3, 19.4 o 19.5: sono gli unici per cui la KISA indica corrette anche la CVE-2026-15723 e la CVE-2026-112212. Se resti su un ramo precedente, controlla nel bollettino della 19.5.1 se le due correzioni sono incluse.
3. GitLab Dedicated: verifica che l’istanza sia almeno alla 19.3.5-internal0 o alla 19.4.2-internal0.
4. Rilevamento: applica ai registri le regole di rilevamento pubblicate da GitLab, già descritte nell’articolo del 22 ottobre. Nessuna fonte riporta indicatori di compromissione.
5. Se trovi attività sospetta: considera esposto il server, sostituisci i segreti usati dalle pipeline e dalle integrazioni, comprese le credenziali di servizio LDAP, e valuta gli obblighi di notifica.

Come aiuta ARXDOME

ARX Expose mostra quali servizi la tua azienda espone su Internet, quali prodotti vi sono riconosciuti e quali hanno vulnerabilità note: aiuta a scoprire se un’istanza GitLab è raggiungibile da fuori. ARX Shield elenca le vulnerabilità aperte sulle macchine monitorate. ARX Sentry raccoglie log ed eventi dei server su cui è installato l’agent e controlla l’integrità dei file nelle cartelle stabilite. Con ARX Horizon puoi consultare dal portale i dettagli delle vulnerabilità.

Ultimo aggiornamento: 22 ottobre 2026