GitLab CVE-2026-110264: RCE senza autenticazione con CVSS 10 tramite un file .org

Il 21 ottobre GitLab ha pubblicato una patch release critica per CVE-2026-110264, con CVSS 10.0: in determinate condizioni un utente non autenticato può eseguire codice arbitrario su un server GitLab self-managed, per un integer overflow durante la compilazione di un'espressione regolare costruita ad arte. Le note di detection di GitLab indicano il percorso: un file Org-mode (.org) preparato in un qualsiasi progetto pubblico e renderizzato dal server. Le versioni colpite partono da GitLab 7.0, e le istanze aggiornate con la release critica del 12 ottobre sono ancora dentro l'intervallo.

Notizia in evoluzione — pubblicata alle 13:46 (11:46 UTC) del 22 ottobre 2026. Aggiornata man mano che vendor e CISA pubblicano.

In breve

CVE	CVE-2026-110264
Prodotto / versioni colpite	GitLab CE/EE self-managed · tutte le versioni dalla 7.0 prima della 18.11.13 · 19.0 prima della 19.0.10 · 19.1 prima della 19.1.9 · 19.2 prima della 19.2.9 · 19.3 prima della 19.3.6 · 19.4 prima della 19.4.3 · 19.5 prima della 19.5.1
Corretta in	19.5.1 · 19.4.3 · 19.3.6 · backport 19.2.9 · 19.1.9 · 19.0.10 · 18.11.13 (rilasciate il 21 ottobre 2026)
CVSS	10.0 critica · CVSS 3.1 · AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H · punteggio di GitLab (CNA); NVD non l'ha ancora valutata
Sfruttata attivamente	Non segnalato da GitLab; nessun rapporto di sfruttamento da CISA o da CERT nazionali
CISA KEV	Non presente (versione del catalogo 2026.10.21)
Advisory ufficiale	GitLab Critical Patch Release 19.5.1

Cosa ha corretto GitLab, e perché "dalla 7.0" è vero

Il post di rilascio contiene 12 correzioni di sicurezza; CVE-2026-110264 è l'unica critica, segnalata su HackerOne dal ricercatore joaxcar. L'intervallo colpito, sia nell'advisory sia nel record CVE, parte da GitLab 7.0: non è un'esagerazione della stampa. Ogni linea di rilascio self-managed ancora in uso è coinvolta, comprese installazioni molto più vecchie di quelle che GitLab supporta ancora. GitLab.com e GitLab Dedicated sono già corretti. GitLab non pubblica alcun workaround.

Il meccanismo viene dalle schede di detection della sicurezza di GitLab, non dal testo dell'advisory. Nella detection sul rendering Org-mode GitLab spiega che i file .org vengono renderizzati con la gem org-ruby (0.9.12), che prende una keyword personalizzata da una riga #+TODO: e la inserisce senza escape in Regexp.new. Una keyword con più di 32.767 ripetizioni spinge un ID di ripetizione del motore regex Onigmo di Ruby oltre il limite dei 16 bit con segno: l'ID diventa negativo e il matcher scrive fuori dal buffer. Con un heap grooming, scrive GitLab, si arriva a una chiamata system() come utente git, e all'attacco basta un solo progetto pubblico che contenga il file .org.

Un file in un repository è un dato finché il server non lo renderizza. Su GitLab il rendering avviene per chiunque possa aprire la pagina del progetto.

Perché la patch del 12 ottobre non basta

Il motore regex è lo stesso di CVE-2026-97229, l'overflow nelle rules:regexp della CI/CD che GitLab ha corretto il 12 ottobre con 19.4.2, 19.3.5 e 19.2.8. La detection sui crash di Onigmo le tratta come un'unica famiglia con due punti d'ingresso: il percorso CI va in overflow in compilazione, quello Org-mode scrive fuori dal buffer durante il match. Le versioni del 12 ottobre sono inferiori a quelle nuove: chi ha aggiornato dieci giorni fa è ancora esposto e deve aggiornare di nuovo.

Il precedente da ricordare è CVE-2021-22205: GitLab passava le immagini caricate a un parser senza validarle, il risultato era l'esecuzione di comandi senza autenticazione, e CISA l'ha inserita nel KEV a novembre 2021. Il rendering lato server di contenuti forniti dall'attaccante è il punto debole ricorrente di questa piattaforma. Le altre nostre analisi su GitLab, con tutte le CVE GitLab del catalogo CISA, sono nella pagina delle vulnerabilità GitLab.

Chi è esposto

• Istanze self-managed esposte su internet in cui chiunque vede almeno un progetto pubblico, o in cui la registrazione aperta permette a chiunque di crearne uno. È la precondizione descritta da GitLab.
• Le istanze interne non sono sicure di default: chiunque abbia un account, o raggiunga un progetto pubblico da una postazione compromessa, è sullo stesso percorso.
• Installazioni 18.10 o precedenti: non hanno una release corretta propria e devono seguire il percorso di upgrade di GitLab fino alla 18.11.13 o successiva.
• Installazioni da sorgente con il Ruby di sistema: l'advisory non le copre e non dà istruzioni.

Cosa raggiunge un attaccante che riesce, secondo GitLab: gitlab-secrets.json, tutte le variabili CI/CD, i token dei runner e i token di accesso, e accesso in lettura e scrittura a tutti i repository dell'istanza.

