La falla CVSS 10 di GitLab rende la CI/CD un sistema di produzione

Un server GitLab non serve soltanto agli sviluppatori per discutere del codice. Può decidere che cosa viene compilato, quali credenziali sono disponibili per una pipeline e che cosa alla fine arriva in produzione. Ecco perché una vulnerabilità con punteggio CVSS 10 nei suoi meccanismi CI/CD dovrebbe essere trattata meno come una normale attività di manutenzione e più come un potenziale incidente di supply chain pronto a verificarsi.

Il 12 ottobre 2026 GitLab ha rilasciato aggiornamenti di sicurezza per Community Edition ed Enterprise Edition, comprese le correzioni per CVE-2026-97229. Come riporta Rapid7, la falla ha ricevuto un punteggio CVSSv3.1 di 10,0 e, in determinate condizioni, poteva consentire l’esecuzione di codice da remoto senza autenticazione. Le versioni corrette di GitLab includevano la 19.4.2, la 19.3.5 e la 19.2.8.

Il problema è legato a una validazione insufficiente nel compilatore delle espressioni regolari della CI/CD. Un’espressione appositamente costruita in una configurazione di pipeline malevola, combinata con un percorso del repository creato ad arte, poteva eseguire comandi arbitrari su un server vulnerabile. Le condizioni necessarie allo sfruttamento sono importanti e, secondo le informazioni disponibili al 13 ottobre, non risultavano casi confermati di sfruttamento di questa specifica falla. Ma gli elementi restano preoccupanti: bassa complessità dell’attacco, nessun requisito di autenticazione e nessuna interazione dell’utente.

La parte pericolosa non è il server, ma ciò che il server può autorizzare

L’esecuzione di codice da remoto su un’applicazione isolata è grave. L’esecuzione di codice da remoto su un sistema collegato al codice sorgente, ai runner, alle credenziali di distribuzione, agli account cloud e all’infrastruttura di produzione è un problema di tutt’altra categoria.

Questa distinzione è la lezione centrale. La compromissione di un’istanza GitLab non significa automaticamente che un attaccante controlli tutte le applicazioni distribuite da un’organizzazione. Ma può avvicinarlo ai meccanismi che creano e distribuiscono quelle applicazioni. Da quel momento, il rischio non riguarda soltanto il furto del codice sorgente. Un attore malevolo potrebbe riuscire a manipolare la logica delle pipeline, ispezionare i segreti disponibili ai job o usare l’ambiente di sviluppo come ponte verso i sistemi collegati.

Ecco perché definire GitLab una “piattaforma di collaborazione” ne riduce il ruolo operativo. La sua interfaccia visibile comprende repository, merge request e discussioni sui progetti. La sua importanza per la sicurezza risiede invece nelle relazioni di fiducia invisibili che vi stanno dietro. Nel momento in cui una piattaforma può determinare la compilazione o la distribuzione del software, la sua disponibilità e la sua integrità meritano un’attenzione da infrastruttura di produzione.

La storia recente dimostra che “applica la patch e dimenticatene” è una pessima strategia

CVE-2026-97229 non è l’unico problema recente di GitLab con la massima gravità indicato nella documentazione. A settembre, CVE-2026-85706 ha interessato l’API dei commit dei repository e poteva consentire a un attaccante senza autenticazione di leggere file arbitrari dai server vulnerabili. SocPrime descrive come i file esposti potessero includere dati di configurazione, credenziali, segreti CI/CD e token di distribuzione. È stato inoltre osservato che la vulnerabilità veniva sottoposta a tentativi di rilevamento poco dopo il rilascio delle patch, ed è stata aggiunta al catalogo CISA delle vulnerabilità note sfruttate.

Il contrasto tra le due falle è istruttivo. Un problema riguardava la lettura dei file; quello più recente riguarda l’esecuzione di codice attraverso l’elaborazione CI/CD. Sono vulnerabilità diverse e non dovremmo confondere le rispettive tempistiche o prove. Insieme, però, dimostrano perché una compromissione di GitLab possa aggravarsi rapidamente: la piattaforma custodisce sia informazioni preziose sia potenti strumenti di automazione.

L’implicazione pratica è scomoda, ma chiara. Applicare la patch è necessario, non sufficiente. Le organizzazioni dovrebbero anche chiedersi a quali sistemi potesse accedere l’istanza, quali credenziali fossero esposte ai runner e se i log mostrino attività sospette precedenti alla correzione. Trattare l’aggiornamento come la conclusione del processo di risposta all’incidente è proprio il modo in cui una vulnerabilità si trasforma in una violazione dalle conseguenze più durature.

L’infrastruttura autogestita porta con sé il vero carico operativo

GitLab.com era già stato corretto per CVE-2026-97229 e, secondo quanto riportato, i clienti GitLab Dedicated non dovevano intraprendere alcuna azione. La responsabilità urgente ricade soprattutto sulle organizzazioni che gestiscono installazioni self-managed. La documentazione delle patch di GitLab identifica il rilascio del 12 ottobre e le edizioni interessate.

Questa distinzione dovrebbe cambiare le discussioni su acquisti e personale. Gestire il servizio in proprio non è soltanto una scelta di hosting: significa impegnarsi a seguire gli avvisi di sicurezza, mantenere versioni supportate, applicare aggiornamenti d’emergenza, limitare l’esposizione e indagare su possibili compromissioni. Se un’organizzazione non sa dire chi è responsabile di queste attività, non è davvero responsabile della sicurezza di GitLab: sta semplicemente sperando che la prossima falla critica si presenti in un momento conveniente.

I controlli temporanei possono ridurre l’esposizione mentre si prepara un aggiornamento. Le informazioni disponibili raccomandano in particolare di limitare l’accesso ai progetti non affidabili, sottolineando però che queste misure non sostituiscono l’applicazione della patch. Più in generale, i runner CI/CD e i permessi di distribuzione dovrebbero essere trattati come confini di fiducia sensibili, non come estensioni intercambiabili della workstation di uno sviluppatore.

La sicurezza della CI/CD va misurata in base al raggio d’azione

La domanda abituale sulla sicurezza è: “Un attaccante può raggiungere il servizio vulnerabile?”. Per l’infrastruttura degli sviluppatori, è solo la prima domanda. Quella più importante è: “A quali sistemi può accedere il servizio dopo essere stato compromesso?”.

Questo significa censire i segreti dei repository, i permessi dei runner, i token di distribuzione, le connessioni cloud, i registry e i percorsi verso la produzione. Significa separare, quando possibile, gli ambienti di compilazione e limitare le credenziali disponibili per i singoli job. Significa anche conservare log sufficienti a stabilire se un’istanza vulnerabile sia stata soltanto esposta o sia stata effettivamente utilizzata.

È questo, a nostro avviso, l’aspetto della vicenda GitLab che merita più attenzione del punteggio riportato nei titoli. CVSS 10,0 comunica l’urgenza, ma non descrive l’impatto complessivo per l’azienda di una software factory compromessa. Il rischio reale dipende dall’architettura: permessi eccessivi e connettività senza separazione possono trasformare la falla di un singolo server in un problema di distribuzione per tutti i clienti a valle.

Il verdetto è chiaro: applica immediatamente le patch alle istanze GitLab self-managed interessate, poi esamina le relazioni di fiducia che gestiscono. Le piattaforme CI/CD sono infrastrutture critiche per la produzione perché producono il software destinato alla produzione. Le organizzazioni che continuano a classificarle come strumenti di collaborazione per sviluppatori stanno misurando la cosa sbagliata e difendendo il perimetro sbagliato.