GitLab, vulnerabilità da 10 su 10: rischio esecuzione di codice remoto

Una vulnerabilità critica in GitLab permette potenzialmente a un aggressore remoto di eseguire codice arbitrario sul server senza autenticarsi. Il problema, identificato come CVE-2026-110264 e classificato con un punteggio CVSS di 10,0 su 10, interessa GitLab Community Edition (CE) ed Enterprise Edition (EE), comprese versioni distribuite oltre 12 anni fa. Non si tratta quindi di una falla limitata alle installazioni più recenti: il difetto risale almeno a GitLab 7.0, pubblicato nel 2014, e riguarda un componente utilizzato dal software per elaborare le espressioni regolari.

GitLab ha rilasciato il 21 ottobre un aggiornamento straordinario che corregge la vulnerabilità in 7 differenti rami del prodotto, invitando gli amministratori delle installazioni self-managed a intervenire immediatamente. La correzione arriva appena 9 giorni dopo un altro aggiornamento di sicurezza dedicato a una vulnerabilità molto simile, anch’essa valutata con il massimo punteggio possibile.

La gravità del problema dipende soprattutto dalla combinazione di tre fattori: l’accesso da remoto, l’assenza della necessità di credenziali e la possibilità di compromettere un server che spesso conserva codice sorgente, credenziali tecniche e informazioni utilizzate nei processi di sviluppo e distribuzione del software. GitLab precisa comunque che lo sfruttamento richiede determinate condizioni, senza averne ancora pubblicato i dettagli.

CVE-2026-110264: perché la nuova falla GitLab è così pericolosa

La vulnerabilità deriva da un errore integer overflow che si manifesta durante la compilazione di una particolare espressione regolare. Nel bollettino ufficiale del 21 ottobre, GitLab conferma che un utente non autenticato potrebbe, in determinate circostanze, ottenere l’esecuzione di codice da remoto (RCE) sul server che ospita l’applicazione.

Il punto vulnerabile si trova, come accennato in apertura, nel compilatore delle espressioni regolari: un’espressione opportunamente costruita può sollecitare percorsi di elaborazione che le espressioni ordinarie non raggiungono. Se uno dei calcoli supera i limiti previsti e il programma non gestisce correttamente il risultato, il processo può entrare in uno stato inatteso.

Per capire perché la vulnerabilità interessi versioni così distanti tra loro, bisogna osservare uno dei componenti alla base di GitLab. L’applicazione utilizza ampiamente Ruby, linguaggio che mette a disposizione un motore nativo per elaborare le espressioni regolari: Onigmo.

Il motore comprende codice nativo che interpreta, compila ed esegue le espressioni regolari: una debolezza nella gestione della memoria o nei calcoli interni può quindi avere conseguenze differenti rispetto a un normale errore gestito dal runtime Ruby.

Ancora una volta, le dipendenze software possono contenere difetti che sopravvivono per anni, anche quando l’applicazione che le utilizza riceve aggiornamenti frequenti. E quando il problema emerge in una libreria profondamente integrata, correggerlo richiede interventi che possono coinvolgere numerose versioni del prodotto.

Quali versioni di GitLab sono vulnerabili e quali aggiornamenti installare

GitLab ha scelto di distribuire la correzione anche su rami che normalmente non rientrerebbero nella propria politica ordinaria di manutenzione. Le release interessate comprendono GitLab 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1.

Chi utilizza GitLab 19.5 deve aggiornare almeno alla versione 19.5.1; per il ramo 19.4 la prima release corretta è la 19.4.3, mentre per il ramo 19.3 è la 19.3.6. Gli amministratori che mantengono installazioni 19.2, 19.1 e 19.0 devono rispettivamente adottare le versioni 19.2.9, 19.1.9 e 19.0.10. La correzione è disponibile anche nella 18.11.13.

Tutte le versioni di GitLab dalla 7.0 precedenti alla 18.11.13 rientrano nell’intervallo interessato dalla vulnerabilità.

La manutenzione ordinaria di GitLab copre normalmente la versione mensile corrente e le due precedenti: nel caso della falla CVE-2026-110264, vista la sua criticità, il produttore ha invece effettuato il backport della correzione anche sui rami 18.11, 19.0, 19.1 e 19.2.

Come verificare se la propria installazione GitLab è esposta

La prima operazione consiste nell’identificare con precisione la versione di GitLab in esecuzione. Gli amministratori possono verificarla attraverso le informazioni dell’istanza o ricorrere agli strumenti disponibili sul server, a seconda del metodo di installazione.

Nelle installazioni basate sui pacchetti Linux di GitLab, il comando gitlab-rake gitlab:env:info, eseguito tramite gli strumenti previsti dalla distribuzione, permette di ottenere informazioni sull’ambiente, compresa la versione dell’applicazione. Nei deployment containerizzati o Kubernetes occorre invece controllare anche il tag dell’immagine effettivamente distribuita.

È pacifico che un’istanza accessibile pubblicamente presenti una superficie di attacco differente rispetto a un sistema disponibile esclusivamente attraverso una rete privata. Tuttavia, anche una rete interna può ospitare dispositivi compromessi o utenti non attendibili; limitare l’accesso riduce l’esposizione, ma non corregge il difetto.