GitLab CVE-2026-97229: Rapid7 riproduce la RCE, serve la 19.3.5

📌 Sviluppi successivi: GitLab CVE-2026-110264: anche LDAP injection e request smuggling (22 ottobre 2026) · GitLab 19.5.1: nuova RCE CVE-2026-110264 senza autenticazione (22 ottobre 2026)

Il 12 ottobre ARX News ha trattato la CVE-2026-97229 (CVSS 10.0) di GitLab Community Edition (CE) ed Enterprise Edition (EE), l’integer overflow nel compilatore delle espressioni regolari di CI/CD, sulla base degli avvisi del CERT-EU e del CERT-FR. Nelle ore successive sono arrivati il bollettino di GitLab ripreso dalle testate, gli avvisi di INCIBE-CERT, del CERT.LV e del CCB belga e, soprattutto, una prima analisi di Rapid7. Di seguito le novità che cambiano le priorità.

Per il ramo 19.3 la versione corretta è la 19.3.5

Il punto più pratico riguarda il ramo 19.3. Il bollettino di GitLab, intitolato secondo INCIBE-CERT «GitLab Critical Patch Release: 19.4.2, 19.3.5, 19.2.8», indica come versione corretta la 19.3.5. Lo stesso numero compare in Help Net Security, CSO Online, Security Affairs e nell’avviso del CERT.LV. Il CERT-EU, il CERT-FR e BleepingComputer riportavano invece la 19.3.4, ed è il numero del nostro primo articolo.

Le fonti non spiegano la differenza. Per prudenza, sul ramo 19.3 considera corretta solo la 19.3.5 o una versione successiva, anche se hai già installato la 19.3.4.

Versioni colpite secondo GitLab, come riportate dalle testate e da INCIBE-CERT:

• dalla 19.2 alla 19.2.8 esclusa;
• dalla 19.3 alla 19.3.5 esclusa;
• dalla 19.4 alla 19.4.2 esclusa.

GitLab.com usa già la versione corretta e i clienti di GitLab Dedicated non devono fare nulla. Secondo CSO Online, GitLab precisa che, quando un tipo di installazione (omnibus, da sorgenti, chart Helm) non è indicato, sono colpiti tutti.

Cosa ha verificato Rapid7

Secondo l’aggiornamento di Help Net Security del 13 ottobre, l’unica fonte che lo riporta, i ricercatori di Rapid7 hanno riprodotto l’esecuzione di codice sull’immagine ufficiale di GitLab CE 19.4.1 non aggiornata; lo stesso input non ha funzionato sull’immagine 19.4.2.

Rapid7 chiarisce anche le condizioni di sfruttamento. Il vettore CVSS del produttore indica attacco da rete, bassa complessità, nessun privilegio e nessuna interazione dell’utente. Per Rapid7, però, l’attaccante deve prima poter fare il commit, su un branch di un progetto pubblico, di un file .gitlab-ci.yml malevolo e di un percorso del repository che contiene caratteri UTF-8. Sulle istanze self-managed che permettono agli utenti di creare progetti pubblici basta un account ordinario.

L’esposizione dipende quindi da chi può ottenere un account sull’istanza e creare progetti pubblici. In termini MITRE ATT&CK resta lo sfruttamento di un’applicazione esposta (T1190), ma con un account valido.

Secondo Rapid7, al momento non c’è uno sfruttamento confermato in attacchi reali; anche INCIBE-CERT indica la vulnerabilità come non sfruttata. Rapid7 raccomanda comunque di aggiornare con urgenza, fuori dal normale ciclo delle patch. Il CCB belga e il CERT.LV chiedono di aggiornare subito.

La vulnerabilità è stata segnalata tramite il programma di bug bounty di GitLab su HackerOne dal ricercatore «joaxcar» (Johan Carlsson, secondo CSO Online). Secondo Help Net Security, lo stesso ricercatore ha segnalato anche la CVE-2026-7767, un open redirect di gravità media nel proxy Kubernetes di GitLab che può far arrivare token di autenticazione a un server non previsto.

