Alpine Linux ricostruisce GitLab dopo l’attacco a CVE-2026-97229

🛡️ Executive Summary

• Otto crash di GitLab: il 20 e 21 ottobre un aggressore ha tentato di sfruttare CVE-2026-97229. Alpine non ha trovato prove di esecuzione di codice.
• Patch mancante: l’istanza usava Ruby standard. Aggiornare GitLab a 19.3.6 non aveva corretto il runtime vulnerabile.
• Ripristino prudenziale: GitLab è stato ricostruito, le credenziali invalidate e i pacchetti Alpine verificati senza rilevare manomissioni.

Alpine Linux ha ricostruito completamente il proprio server GitLab dopo una sequenza di tentativi di sfruttamento della CVE-2026-97229, vulnerabilità critica con punteggio CVSS 10.0. Gli attacchi del 20 e 21 ottobre 2026 hanno provocato otto arresti dei processi worker e malfunzionamenti delle pipeline, senza che siano emerse prove di esecuzione arbitraria di codice. Gli amministratori, tuttavia, non disponevano di registrazioni sufficienti per escludere una compromissione e hanno scelto di ripartire da un’infrastruttura nuova, azzerando password e segreti. Il caso rivela soprattutto un problema di manutenzione: GitLab era stato aggiornato, ma la libreria Ruby vulnerabile era rimasta in esecuzione. Le verifiche sulla catena di distribuzione non hanno individuato pacchetti alterati.

L’attacco GitLab sfrutta una vulnerabilità critica nelle configurazioni CI/CD

Il rapporto ufficiale pubblicato dal progetto Alpine Linux ricostruisce un attacco contro il componente che valuta le espressioni regolari nelle configurazioni CI/CD. La CVE-2026-97229 dipende dal motore Onigmo, utilizzato da Ruby, e può consentire in determinate condizioni l’esecuzione di codice sul server attraverso un’espressione regolare appositamente costruita. GitLab aveva distribuito le correzioni il 12 ottobre, ma Alpine il giorno successivo aveva installato per errore la release 19.3.4 al posto della 19.3.5, che conteneva il rimedio. Il 20 ottobre un utente appena registrato ha cominciato a inviare configurazioni malevole, proseguendo il giorno successivo con tentativi che hanno provocato otto crash dei worker, errori 502 e job CI falliti. In quattro episodi l’aggressore è riuscito ad avanzare nelle prime fasi dello sfruttamento, senza completare quella successiva. Ha anche scaricato l’immagine container del progetto, comportamento che gli amministratori considerano compatibile con l’adattamento dell’exploit alla specifica build. L’incidente rende concreto il rischio già evidenziato dalla vulnerabilità GitLab CVE-2026-97229 nelle pipeline CI/CD, distinguendo però il tentativo documentato da un’intrusione riuscita che non è stata dimostrata.

Leggi anche: GitLab a rischio RCE, Node.js e HTTP/3 aprono nuove falle nei server

La versione 19.3.6 non elimina il problema se Ruby resta vulnerabile

Il passaggio a GitLab 19.3.6, effettuato il 22 ottobre, non aveva risolto il problema. La correzione distribuita da GitLab risiedeva infatti nelle modifiche applicate alla versione di Ruby inclusa nei pacchetti ufficiali; l’immagine personalizzata di Alpine impiegava invece Ruby standard, senza quelle patch. Il 26 ottobre gli amministratori si sono accorti che l’istanza rimaneva esposta, nonostante il numero di versione più recente del prodotto. Ruby aveva pubblicato il 23 ottobre le release correttive 3.3.13, 3.4.12 e 4.0.9, necessarie anche negli ambienti che compilano GitLab autonomamente o utilizzano container personalizzati. La distinzione è decisiva per chi amministra infrastrutture DevOps: un aggiornamento dell’applicazione non certifica l’aggiornamento delle dipendenze effettivamente eseguite. Alpine segnala inoltre un problema con la propria immagine alpinelinux/gitlab:19.3.6: quella pubblicata il 27 ottobre contiene Ruby corretto, mentre le copie scaricate prima di tale data rimangono vulnerabili. Per queste installazioni occorre riscaricare l’immagine e ricreare il container, verificando il runtime. Anche le correzioni di Ruby e Onigmo collegate alle falle GitLab mostrano perché controllare soltanto il numero di versione del servizio può produrre una falsa sensazione di sicurezza.