Remediation

1. Sono colpito? Controlla la versione in Admin → Overview → Dashboard, oppure su un host Omnibus con sudo gitlab-rake gitlab:env:info. Qualsiasi versione sotto quella corretta del proprio ramo è colpita, comprese 19.4.2, 19.3.5 e 19.2.8.

2. Patch — versioni corrette esatte. Aggiorna a 19.5.1, 19.4.3 o 19.3.6, oppure ai backport 19.2.9, 19.1.9, 19.0.10 o 18.11.13. Le istanze a nodo singolo restano ferme durante le migrazioni; quelle multi-nodo possono usare la procedura zero-downtime di GitLab. Parti dalle istanze raggiungibili da internet.

3. Non puoi aggiornare subito? Controlli compensativi. GitLab non indica workaround e nessuna impostazione disattiva da sola il rendering Org, quindi questi interventi riducono solo l'esposizione:

• Togli l'istanza da internet (VPN o allowlist IP davanti) finché non è aggiornata.
• Elimina la precondizione indicata da GitLab: in Admin → Settings → General → Visibility and access controls limita il livello di visibilità Public, e disattiva la registrazione in Sign-up restrictions. Gli utenti autenticati raggiungono comunque il renderer: è un rinvio, non una correzione.

4. Cerca tracce di compromissione. GitLab ha pubblicato gli indicatori; usali come sono scritti:

• exceptions_json.log (Omnibus: /var/log/gitlab/gitlab-rails/exceptions_json.log): una raffica di Timeout::Error con extra.class_name = OtherMarkup e un file .org in extra.file_name. La regola di GitLab scatta con cinque o più eventi dallo stesso client in 30 minuti.
• Log di accesso di Workhorse: HTTP 502 sulla route blob di un file .org, cioè la richiesta che ha fatto cadere un worker e non è mai arrivata nei log Rails.
• puma_stderr.log (/var/log/gitlab/puma/puma_stderr.log): crash nativi [BUG] con frame di org-ruby headline.rb o di Onigmo come match_at e onig_search_gpos.
• Nei repository: file .org con una riga #+TODO:, #+SEQ_TODO: o #+TYP_TODO: sproporzionata, cioè il payload stesso.

GitLab è esplicita: un exploit riuscito è silenzioso e non manda sempre in crash il worker, quindi l'assenza di questi segnali non scagiona un'istanza. MITRE ATT&CK: T1190 (Exploit Public-Facing Application), T1059.004 (Unix shell), T1552.001 (credenziali in file), T1213.003 (dati da repository di codice).

5. Bonifica e verifica. Se scatta un segnale, considera l'host compromesso: ricostruiscilo da un'immagine pulita invece di aggiornarlo sul posto, poi ruota ciò che l'utente git poteva leggere: token di accesso personali, di progetto e di gruppo, token dei runner, variabili CI/CD, deploy key e secret delle applicazioni OAuth. Pianifica a parte i valori di gitlab-secrets.json, perché alcuni cifrano dati nel database. Alla fine verifica la versione corretta su tutti i nodi, non solo su quello che ha dato l'allarme.

Cosa non si sa ancora

• Se qualcuno la stia sfruttando. GitLab non lo dice e non è nel KEV. Un repository GitHub pubblicato come exploit di CVE-2026-110264 dichiara nel proprio README di implementare la precedente catena di CVE-2026-97229.
• Il punteggio di NVD; il 10.0 è di GitLab.
• Se l'anteprima dell'editor web, che la regola secondaria di GitLab sorveglia, offra un secondo percorso senza autenticazione.

La CSA di Singapore ha emesso il 22 ottobre un alert che chiede agli amministratori di aggiornare subito. Se CISA la inserisse nel catalogo con controllo totale del sistema, con ogni probabilità la BOD 26-04 imporrebbe alle agenzie federali la scadenza più breve; le fasce sono spiegate nella nostra guida alla BOD 26-04.

Testare il proprio GitLab, non l'advisory

Il controllo di versione dice che l'istanza è nell'intervallo colpito. Non dice se un utente non autenticato raggiunge davvero il renderer Org nella tua configurazione: se i progetti pubblici sono visibili, se la registrazione è aperta, quali nodi e mirror stanno dietro quale percorso di rete. Zero Hunt lo verifica come farebbe un attaccante: il suo red team AI autonomo identifica dall'esterno la versione esatta di GitLab, mappa cosa vede un utente non autenticato, e l'exploit forge itera un proof-of-concept contro quella specifica installazione finché funziona in modo dimostrabile. Lavora in black box di default, su un'appliance on-premise con AI privata, e una persona approva ogni passo di sfruttamento. Per confrontarlo con altri strumenti c'è la nostra guida al penetration test automatizzato.

Il piano di correzione arriva poi dal Remediation Advisor: prima questa CVE se la prova è andata a segno, l'upgrade esatto con il suo rollback, il controllo compensativo per i nodi che oggi non si possono aggiornare, e un nuovo test con la stessa prova a upgrade fatto. Ogni passo è firmato al momento della scrittura in un registro di evidenze concatenato con hash: "aggiornato" diventa qualcosa che puoi dimostrare, non solo una stringa di versione.