Una vulnerabilità con CVSS 10.0 su GitLab può rappresentare un problema piuttosto serio per chiunque esponga un’istanza self-managed su Internet. Se poi quell’istanza gestisce repository, pipeline e processi di rilascio di una distribuzione Linux, le conseguenze potenziali diventano ancora più importanti. È il caso di Alpine Linux, che ha dovuto ricostruire la propria infrastruttura GitLab dopo aver rilevato diversi tentativi di sfruttamento di CVE-2026-97229, una vulnerabilità che consente Remote Code Execution in determinate condizioni.
Il problema è stato corretto da GitLab il 12 ottobre 2026, ma la sua diffusione non si è fermata con la pubblicazione delle patch di sicurezza. Nel frattempo, Alpine Linux aveva dovuto affrontare diversi tentativi di compromissione della propria istanza, scoprendo anche un problema nella gestione delle dipendenze che aveva reso inefficace il primo aggiornamento.
Un problema che nasce nel motore regex di Ruby.
CVE-2026-97229 interessa il compilatore di espressioni regolari utilizzato da GitLab attraverso Onigmo, il motore regex integrato in Ruby. La vulnerabilità è classificata come Integer Overflow or Wraparound (CWE-190) e deriva da un errore nei calcoli effettuati durante la compilazione di determinate espressioni regolari.
In altre parole, un integer overflow si verifica quando un’operazione aritmetica produce un risultato superiore al valore massimo rappresentabile dal tipo di dato utilizzato. Il valore può quindi tornare inaspettatamente piccolo, provocando errori nei controlli successivi e, in determinati scenari, una gestione non corretta della memoria.
Nel caso specifico, un’espressione regolare costruita appositamente può provocare questo comportamento durante la compilazione. La conseguente corruzione della memoria può essere sfruttata per arrivare all’esecuzione di codice arbitrario sul server GitLab. Il problema assume particolare rilevanza per il modo in cui GitLab utilizza le regex nelle configurazioni CI/CD. Un attaccante può inviare una configurazione contenente un’espressione appositamente costruita e raggiungere il percorso vulnerabile senza autenticazione, nelle condizioni descritte dall’advisory.
Il punteggio assegnato è il massimo possibile: CVSS 10.0. La vulnerabilità è stata segnalata dal ricercatore joaxcar attraverso il programma bug bounty di GitLab.
Quando però aggiornare non basta:
La vicenda di Alpine Linux è particolarmente interessante perché mostra come una patch apparentemente applicata possa lasciare comunque esposta un’infrastruttura. Dopo la pubblicazione delle correzioni, Alpine aveva aggiornato la propria istanza GitLab, ma utilizzava una versione che non conteneva ancora tutte le modifiche necessarie. Il punto fondamentale è che la vulnerabilità non risiede direttamente nel codice applicativo di GitLab, ma nel motore regex di Ruby. GitLab ha distribuito le correzioni attraverso i propri pacchetti e le immagini ufficiali, includendo le modifiche necessarie al componente incorporato.
Alpine, invece, utilizzava un’immagine container personalizzata contenente una versione standard di Ruby. Di conseguenza, aggiornare GitLab non comportava automaticamente l’aggiornamento del componente vulnerabile. Anche dopo il passaggio a GitLab 19.3.6, il server continuava a utilizzare un motore Onigmo privo delle correzioni. Questo dettaglio è importante per chiunque gestisca software attraverso immagini container personalizzate. Il numero di versione dell’applicazione non racconta necessariamente tutta la storia: le dipendenze incorporate, le librerie vendorizzate e i componenti compilati possono mantenere vulnerabilità già corrette upstream. La correzione upstream è arrivata dal progetto Ruby il 23 ottobre, con le versioni 3.3.13, 3.4.12 e 4.0.9. Gli aggiornamenti includono le modifiche relative a quattro vulnerabilità del compilatore regex segnalate da GitLab.
Otto crash e poi una ricostruzione completa.
Prima di individuare il problema nella propria immagine container, Alpine aveva già rilevato attività sospette sull’istanza GitLab. Un account appena registrato aveva iniziato a inviare configurazioni CI contenenti espressioni costruite per raggiungere il percorso vulnerabile. I tentativi sono proseguiti anche nei giorni successivi. Il bilancio riportato dagli sviluppatori comprende otto crash dei worker GitLab, quattro dei quali hanno consentito all’attaccante di avanzare parzialmente nell’esecuzione dell’exploit, senza però completare il passaggio successivo. Durante l’attività sospetta è stata inoltre scaricata l’immagine container utilizzata da Alpine per eseguire GitLab, probabilmente per analizzarne la configurazione e adattare l’exploit all’ambiente specifico. Le verifiche successive non hanno individuato prove concrete di un’esecuzione di codice riuscita. Non sono stati trovati file, chiavi, processi o hook sospetti e i test effettuati sui tempi di risposta non hanno mostrato comportamenti compatibili con un’exploitation completata.
Esistevano però alcune limitazioni importanti nell’analisi forense. Parte dei log dei job in background e il filesystem del vecchio container non erano più disponibili. Mancava inoltre una registrazione delle connessioni di rete in uscita, che avrebbe potuto aiutare a individuare eventuali attività successive all’exploitation. Per questo motivo Alpine ha deciso di non considerare sufficienti le evidenze raccolte per escludere una compromissione. L’istanza è stata chiusa e l’intera infrastruttura è stata ricostruita da zero, con la sostituzione delle chiavi segrete di GitLab e il reset delle password. Il servizio è tornato disponibile con GitLab 19.3.7 e Ruby 3.3.13. Gli utenti hanno dovuto riconfigurare autenticazione a due fattori, token personali e credenziali delle integrazioni.
Il rischio per la supply chain è un rischio sempre presente.
Il motivo per cui l’incidente ha richiesto tanta attenzione è legato anche al ruolo dell’istanza GitLab all’interno dell’ecosistema Alpine. La piattaforma ospita infatti i repository aports, che contengono le ricette utilizzate per costruire i pacchetti della distribuzione. Un accesso non autorizzato a questi repository avrebbe potuto consentire di modificare il codice sorgente o introdurre componenti malevoli nei pacchetti distribuiti agli utenti. In uno scenario del genere, l’impatto sarebbe potuto andare ben oltre la compromissione di un singolo server. Le verifiche di Alpine non hanno evidenziato manomissioni nei repository, nei pacchetti e nelle release analizzate, comprese quelle del 21 ottobre. Gli sviluppatori hanno confrontato i commit con copie conservate esternamente e verificato i risultati dei 45 builder utilizzati per produrre i pacchetti. Anche le chiavi utilizzate per firmare pacchetti e release sono rimaste al sicuro, perché non erano mai state conservate sul server GitLab. Una scelta architetturale che ha limitato significativamente le conseguenze potenziali dell’incidente.
La vulnerabilità entra direttamente nel catalogo KEV.
Il 29 ottobre 2026 la CISA ha inserito CVE-2026-97229 nel catalogo Known Exploited Vulnerabilities, confermando lo sfruttamento attivo della falla. Per le agenzie federali statunitensi soggette alla direttiva BOD 26-04 è stata fissata una scadenza di remediation al 1° novembre 2026. Per chi gestisce GitLab Community Edition o Enterprise Edition, le versioni corrette sono 19.2.8, 19.3.5 e 19.4.2, a seconda del ramo utilizzato. È comunque importante verificare anche la versione effettiva di Ruby e Onigmo, soprattutto in presenza di immagini personalizzate o build non standard.
GitLab ha inoltre pubblicato sei regole di rilevamento per individuare eventuali tentativi di sfruttamento nelle istanze self-managed. Alpine ha annunciato ulteriori interventi sui propri processi, tra cui l’applicazione delle patch critiche entro 24 ore, controlli sulle dipendenze incorporate nelle immagini personalizzate, conservazione più lunga dei log e monitoraggio delle connessioni in uscita.
Questa è una lezione che va oltre GitLab:
Questa vicenda dimostra quanto sia importante verificare lo stato effettivo di sicurezza di un’infrastruttura, andando oltre il semplice numero di versione dei software installati. Container personalizzati, fork, dipendenze vendorizzate e librerie compilate possono creare una distanza significativa tra la versione dichiarata di un prodotto e il suo reale stato di sicurezza.
Alpine Linux ha scelto di ricostruire l’infrastruttura perché non disponeva di elementi sufficienti per escludere una compromissione. Una decisione costosa, ma ragionevole quando il sistema coinvolto rappresenta un punto centrale della propria supply chain. La sicurezza di una piattaforma di sviluppo dipende anche da tutto ciò che gira al suo interno, comprese le dipendenze che spesso diamo per scontate.
Se gestite un’istanza GitLab, verificate immediatamente gli aggiornamenti disponibili, le dipendenze effettivamente utilizzate e l’eventuale presenza di immagini container personalizzate. Se il server è rimasto esposto durante il periodo di vulnerabilità e sono presenti indicatori di attività sospette, valutate anche un’attività di incident response. Aggiornare il software, da solo, non permette di escludere che qualcuno abbia già ottenuto accesso.
Red Team & Offensive Security Engineer
Parlo di sicurezza informatica offensive, Linux e Open Source
