La vulnerabilità di GitLab è rimasta attiva dopo l’upgrade su un server Alpine
La vulnerabilità di GitLab CVE-2026-97229 è rimasta sfruttabile sul server self-hosted di Alpine Linux anche dopo l’upgrade di GitLab, perché il container del progetto utilizzava un’installazione separata di Ruby che non aveva ricevuto la patch inclusa da GitLab. Alpine ha dichiarato che un aggressore ha inviato configurazioni appositamente create per la continuous integration, o CI, il 20 e 21 ottobre. Non ha trovato prove dell’esecuzione di codice, ma la mancanza di prove non le ha permesso di escludere una compromissione riuscita.
CVE-2026-97229 ha una valutazione di 10,0 nel Common Vulnerability Scoring System, o CVSS, il punteggio massimo di questa scala di gravità. In determinate condizioni, una regular expression malevola, cioè un modello per la ricerca di testo, presente in una configurazione CI può indurre GitLab a eseguire codice controllato dall’aggressore. Il difetto sottostante si trova in Onigmo, il motore di regular expression incluso in Ruby. GitLab utilizza Ruby per elaborare le espressioni presenti nei file CI.
GitLab ha pubblicato la correzione iniziale il 12 ottobre modificando la versione di Ruby inclusa nei propri pacchetti Linux e nelle container image ufficiali. Il 13 ottobre Alpine ha aggiornato il proprio server a GitLab 19.3.4 anziché a 19.3.5, una scelta che Alpine ha descritto come un errore. Il 20 ottobre, un account appena registrato ha iniziato a sondare il server ancora vulnerabile. Le configurazioni inviate hanno causato otto arresti anomali dei processi worker di GitLab nell’arco di due giorni. Il tentativo principale del 21 ottobre ha inoltre prodotto errori 502 e interrotto job CI. Alpine ha affermato che quattro arresti anomali indicavano che l’exploit aveva raggiunto una fase intermedia prima di fallire. L’account ha inoltre scaricato la container image di GitLab di Alpine, suggerendo che l’aggressore stesse adattando il tentativo a quella specifica build.
Alpine ha bloccato l’account il 23 ottobre. I tentativi di tornare il 25 e 26 ottobre non sono riusciti. Tuttavia, il 26 ottobre il progetto ha scoperto che l’upgrade a GitLab 19.3.6, eseguito il 22 ottobre, non aveva eliminato la vulnerabilità. La container image alpinelinux/gitlab installava separatamente la versione standard di Ruby e quindi non conteneva la versione corretta di Ruby distribuita nei pacchetti e nelle container image di GitLab. Il 27 ottobre Alpine ha limitato il servizio agli sviluppatori e ai build server, quindi lo ha ricostruito da zero. La ricostruzione si è conclusa il 28 ottobre con Ruby 3.3.13 o successivo, la sostituzione delle secret key di GitLab e il reset obbligatorio delle password. Alpine stava testando il servizio ricostruito prima di riaprirlo al pubblico.
Alpine non ha trovato file, processi, hook o credenziali inattesi e i test sui tempi di risposta non hanno mostrato i ritardi previsti dalle sue verifiche. Non ha inoltre rilevato richieste web o tramite application programming interface, o API, che inviassero informazioni private all’aggressore. Questi controlli non sono stati conclusivi. Alpine ha affermato che un tentativo riuscito avrebbe potuto non produrre né un arresto anomalo né una traccia nei web log. Alcuni log dei background job e il precedente filesystem del container non erano disponibili, mentre né Alpine né il suo hosting provider avevano registrato le connessioni in uscita. Ha quindi trattato il server come compromesso, invece di presumere che l’assenza di prove significasse che l’attacco fosse fallito.
Se si è verificata una code execution, il materiale esposto potrebbe aver incluso nomi utente, indirizzi email e IP, hash delle password, secret per la two-factor authentication, CI/CD variables, runner token, credenziali per integrazioni e webhook, repository privati, issue riservate e merge request. I personal access token erano archiviati sotto forma di hash. Alpine non ha dichiarato se abbia sostituito runner token, CI/CD variables, access token o credenziali di integrazione, oltre ad aver reimpostato le password e cambiato le secret key di GitLab.
Il server interessato ospita aports, il repository utilizzato per creare i pacchetti Alpine. Alpine ha verificato ogni modifica di aports aggiunta dal 20 al 22 ottobre confrontandola con la copia del repository di uno sviluppatore e con tutti i 45 build server, riscontri ai quali, secondo Alpine, l’aggressore non poteva accedere. Ha confermato che ogni modifica era arrivata tramite un push registrato da parte di uno sviluppatore noto e che i pacchetti prodotti dal 20 al 24 ottobre corrispondevano alla cronologia di aports pubblicata su git.alpinelinux.org. I controlli erano in corso di estensione fino al 27 ottobre. Le release esaminate includevano i file minirootfs utilizzati per le container image Docker ufficiali di Alpine. Le package signing key e le release signing key non erano mai state archiviate sul server GitLab.
Gli amministratori devono distinguere i pacchetti ufficiali di GitLab dalle installazioni che forniscono una propria copia di Ruby. Il pacchetto Linux e le container image ufficiali di GitLab devono essere aggiornati alla release più recente del rispettivo branch. Le release del 21 ottobre erano 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 e 18.11.13. GitLab indica 19.4.2, 19.3.5 e 19.2.8 come versioni che correggono CVE-2026-97229 nei rispettivi branch interessati. In origine, il bollettino indicava 19.3.4 come corretta, ma ora la contrassegna come interessata; le installazioni che utilizzano ancora 19.3.4 devono quindi passare a 19.3.6. Le release più recenti correggono anche CVE-2026-110264, un difetto separato relativo a una regular expression.
Le installazioni compilate autonomamente e le custom image che installano Ruby in modo indipendente devono aggiornare entrambi i componenti. Le release corrette di Ruby sono 3.3.13, 3.4.12 e 4.0.9 o successive. Ruby 3.2 ha raggiunto l’end of life ad aprile e non riceverà questa correzione, anche se al 29 ottobre la guida di GitLab per le installazioni compilate autonomamente lo indicava ancora come versione minima. I post di GitLab sulle patch del 12 e del 21 ottobre non invitavano gli amministratori delle installazioni compilate autonomamente ad aggiornare Ruby. Gli utenti Alpine devono eseguire nuovamente il pull di alpinelinux/gitlab:19.3.6, perché la container image pubblicata il 27 ottobre contiene Ruby 3.3.13, mentre le copie precedenti dello stesso tag e tutti i tag più vecchi rimangono vulnerabili. I pacchetti Ruby di Alpine contengono la versione 3.4.12 su Alpine 3.22, 3.23, 3.24 ed edge e la versione 3.3.13 su Alpine 3.21; l’esecuzione di apk upgrade consente di installarli.
Rapid7 ha realizzato un exploit funzionante in laboratorio e ha pubblicato proof-of-concept code il 13 ottobre. L’exploit ha eseguito comandi come utente git di GitLab su una container image ufficiale e priva di patch di GitLab 19.4.1, ma non ha funzionato contro 19.4.2. Il relativo percorso di attacco richiede che un file .gitlab-ci.yml malevolo e un path contenente caratteri UTF-8 vengano sottoposti a commit in un progetto pubblico prima della richiesta CI lint finale e non autenticata. Questa barriera potrebbe non essere presente nei sistemi in cui chiunque può registrarsi e creare progetti. Rapid7 non sa in che modo la segnalazione originale, ancora privata, eviti il passaggio di scrittura e Alpine non ha spiegato come l’aggressore abbia inviato le proprie configurazioni. CVE-2026-97229 non figurava nel catalogo Known Exploited Vulnerabilities di CISA nell’aggiornamento del 28 ottobre.
GitLab ha pubblicato sei regole Sigma di rilevamento per i server self-managed, quattro delle quali sono contrassegnate come sperimentali. Le regole cercano warning CI sospetti, richieste GraphQL ciLint, path non ASCII insolitamente lunghi e crash report di Ruby che coinvolgono Onigmo. Gli amministratori devono inoltre esaminare file temporanei, processi child di Puma o Sidekiq, connessioni in uscita, scheduled task modificati e credenziali SSH alterate. Le prove di una code execution richiedono di trattare l’host come compromesso e sostituire secret di GitLab, CI/CD variables, runner token e access token. Le restrizioni temporanee sull’accesso anonimo, sulla scrittura nei progetti pubblici o sulla route CI lint coprono soltanto il percorso dimostrato da Rapid7 e non correggono Ruby.