GitLab ha pubblicato il 21 ottobre 2026 un rilascio di sicurezza fuori ciclo per le istanze self-managed: dodici vulnerabilità corrette, tra cui la CVE-2026-110264, con punteggio CVSS 10,0. Si tratta di un integer overflow nel compilatore di espressioni regolari che, secondo l'avviso, può essere innescato da un utente non autenticato e portare a esecuzione di codice sul server. È la seconda falla di questo tipo in nove giorni, e questo cambia il modo in cui conviene leggere la notizia.

Cosa è successo

Il problema riguarda il componente che GitLab usa per compilare le espressioni regolari, basato su Onigmo, il motore di regex di Ruby. Una regex costruita ad arte provoca un overflow di interi durante la compilazione, con conseguente corruzione della memoria. Il difetto (CWE-190) è stato segnalato dal ricercatore noto come joaxcar, lo stesso che aveva già trovato falle collegate al medesimo componente il 23 settembre e il 12 ottobre.

Le versioni interessate, sia Community sia Enterprise Edition, sono quelle dalla 7.0 fino alle release precedenti ai fix: 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1. In pratica, ogni installazione self-managed realizzata dal 2014 in poi è nel perimetro finché non viene aggiornata. GitLab.com e GitLab Dedicated risultano già protetti.

Il punto più utile da capire è il rapporto con la CVE-2026-97229, corretta il 12 ottobre con le release 19.4.2, 19.3.5 e 19.2.8. Rapid7 aveva mostrato che quella falla era sfruttabile committando in un progetto pubblico un file .gitlab-ci.yml con una regex malevola e un percorso con caratteri UTF-8, riproducendo l'esecuzione di codice su un'istanza non aggiornata. La patch di ottobre per la 97229 non copre la nuova CVE-2026-110264: stesso componente, percorso di innesco diverso. Chi aveva aggiornato il 13 ottobre e considerava chiusa la questione, quindi, è di nuovo esposto.

Sullo stato di sfruttamento: al 22 ottobre non risultano attacchi confermati, non è stato indicato un exploit pubblico e la CVE non è nel catalogo CISA KEV. GitLab non ha descritto in dettaglio le precondizioni di sfruttamento. Shadowserver segnala oltre 2.700 istanze GitLab Community Edition raggiungibili da Internet. Non ci sono workaround ufficiali: l'unica correzione è l'aggiornamento. Nella stessa release sono state corrette anche altre falle, tra cui un'acquisizione di account via collegamento automatico OmniAuth-LDAP quando sono attivi sia SAML sia LDAP (CVE-2026-15723, CVSS 8,2) e un avvelenamento della cache negli endpoint di discovery OAuth/OIDC (CVE-2026-112212, CVSS 7,5).

Cosa significa per le aziende italiane

GitLab self-managed è molto diffuso in software house, studi di sviluppo, aziende manifatturiere con reparti IT interni, università e pubbliche amministrazioni, spesso perché permette di tenere il codice "in casa". Il rischio concreto è più alto di quanto il solo punteggio suggerisca, per tre motivi.

Un server GitLab custodisce i segreti dell'intera azienda. Oltre al codice sorgente contiene variabili CI/CD, token di deploy, chiavi cloud e credenziali dei registri. Chi ottiene esecuzione di codice sul server arriva a tutto questo e, da lì, alla produzione dei clienti: è una compromissione della catena di fornitura potenziale, come abbiamo visto nel caso Meta, con codice sorgente sottratto da GitHub tramite credenziali di un dipendente. Già a settembre avevamo descritto l'altra faccia del problema, la CVE-2026-85706 che legge i segreti del server.

La finestra di patch è reale ma stretta. Con una falla ricorrente sullo stesso componente, i ricercatori e gli attaccanti hanno già motivo di confrontare le versioni corrette e ricostruire l'innesco: l'esperienza recente dice che dal rilascio alla comparsa di un exploit funzionante possono passare giorni, a volte ore. Non c'è ancora sfruttamento noto, ma aspettare conferme significa partire già in ritardo.

L'aggiornamento non è banale. Le release 19.4.3 e 19.3.6 includono migrazioni obbligatorie dello schema PostgreSQL: su installazioni a nodo singolo ciò si traduce in ore di indisponibilità. Per le PMI senza una finestra di manutenzione concordata è facile rimandare, ed è esattamente così che un'istanza resta esposta.

Sul piano normativo, per i soggetti NIS2 un server di sviluppo esposto con una CVSS 10 rientra nella gestione delle vulnerabilità e nella sicurezza della catena di fornitura, mentre un eventuale accesso ai dati personali presenti nei repository o nei sistemi collegati può configurare una violazione GDPR, con valutazione della notifica al Garante entro 72 ore. A pochi giorni dal 31 ottobre, data entro cui le misure di base NIS2 vanno rese operative per molti soggetti, avere una procedura documentata per le patch urgenti è un'evidenza concreta.

Cosa fare subito

  • Verificare la versione da Amministrazione → Panoramica o con gitlab-rake gitlab:env:info, e aggiornare alla release corretta del proprio ramo (18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 o 19.5.1). Chi è già sulla 19.4.2 o su un ramo patchato solo per la CVE-2026-97229 deve aggiornare di nuovo.
  • Pianificare il downtime per le migrazioni PostgreSQL sui rami 19.4.3 e 19.3.6; per installazioni critiche valutare un aggiornamento senza interruzioni su più nodi.
  • Ridurre l'esposizione fino all'aggiornamento: togliere l'istanza da Internet se non serve, metterla dietro VPN o reverse proxy con allow-list, disattivare la creazione di progetti pubblici e la registrazione libera degli utenti.
  • Monitorare i log per crash dei worker nativi Onigmo e raffiche di errori nel rendering dei file Org mode, i segnali citati dalle fonti.
  • Ruotare i segreti (token CI/CD, chiavi di deploy, credenziali cloud) se si sospetta anche solo un accesso anomalo, e controllare la presenza di nuovi utenti amministratori, runner o chiavi SSH non riconosciuti.
  • Documentare data e responsabile dell'intervento, per le evidenze NIS2 e per il registro delle violazioni.