Nessuna prova di RCE, ma i log non consentono di escluderla

L’indagine ha individuato tentativi di exploit, non una compromissione confermata. Gli amministratori non hanno trovato file inattesi, chiavi sconosciute, processi anomali o modifiche sospette agli hook; inoltre, i controlli temporali non hanno rilevato ritardi associati all’esecuzione del codice dell’attaccante. Esiste però un limite tecnico importante: un exploit riuscito avrebbe potuto non generare crash né apparire nei normali log delle richieste web. Alcune registrazioni dei processi in background e il filesystem del vecchio container non erano più disponibili, mentre non era attivo il monitoraggio completo delle connessioni di rete in uscita. Per questo Alpine ha scelto di trattare l’istanza come potenzialmente compromessa, senza attribuire all’aggressore attività mai dimostrate. Se l’attacco fosse riuscito, l’accesso avrebbe potuto riguardare account, hash delle password, segreti della doppia autenticazione, token, variabili CI/CD e repository privati. La ricostruzione del server nasce dunque da una valutazione prudenziale del rischio residuo, non dalla scoperta di un furto di dati accertato.

Repository, builder e release Alpine superano le verifiche d’integrità

La verifica più delicata ha riguardato la supply chain del software. Gli amministratori hanno confrontato i commit del repository aports con registrazioni indipendenti dall’istanza GitLab, inclusi il clone di uno sviluppatore e i dati dei 45 builder che producono i pacchetti. Hanno poi ricondotto i pacchetti costruiti tra il 20 e il 24 ottobre ai commit verificati e controllato le release stabili 3.21.9, 3.22.7, 3.23.7 e 3.24.3 pubblicate il 21 ottobre, insieme alle immagini ISO e agli archivi minirootfs usati per i container ufficiali. Non sono emerse manomissioni nei materiali esaminati, ma il progetto ha annunciato ulteriori controlli fino alla chiusura del server, rimasto esposto fino al 27 ottobre. Un altro elemento importante è la separazione delle chiavi di firma: quelle utilizzate per autenticare pacchetti e release non erano conservate sul server GitLab. L’architettura di rilascio ha quindi offerto una possibilità di verifica indipendente, particolarmente importante per una distribuzione impiegata in ambienti containerizzati e infrastrutture di produzione.

Continua con:

Alpine Linux 3.24 e Flatpak 1.18 aggiornano desktop e sandboxing

GitLab riapre con nuove chiavi: cosa cambia per gli amministratori

La ricostruzione è iniziata il 27 ottobre e il servizio ha riaperto il 29 ottobre, utilizzando GitLab 19.3.7 e Ruby 3.3.13. Nel comunicato ufficiale sulla riapertura il progetto precisa che account, repository, issue e merge request sono stati conservati, ma la sostituzione delle chiavi segrete richiede di impostare nuovamente le password, riconfigurare la doppia autenticazione e ricreare i token e alcuni segreti utilizzati dalle integrazioni. È necessario anche verificare le nuove impronte SSH prima di accettare la chiave del server ricostruito. Alpine intende applicare le future patch critiche entro un giorno, conservare più a lungo i log e registrare le connessioni in uscita per rendere più solide le indagini successive. Per i responsabili di sistemi GitLab self-managed, anche italiani, la lezione è operativa: verificare la build, il runtime e i segreti effettivamente in uso, non limitarsi all’indicazione di versione dell’interfaccia. Per ridurre la superficie d’attacco è inoltre necessario verificare i permessi dei runner e la rotazione delle credenziali di servizio, oltre a disporre di copie indipendenti delle registrazioni di rilascio. L’incidente non dimostra un’infezione dei pacchetti Alpine, ma documenta quanto possa essere rischioso un disallineamento tra software aggiornato e dipendenze vulnerabili.