Gli aggressori stanno già sfruttando CVE-2026-97229, una vulnerabilità critica che può consentire di eseguire codice sui server GitLab. L’Agenzia per la sicurezza informatica e delle infrastrutture degli Stati Uniti (CISA) ha confermato lo sfruttamento attivo il 29 ottobre e ha aggiunto la falla al proprio catalogo delle vulnerabilità note e sfruttate.
Il problema riguarda il compilatore di espressioni regolari utilizzato per elaborare le configurazioni CI/CD. GitLab ha pubblicato le correzioni il 12 ottobre, ma il caso di Alpine Linux mostra che rilevare un tentativo di attacco non equivale a confermare un’intrusione: l’organizzazione ha trovato segnali preoccupanti nella propria istanza, ma non è riuscita a determinare se l’aggressore fosse arrivato a eseguire codice.
Cosa consente la falla e quali versioni sono state corrette
Identificata come CVE-2026-97229, la falla deriva da un overflow di interi nel compilatore di espressioni regolari CI/CD. Un’espressione appositamente predisposta all’interno di una configurazione di pipeline può, in determinate condizioni, aggirare la convalida e portare all’esecuzione di codice arbitrario sul server. GitLab ha descritto il problema come una possibile esecuzione da parte di un utente non autenticato.
Rapid7, che ha riprodotto la vulnerabilità, precisa una condizione rilevante per questo scenario: l’aggressore deve poter inserire una configurazione CI/CD dannosa in un repository prima di attivare la falla. In un’istanza autogestita che consenta ai nuovi utenti di registrarsi e creare progetti pubblici, questa possibilità può essere alla portata di un account ordinario. Rapid7 ha confermato la catena nell’immagine ufficiale di GitLab CE 19.4.1 e afferma che lo stesso input non ha eseguito codice nell’immagine corretta 19.4.2.
GitLab ha rilasciato le versioni 19.4.2, 19.3.5 e 19.2.8 per Community Edition ed Enterprise Edition. Sono le versioni corrette per i rispettivi rami: le installazioni autogestite che eseguono versioni precedenti all’interno di questi rami devono essere aggiornate. GitLab.com è già stato corretto e, secondo Rapid7 e la documentazione di GitLab, i clienti di GitLab Dedicated non devono intervenire.
CISA ha ordinato alle agenzie federali statunitensi di mettere in sicurezza i propri server entro domenica, in conformità alla direttiva BOD 26-04. Sebbene la scadenza si applichi agli enti federali, l’agenzia ha raccomandato anche ai team del settore privato di dare priorità all’aggiornamento. GitLab ha inoltre pubblicato rilevamenti delle minacce per i clienti con istanze autogestite.
Alpine ha rilevato tentativi e ricostruito la propria istanza
Alpine Linux ha riferito che un aggressore ha testato la vulnerabilità contro il suo server GitLab il 20 e il 21 ottobre, dopo la pubblicazione della patch da parte di GitLab. L’istanza di Alpine utilizzava ancora GitLab 19.3.4. Secondo la sua analisi, un account appena registrato ha inviato configurazioni CI/CD manipolate che hanno causato otto arresti anomali dei processi di lavoro; in quattro casi, l’aggressore ha portato avanti parzialmente l’exploit, ma non ha completato il passaggio successivo.
L’aggressore ha anche scaricato l’immagine del container GitLab di Alpine, un indizio che potrebbe aver adattato l’exploit a quella specifica build. Alpine ha dichiarato di non aver trovato prove dell’esecuzione di codice, ma di non aver potuto nemmeno escluderla. Poiché i log disponibili non permettevano di escludere questa possibilità, ha trattato il server come compromesso e lo ha ricostruito da zero.
L’organizzazione ha verificato che il repository aports, i pacchetti e i rilasci del 21 ottobre non erano stati alterati. Ha inoltre segnalato che le chiavi di firma dei pacchetti e dei rilasci non erano conservate sul server GitLab. Dopo la chiusura e la ricostruzione, la sua istanza è tornata online il 29 ottobre con GitLab 19.3.7.
L’incidente ha messo in luce un altro aspetto tecnico: Alpine ha spiegato che, nel suo caso, aggiornare GitLab non è bastato. La correzione dipende anche da una patch a Ruby inclusa da GitLab nei suoi pacchetti ufficiali; l’immagine di Alpine utilizzava una versione standard di Ruby che non la includeva. L’organizzazione ha indicato che chi distribuisce GitLab con una versione propria di Ruby deve aggiornare anche Ruby a una versione corretta: 3.3.13, 3.4.12 o 4.0.9, o successiva.
Durante la chiusura, Alpine ha reimpostato le password e sostituito le chiavi segrete di GitLab. Ha inoltre annunciato che applicherà le patch critiche di GitLab entro un giorno, verificherà se ogni rilascio richiede l’aggiornamento di Ruby o di altri componenti e amplierà la registrazione delle connessioni in uscita e al database. Per le istanze autogestite che non possono ancora essere aggiornate, Rapid7 cita come misure temporanee la limitazione dell’accesso anonimo ai progetti pubblici e il divieto per gli utenti non attendibili di creare o modificare progetti pubblici; queste misure riducono l’esposizione alla modalità d’attacco dimostrata, ma non correggono il compilatore vulnerabile.
Fonti: BleepingComputer, Rapid7, Alpine Linux, Documentazione GitLab
