GitLab CVE-2026-97229: esecuzione di codice con CVSS 10 dalle regex della CI/CD, ora sfruttata e in KEV

La CISA ha inserito il 29 ottobre 2026 nel catalogo KEV la CVE-2026-97229 di GitLab Community Edition ed Enterprise Edition, confermandone lo sfruttamento attivo; il giorno dopo ACN ha aggiornato il proprio alert del 12 ottobre per lo sfruttamento rilevato. La falla, valutata dal vendor con CVSS v3.1 pari a 10.0, è un integer overflow nel compilatore delle espressioni regolari usate nelle configurazioni delle pipeline CI/CD: una regex costruita ad arte porta all'esecuzione di codice arbitrario sul server GitLab. L'ha segnalata il ricercatore noto come joaxcar tramite il programma di bug bounty di GitLab, che l'ha corretta il 12 ottobre con le versioni 19.4.2, 19.3.5 e 19.2.8. Il vendor la descrive come sfruttabile da un utente non autenticato. Rapid7, che il 13 ottobre ha riprodotto l'esecuzione di codice su un'immagine ufficiale non aggiornata e pubblicato una prova di concetto, ha precisato che all'attaccante serve prima poter caricare un file di configurazione .gitlab-ci.yml malevolo in un progetto pubblico: un requisito che però un account qualsiasi soddisfa da solo dove l'istanza consente la registrazione libera e la creazione di progetti pubblici.

Il meccanismo spiega anche perché la correzione non è sempre dove ci si aspetta. Secondo l'analisi di Rapid7, la regex supera i controlli di GitLab in una forma compatta e viene poi ricompilata da Onigmo, il motore di espressioni regolari integrato in Ruby, quando è valutata su un percorso del repository con caratteri UTF-8; è in questa seconda compilazione che il calcolo della dimensione del programma va in overflow, fino all'esecuzione di un comando di sistema con l'utente git di GitLab. Il bug sta quindi in Ruby, e la patch di GitLab consiste in modifiche al Ruby che il vendor distribuisce nei propri pacchetti e nelle proprie immagini container. Lo ha imparato a sue spese Alpine Linux: il 20 e 21 ottobre un account appena registrato ha inviato configurazioni CI costruite ad arte all'istanza GitLab del progetto, facendo andare in crash i processi otto volte, in quattro casi con l'exploit arrivato a metà strada. L'istanza era ferma alla 19.3.4, installata per errore al posto della 19.3.5, e l'aggiornamento alla 19.3.6 del 22 ottobre non l'ha protetta, perché l'immagine di Alpine usava il Ruby standard, corretto solo il 23 ottobre. Alpine non ha trovato prove che l'attaccante abbia eseguito codice, ma non può escluderlo: ha ricostruito il server da zero, azzerato password, secondo fattore e token, e chiesto ai manutentori di sostituire i valori delle variabili CI/CD, dandoli per potenzialmente esposti. Pacchetti e release della distribuzione, verificati su registri esterni a GitLab, risultano integri.

La scadenza di remediation fissata dalla CISA per le agenzie federali statunitensi, tre giorni in base alla direttiva BOD 26-04, è il 1° novembre 2026: un'indicazione di priorità che vale per chiunque esponga un GitLab in proprio. Fra la patch e i primi tentativi documentati è passata una settimana. Era andata ancora più in fretta con la falla nell'API dei commit di GitLab, sfruttata il giorno dopo la divulgazione, come avevamo scritto in un nostro precedente alert del 14 settembre sulla CVE-2026-85706 di GitLab. E lo stesso ricercatore ha segnalato una seconda falla gemella, la CVE-2026-110264, sempre con CVSS 10 e sempre nel compilatore delle regex, che GitLab ha corretto il 21 ottobre: le versioni del 12 ottobre chiudono la prima ma non la seconda, quindi conviene puntare direttamente alle release più recenti. Un dettaglio sul ramo 19.3: la versione correttiva indicata da GitLab è la 19.3.5, e la 19.3.4 va considerata vulnerabile, come mostra il caso di Alpine.

A doversene preoccupare è chi gestisce un'istanza GitLab CE o EE in proprio, sia installata dai pacchetti ufficiali sia in container: software house, università ed enti di ricerca, amministrazioni con sviluppo interno, comunità open source. Il rischio è massimo sulle istanze raggiungibili da Internet che consentono la registrazione libera e la creazione di progetti pubblici, dove l'attaccante si procura da solo i requisiti, come è successo ad Alpine. Chi compila GitLab da sorgente o lo esegue in immagini container proprie deve aggiornare anche Ruby, perché l'aggiornamento di GitLab da solo non basta. Non devono intervenire gli utenti di GitLab.com e di GitLab Dedicated, già aggiornati dal vendor.

• Versioni affette: GitLab CE/EE dalla 19.2 alla 19.2.7, dalla 19.3 alla 19.3.4 e dalla 19.4 alla 19.4.1 per la CVE-2026-97229; la gemella CVE-2026-110264 riguarda tutte le versioni dalla 7.0 precedenti alle 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 e 19.5.1. Sono esposte anche le installazioni con Ruby proprio precedente alle versioni 3.3.13, 3.4.12 e 4.0.9.
• Azione raccomandata: aggiornare subito all'ultima patch del proprio ramo, e comunque almeno alla 19.5.1, alla 19.4.3, alla 19.3.6 o alla 19.2.9, che correggono entrambe le falle; per le installazioni da sorgente o in immagini container proprie aggiornare anche Ruby alla 3.3.13, alla 3.4.12 o alla 4.0.9 o successive; fino all'aggiornamento disattivare la registrazione libera, limitare l'accesso anonimo ai progetti pubblici e impedire a utenti non fidati di crearli o di scriverci; usare le sei regole di rilevamento pubblicate da GitLab per i tentativi di sfruttamento e cercare nei log crash ripetuti dei processi worker e account registrati di recente che hanno caricato configurazioni CI; se l'istanza è rimasta esposta senza patch, valutare un'analisi di compromissione e la sostituzione di token, chiavi dei runner e valori delle variabili CI/CD.

Fonti: ACN, GitLab, CISA, Rapid7, Alpine Linux, BleepingComputer