Le altre correzioni del rilascio

Secondo INCIBE-CERT, le 24 vulnerabilità corrette sono così suddivise: 1 critica, 5 alte, 14 medie e 4 basse. Rispetto al primo articolo, CSO Online collega a un identificativo tutte e cinque quelle di gravità alta:

• CVE-2026-92883 (CVSS 8.7): cross-site scripting nell’output con evidenziazione della sintassi, per una sanitizzazione insufficiente degli attributi HTML;
• CVE-2026-16301 (CVSS 8.5): un utente con ruolo Developer può eseguire pipeline su branch protetti senza autorizzazione;
• CVE-2026-14814 (CVSS 8.2): è il cache poisoning già citato; riguarda le risposte per i file raw del repository e può far eseguire contenuto malevolo alle pipeline prese di mira, con accesso alle variabili d’ambiente protette;
• CVE-2026-81839 (CVSS 7.7): un utente autenticato può eseguire pipeline arbitrarie in un progetto trasferito, con i privilegi del nuovo gruppo;
• CVE-2026-96893 (CVSS 7.3): in GitLab Duo, un utente autenticato può inserire contenuto costruito ad arte nelle istruzioni degli agenti IA, con possibile esecuzione di comandi non voluti attribuita ad altri utenti.

Le vulnerabilità di gravità media e bassa riguardano GitLab Pages, il proxy Kubernetes, le API GraphQL, le merge request, i ruoli personalizzati, il package registry e l’importazione di repository e progetti. Secondo CSO Online, GitLab renderà pubblici i dettagli delle segnalazioni 90 giorni dopo il rilascio: non conviene aspettarli per aggiornare.

Impatto per le aziende europee e italiane

Le condizioni descritte da Rapid7 rendono più esposte le istanze GitLab condivise con molti utenti, compresi fornitori, consulenti e collaboratori esterni, soprattutto se permettono di creare progetti pubblici. Sono spesso le stesse istanze che custodiscono pipeline di rilascio e segreti.

Gli avvisi di CSIRT nazionali in Belgio, Spagna e Lettonia, oltre a quelli del CERT-EU e del CERT-FR, confermano l’attenzione europea. Per i soggetti NIS2 vale quanto già scritto nel primo articolo: gestione delle vulnerabilità, sicurezza della catena di fornitura del software e, in caso di incidente significativo, notifica allo CSIRT Italia dell’ACN.

Cosa fare subito

1. Ramo 19.3: aggiorna alla 19.3.5 o successiva, anche se sei già alla 19.3.4. Sugli altri rami: 19.4.2 o 19.2.8 o successive. Per il ramo 19.1 resta valido quanto già scritto: nessuna correzione indicata, passa almeno alla 19.2.8.
2. Priorità: parti dalle istanze raggiungibili da Internet e da quelle in cui la registrazione è aperta o gli utenti possono creare progetti pubblici.
3. Verifica le impostazioni: controlla chi può registrarsi e chi può creare progetti pubblici, la condizione indicata da Rapid7. Non è una mitigazione indicata da GitLab: l’unica correzione è l’aggiornamento.
4. Controlla i repository: cerca le modifiche recenti a .gitlab-ci.yml nei progetti pubblici, soprattutto da account nuovi o poco usati, e i percorsi del repository con caratteri non ASCII. Nessuna fonte ha pubblicato indicatori di compromissione.
5. Se trovi attività sospetta: considera esposto il server, sostituisci i segreti usati dalle pipeline e valuta gli obblighi di notifica.

Come aiuta ARXDOME

ARX Expose individua i servizi che la tua azienda espone su Internet e i prodotti con vulnerabilità note: aiuta a capire se un’istanza GitLab è raggiungibile da fuori. ARX Shield elenca le vulnerabilità aperte sulle macchine monitorate. ARX Sentry raccoglie log ed eventi dei server su cui è installato l’agent e controlla l’integrità dei file nelle cartelle stabilite. Con ARX Horizon consulti dal portale i dettagli delle vulnerabilità.

Ultimo aggiornamento: 13 ottobre 2026