CVE-2026-97229: vulnerabilità critica in GitLab CE/EE sfruttata, come verificare e applicare la patch

Se la tua azienda ospita un'istanza GitLab self-managed, aggiornala oggi. La vulnerabilità CVE-2026-97229 permette a un utente non autenticato di eseguire codice arbitrario sul server GitLab tramite un'espressione regolare costruita ad arte in una configurazione CI/CD. CISA l'ha inserita nel catalogo delle vulnerabilità sfruttate attivamente. GitLab ha pubblicato le versioni corrette 19.4.2, 19.3.5 e 19.2.8. Qui sotto spiego chi è colpito, come verificare la propria esposizione e cosa fare in ordine di priorità.

Cosa è successo

GitLab compila le espressioni regolari fornite dagli utenti, per esempio i pattern nei file di configurazione CI, usando il motore di Ruby. GitLab ha scoperto che pattern costruiti ad arte possono corrompere la memoria durante la compilazione e che questo può essere trasformato in esecuzione di codice remoto sul server. La vulnerabilità è classificata come integer overflow nel compilatore delle espressioni regolari usato per la CI/CD. Il bug di fondo sta in Ruby (motore Onigmo) ed è stato corretto anche lì. CVE-2026-97229 è una delle quattro CVE pubblicate da GitLab per questa famiglia di problemi: le altre sono CVE-2026-89078, CVE-2026-93577 e CVE-2026-110264.

Chi è colpito

Sono interessate GitLab Community Edition (CE) ed Enterprise Edition (EE) in installazione self-managed, in tutti i tipi di deployment (omnibus, sorgente, chart Helm). Il patch release del 12 ottobre 2026 indica come versioni corrette:

