Il 21 ottobre 2026 GitLab ha pubblicato dei correttivi per una falla critica di GitLab, catalogata come CVE-2026-110264 e valutata 10 su 10. Può permettere a un aggressore senza account di eseguire il proprio codice sul server. Sono colpite tutte le versioni di GitLab Community Edition (CE) ed Enterprise Edition (EE) a partire dalla 7.0, uscita nel 2014. Le aziende e le amministrazioni svizzere che ospitano GitLab in proprio devono installare una versione corretta.
GitLab serve a conservare il codice sorgente di un'organizzazione e ad automatizzarne le messe in produzione. Un server compromesso mette quindi in gioco tutto il codice dell'organizzazione. Secondo il sito specializzato Inside IT, il 23 ottobre 2026 non era ancora stato osservato alcun attacco. La testata ritiene tuttavia quasi certo che la situazione cambi rapidamente.
Che cosa permette la falla di GitLab CVE-2026-110264?
La falla deriva da un overflow di interi durante la compilazione di un'espressione regolare, un modello di ricerca all'interno di un testo. Secondo la scheda pubblicata il 22 ottobre 2026 su cve.org, un'espressione regolare manipolata può provocare questo overflow. In determinate condizioni, un utente non autenticato può allora eseguire codice arbitrario sul server GitLab.
Il punteggio di 10.0 è il massimo della scala CVSS (Common Vulnerability Scoring System), nella sua versione 3.1. Il vettore pubblicato descrive un attacco condotto attraverso la rete, poco complesso, senza privilegi e senza alcuna azione da parte di un utente. Gli effetti su riservatezza, integrità e disponibilità sono tutti giudicati elevati.
Ciò che è accertato, dunque, è la gravità della falla e l'elenco delle versioni colpite. Le «condizioni» precise dell'attacco, invece, non sono state descritte nel dettaglio da GitLab. La falla è stata segnalata dal ricercatore joaxcar nell'ambito del programma di ricompense di GitLab sulla piattaforma HackerOne.
Quale versione di GitLab installare?
GitLab raccomanda a tutte le installazioni autogestite di passare immediatamente a una delle sette versioni corrette. La scelta dipende dal ramo già installato, come riassume la tabella tratta dalla nota di rilascio di GitLab.
| Ramo installato | Versione corretta da installare |
|---|---|
| 19.5 | 19.5.1 |
| 19.4 | 19.4.3 |
| 19.3 | 19.3.6 |
| 19.2 | 19.2.9 |
| 19.1 | 19.1.9 |
| 19.0 | 19.0.10 |
| 18.11 | 18.11.13 |
| Prima della 18.11 | Nessun correttivo: migrare verso un ramo corretto |
Per questa falla, GitLab ha esteso il correttivo, oltre che alle sue versioni abituali, ai rami 18.11, 19.0, 19.1 e 19.2. Secondo Inside IT, non è invece proposto alcun aggiornamento per le versioni precedenti alla 18.11.13. Un'istanza più vecchia deve quindi cambiare ramo, il che richiede una preparazione maggiore.
L'aggiornamento non è sempre indolore. GitLab avverte che contiene migrazioni del database, in particolare nelle versioni 19.4.3 e 19.3.6. Su un server singolo comporta un'interruzione, il tempo necessario perché le migrazioni si concludano. Un'installazione distribuita su più server può applicarlo senza interruzioni, seguendo la procedura adeguata.
Perché lo sfruttamento segue rapidamente un correttivo?
Un correttivo pubblicato rende pubblica la falla, ed è questo che accelera gli attacchi. Inside IT lo dice in questi termini: pubblicando i suoi correttivi, GitLab ha reso nota la falla. Da quel momento gli aggressori sanno quale software prendere di mira e quali versioni restano vulnerabili.
La nota di rilascio fornisce del resto un indizio sull'area interessata. Menziona, per ogni ramo, un correttivo nella gestione delle espressioni regolari di Ruby. GitLab mantiene riservati i dettagli tecnici di ogni falla per 90 giorni dopo il correttivo, ma la falla in sé è ormai nota.
Il recente caso di PHP mostra con quale rapidità possano evolvere le cose. Per la falla PHP PHP2Shell, Cloudflare bloccava tentativi di attacco nove ore prima della pubblicazione ufficiale, dopo la rottura dell'embargo. Nulla di simile è stato segnalato per GitLab nelle fonti consultate.
Ciò che non riguarda GitLab.com
I clienti che utilizzano GitLab online, senza un proprio server, non devono fare nulla. GitLab.com funziona già con la versione corretta. I clienti di GitLab Dedicated, l'offerta ospitata per una sola organizzazione, sono protetti se utilizzano le versioni 19.3.5-internal0 o 19.4.2-internal0, o più recenti.
Sono quindi interessate solo le installazioni autogestite: server di aziende, amministrazioni, scuole o provider di hosting. GitLab precisa che, salvo indicazione contraria, sono colpiti tutti i tipi di installazione, che si tratti del pacchetto completo, di un'installazione dal codice sorgente o di un deployment tramite chart Helm.
Altre undici falle corrette nell'occasione
Le stesse versioni correggono altre undici falle, di cui due giudicate elevate. La CVE-2026-15723, valutata 8.2, permette di prendere il controllo di un account LDAP esistente quando due impostazioni di accesso, OmniAuth SAML e il collegamento automatico LDAP, sono attivate contemporaneamente. La CVE-2026-112212, valutata 7.5, permette di avvelenare una cache condivisa per reindirizzare determinate connessioni OAuth od OIDC verso un server esterno. Le altre nove sono giudicate medie o basse.
Che cosa deve fare una PMI o un'amministrazione in Svizzera
Il primo passo consiste nel sapere chi gestisce il server GitLab e quale versione esegue. I passi successivi discendono dalle indicazioni di GitLab:
- confrontare la versione installata con la tabella e installare la versione corretta del proprio ramo;
- per una versione precedente alla 18.11, pianificare la migrazione verso un ramo corretto;
- su un server singolo, prevedere la breve interruzione dovuta alle migrazioni del database;
- se l'istanza è gestita da un fornitore, chiedergli se ha installato una delle sette versioni corrette;
- utilizzare i due rilevamenti pubblicati da GitLab per individuare tentativi di sfruttamento, denominati «Onigmo native worker crash» e «Org mode render error burst»;
- abbonarsi alle notifiche dei correttivi di GitLab, via e-mail o tramite feed RSS.
Queste azioni rientrano nelle misure di base di sicurezza informatica di una PMI, che iniziano con aggiornamenti rapidi.
Ciò che non si sa ancora
Diversi punti restano aperti nelle fonti consultate:
- le condizioni esatte che rendono possibile l'attacco non sono state pubblicate;
- il numero di istanze GitLab autogestite in Svizzera, e la quota ancora vulnerabile, non sono noti;
- al 23 ottobre 2026 non era segnalato alcuno sfruttamento, ma da allora la situazione può essere cambiata;
- nessuna delle fonti riferisce di un avviso dell'Ufficio federale della cibersicurezza (UFCS) su questa falla.