• 19.4.2
• 19.3.5 (la 19.3.4 aveva un bug sulle pagine delle merge request con l'integrazione Ona attiva)
• 19.2.8

L'elenco preciso delle versioni vulnerabili va verificato sull'advisory GitLab. In pratica, se la tua istanza è su una versione precedente a quelle indicate, considerala esposta. GitLab.com è già aggiornato e i tenant GitLab Dedicated sono stati corretti con una release interna prima della pubblicazione: se usi solo il servizio cloud di GitLab non devi intervenire sul server, ma vale comunque il controllo sulle credenziali di cui parlo più avanti.

Quanto è grave

GitLab classifica la vulnerabilità come critica. Il punteggio CVSS non è ancora stato assegnato da NVD, ma la presenza nel catalogo CISA KEV indica sfruttamento attivo confermato. Non è noto se sia usata in campagne ransomware. Alle agenzie federali USA CISA ha imposto una scadenza di rimedio al 1 novembre 2026, cioè tre giorni dopo la pubblicazione: un segnale della priorità attribuita.

Cosa può fare un attaccante: eseguire codice sul server GitLab senza autenticarsi. Significa accesso potenziale al codice sorgente, alle variabili CI/CD (spesso contengono chiavi cloud, password di database, token di deploy), ai runner e, tramite le pipeline, ai sistemi su cui GitLab pubblica. In una PMI il server GitLab è di frequente il punto da cui si raggiunge tutto il resto. I dettagli pubblici dell'exploit non sono noti; GitLab rende pubblici gli issue di sicurezza 90 giorni dopo la patch.

Come capire se sei esposto

Leggere la versione installata

• Da interfaccia web: accedi come amministratore e apri Admin Area, poi Overview: la versione compare nella scheda riepilogativa. In alternativa la pagina /help mostra la versione agli utenti autenticati.
• Da shell sul server (installazione omnibus): sudo gitlab-rake gitlab:env:info riporta versione di GitLab e di Ruby. Anche cat /opt/gitlab/version-manifest.txt è utile.
• Via API, con un token: chiamata GET a /api/v4/version.

Verificare se il servizio è raggiungibile da internet

• Da una rete esterna (per esempio il telefono con dati mobili) prova ad aprire l'URL dell'istanza. Se la pagina di login risponde, è esposta.
• Sul firewall o sul router controlla le regole di port forwarding verso il server (in genere 80, 443 e 22 per Git via SSH).
• Sul server: sudo ss -tlnp mostra le porte in ascolto e su quali interfacce.
• Controlla se la registrazione pubblica di nuovi utenti è attiva in Admin Area > Settings > General > Sign-up restrictions. Un'istanza aperta alle iscrizioni allarga molto la superficie.

Log e indicatori da guardare

• /var/log/gitlab/gitlab-rails/production_json.log e production.log: richieste anomale verso endpoint legati alla CI (lint, pipeline, modifica di file .gitlab-ci.yml) da IP sconosciuti.
• /var/log/gitlab/puma/ e /var/log/gitlab/sidekiq/: crash o riavvii ripetuti dei worker possono indicare tentativi di sfruttamento della corruzione di memoria.
• Processi inattesi avviati dall'utente git, connessioni in uscita non previste, nuovi utenti amministratori, nuovi token o deploy key, modifiche ai runner.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La correzione è contenuta nelle versioni GitLab 19.4.2, 19.3.5 e 19.2.8, disponibili attraverso i canali di aggiornamento abituali (repository dei pacchetti omnibus, immagini Docker, chart Helm). GitLab ha risolto il problema applicando la patch al Ruby che distribuisce; non serve aggiornare Ruby a mano su un'installazione omnibus. Chi installa GitLab da sorgente deve invece verificare la versione di Ruby: le release Ruby 4.0.8 o successive, 3.4.12 e 3.3.13 contengono il fix per il bug alla base di CVE-2026-97229. Ruby 4.0.9, 3.4.12 e 3.3.13 includono le correzioni per tutte e quattro le CVE.

Prima di aggiornare fai un backup consistente (sudo gitlab-backup create più copia di gitlab-secrets.json e gitlab.rb) e rispetta il percorso di upgrade indicato nella documentazione se parti da versioni lontane.

Cosa fare subito

1. Aggiorna alla versione corretta della tua serie. È l'unica mitigazione completa. CISA indica di seguire le istruzioni del produttore e di interrompere l'uso del prodotto se non esistono mitigazioni applicabili.
2. Se non puoi aggiornare entro poche ore, riduci l'esposizione: metti l'istanza dietro VPN, limita l'accesso a IP noti, chiudi il port forwarding da internet, disattiva la registrazione pubblica degli utenti.
3. Non affidarti a limiti sulle regex: l'advisory Ruby è esplicito, Regexp.timeout non protegge e nemmeno il limite sulla lunghezza dei pattern, perché alcuni bug si attivano con pattern brevi.
4. Ruota le credenziali dopo l'aggiornamento se l'istanza era raggiungibile da internet: token di registrazione dei runner, personal access token, deploy key, variabili CI/CD con segreti verso cloud e database.
5. Verifica il backup: deve esistere, essere recente e ripristinabile. Se non hai un piano scritto, il mio articolo sul disaster recovery per PMI spiega da dove partire.

Se sospetti di essere già stato colpito

Non spegnere il server e non reinstallare: cancelleresti le tracce che servono a capire cosa è stato preso. Isola la macchina dalla rete (stacca il cavo o blocca il traffico sul firewall), lasciala accesa e conserva i log con una copia su un supporto separato. Documenta orari e azioni svolte. Poi avvia un'analisi di incident response: acquisizione forense del disco e della memoria, ricostruzione della timeline, verifica dei segreti esposti e delle macchine raggiunte tramite i runner. Per il modo in cui ho affrontato un caso simile sul lato sistema operativo, vedi l'articolo su CVE-2026-46300 nel kernel Linux. Se serve una perizia utilizzabile in sede legale o assicurativa, l'acquisizione va fatta con metodo forense fin dal primo momento. Un intervento di incident response nel mio studio parte da 1.500 € e un audit di sicurezza completo da 2.000 €, sempre con preventivo a prezzo fisso.

Fonti

• NVD: CVE-2026-97229
• GitLab Critical Patch Release 19.4.2, 19.3.5, 19.2.8
• Ruby: correzioni al motore regexp per le CVE di GitLab
• CISA BOD 26-04
• CISA BOD 26-04, guida all'implementazione

Serve una mano?

Se hai un GitLab self-managed e non sai da che versione parti, se l'istanza è esposta o se i log mostrano qualcosa di strano, posso fare la verifica con te, da remoto o di persona tra Varese, Como e Milano. Scrivimi dalla pagina contatti oppure chiedi un preventivo gratuito: rispondo entro 24 ore.