CVE-2026-110264: Grave vulnerabilità RCE in GitLab interessa 12 anni di pubblicazioni

GitLab ha rilasciato aggiornamenti di sicurezza urgenti per affrontare CVE-2026-110264, una vulnerabilità di massima gravità che potrebbe consentire a un attaccante non autenticato di eseguire codice arbitrario su server GitLab autogestiti vulnerabili. Il difetto ha un punteggio CVSS di 10.0 e colpisce sia GitLab Community Edition (CE) che Enterprise Edition (EE).

La vulnerabilità è particolarmente degna di nota perché il codice interessato risale a GitLab 7.0, rilasciato nel 2014. Ciò lascia circa 12 anni di rilasci GitLab all’interno della gamma vulnerabile, anche se attualmente non vi è alcuna prova che gli attaccanti abbiano sfruttato la debolezza durante quel periodo. GitLab ha divulgato la questione e rilasciato versioni patchate il 21 ottobre 2026.

La vulnerabilità origina da un overflow dell’intero attivato mentre GitLab compila un’espressione regolare appositamente creata. In certe condizioni, un attaccante non autenticato potrebbe utilizzare quella condizione per eseguire codice arbitrario sul server GitLab sottostante. GitLab ha volutamente trattenuto il percorso completo di sfruttamento e i requisiti specifici mentre gli amministratori distribuiscono le patch.

Per le organizzazioni che gestiscono infrastrutture GitLab autogestite, il potenziale impatto è grave. I repository GitLab contengono frequentemente codice sorgente, configurazione CI/CD, segreti di distribuzione, token di accesso, definizioni di infrastruttura e collegamenti a ambienti di produzione. Un compromesso a livello di server potrebbe quindi creare opportunità per il furto di credenziali, la manipolazione dei repository, attacchi alla catena di fornitura, persistenza o movimento laterale.

I team di sicurezza che cercano opportunità di rilevamento per CVE-2026-110264 possono sfruttare la piattaforma SOC Prime’s AI-Native Detection Intelligence per rafforzare la visibilità dello sfruttamento delle vulnerabilità e del comportamento post-compromesso correlato negli ambienti SIEM, EDR e Data Lake.

Clicca Esplora Rilevamenti per accedere ai contenuti di rilevamento pertinenti e alla logica di caccia. Per rilevare tentativi di sfruttamento di CVE-2026-110264, i difensori dovrebbero correlare la telemetria dell’applicazione GitLab con l’esecuzione dei processi, il comportamento anomalo del server e la logica di rilevamento delle minacce di nuova pubblicazione di GitLab.

I professionisti della sicurezza possono anche utilizzare Prime Architect per trasformare l’intelligence emergente sulle vulnerabilità in regole Sigma e query di caccia, convalidare la logica di rilevamento, generare Flussi di Attacchi pertinenti e tradurre i contenuti di rilevamento tra le piattaforme di sicurezza supportate.

Contatta Vendite

analisi CVE-2026-110264

GitLab descrive la vulnerabilità come un overflow dell’intero nel suo compilatore di espressioni regolari. In certe condizioni, la compilazione di un’espressione regolare appositamente creata può portare all’esecuzione di codice arbitrario sul server GitLab senza autenticazione.

GitLab ha assegnato alla vulnerabilità il massimo punteggio CVSS v3.1 di 10.0, con il vettore CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Questo riflette una vulnerabilità accessibile tramite rete con complessità di attacco bassa, nessun privilegio richiesto e nessuna interazione dell’utente, con un impatto potenzialmente elevato su confidenzialità, integrità e disponibilità.

Il ricercatore di sicurezza joaxcar ha scoperto e segnalato la vulnerabilità tramite il programma bug bounty di GitLab su HackerOne. Le note di rilascio di GitLab fanno anche riferimento a patch per la gestione delle espressioni regolari in Ruby, mentre i rapporti indicano che il motore sottostante interessato è Onigmo, l’implementazione delle espressioni regolari di Ruby integrata nei pacchetti GitLab.

CVE-2026-110264 colpisce GitLab CE e EE su un intervallo insolitamente ampio:

• GitLab 7.0 fino a versioni prima della 18.11.13
• GitLab 19.0 prima della 19.0.10
• GitLab 19.1 prima della 19.1.9
• GitLab 19.2 prima della 19.2.9
• GitLab 19.3 prima della 19.3.6
• GitLab 19.4 prima della 19.4.3
• GitLab 19.5 prima della 19.5.1

GitLab ha riportato il fix nella 18.11.13, 19.0.10, 19.1.9, e 19.2.9 oltre ai suoi normali rami di patch supportati a causa della gravità e della difussione insolitamente ampia.

Il lungo intervallo di vulnerabilità non significa che il difetto sia stato attivamente sfruttato dal 2014. Piuttosto, la funzionalità vulnerabile delle espressioni regolari è esistita attraverso le versioni che risalgono a GitLab 7.0. Né GitLab né i due rapporti forniti hanno confermato lo sfruttamento in attacchi reali al 22 ottobre 2026.

Questa vulnerabilità non dovrebbe inoltre essere confusa con CVE-2026-97229, un’altra vulnerabilità critica di esecuzione di codice remoto di GitLab legata alla gestione delle espressioni regolari, che è stata corretta all’inizio di ottobre. Quel problema ha colpito un intervallo più ristretto di versioni più recenti. L’installazione delle correzioni del 12 ottobre per quella vulnerabilità non protegge automaticamente i sistemi da questo nuovo difetto divulgato.

Gli amministratori che hanno aggiornato di recente GitLab devono quindi verificare la build esatta installata piuttosto che presumere che un precedente rilascio di sicurezza di ottobre fornisca una protezione sufficiente.

I dettagli attualmente disponibili per CVE-2026-110264 non rivelano l’input controllato dall’attaccante preciso, l’endpoint, la funzionalità o le condizioni richieste per raggiungere il compilatore vulnerabile delle espressioni regolari. Generalmente, GitLab rende pubblici i problemi di sicurezza dettagliati 90 giorni dopo il rilascio contenente una correzione, riducendo la disponibilità immediata di informazioni tecniche strumentalizzabili mentre i clienti applicano le patch.

Nessuna PoC pubblica CVE-2026-110264 è stata divulgata nei rapporti forniti o nell’avviso di GitLab. Cybersecurity News afferma specificamente che GitLab non ha pubblicato uno exploit pubblico, mentre l’azienda ha limitato la divulgazione del percorso completo di attacco.

Allo stesso tempo, l’assenza di una PoC pubblica non dovrebbe essere interpretata come un rischio basso. Una vulnerabilità accessibile in remoto e non autenticata con un punteggio CVSS di 10.0 rappresenta un obiettivo attraente, in particolare perché i server GitLab autogestiti sono frequentemente esposti a Internet.

Attualmente non ci sono IOC dell’eventuale VCE-2026-110264 come indirizzi IP malevoli, domini, hash di payload o modelli di richieste di exploit confermati perché né GitLab né i ricercatori di sicurezza citati hanno segnalato sfruttamenti attivi.

GitLab ha, tuttavia, pubblicato due rilevamenti delle minacce intesi a identificare possibili tentativi di sfruttamento su installazioni autogestite:

• Crash del lavoratore nativo di Onigmo
• Errore di rendering del burst in modalità Org

Questi rilevamenti sono progettati per identificare comportamenti sospetti correlati a tentativi di attivare la vulnerabilità. La loro presenza non conferma di per sé un compromesso avvenuto e dovrebbe essere correlata con la telemetria applicativa e degli endpoint più ampia.

I team di sicurezza dovrebbero indagare su crash inaspettati dell’applicazione GitLab, esplosioni di errori di rendering, processi anomali originati da componenti GitLab o Ruby, esecuzioni di shell inaspettate, nuovi meccanismi di persistenza creati e connessioni in uscita dai server GitLab che deviano dai modelli operativi normali.

Mitigazione CVE-2026-110264

GitLab raccomanda fortemente che tutte le organizzazioni che operano su installazioni autogestite vulnerabili eseguano un aggiornamento immediato. Le versioni corrette sono:

GitLab.com è già stato aggiornato. I locatari di GitLab Dedicated che eseguono versioni interne 19.3.5-internal0, 19.4.2-internal0 o successivi contengono già le correzioni necessarie e non devono intraprendere azioni per questa vulnerabilità.

I clienti autogestiti non dovrebbero ritardare la mitigazione mentre aspettano ulteriori dettagli di sfruttamento. GitLab non ha pubblicato una soluzione alternativa che fornisca una protezione equivalente, rendendo l’installazione del rilascio corretto il percorso di mitigazione affidabile.

Prima di aggiornare, gli amministratori dovrebbero esaminare la documentazione di aggiornamento di GitLab e tener conto delle migrazioni del database. GitLab avverte che i deployment a nodo singolo possono subire tempi di inattività mentre le migrazioni sono in corso, mentre gli ambienti multi-nodo configurati correttamente possono seguire il processo di aggiornamento a zero tempi di inattività del venditore. Le versioni 19.3.6 e 19.4.3 contengono migrazioni regolari, e la 19.4.3 include anche una migrazione post-distribuzione.

Dopo aver applicato la patch, i team di sicurezza dovrebbero eseguire un’analisi retrospettiva piuttosto che trattare l’aggiornamento stesso come prova che un server non è mai stato preso di mira. Esaminare i log delle applicazioni GitLab per i due indicatori di sfruttamento pubblicati da GitLab e indagare su attività sospette precedenti all’aggiornamento.

I difensori dovrebbero anche esaminare la telemetria del sistema operativo per:

• Processi child inaspettati originati da GitLab, Ruby o lavoratori associati
• Esecuzione di shell o interpreti di scripting sotto account di servizio GitLab
• Nuove chiavi SSH o account amministrativi
• Modifiche inaspettate ai repository o alle pipeline CI/CD
• Nuovi lavori pianificati o meccanismi di persistenza creati
• Modifiche a runner, token di distribuzione, token di accesso personale e token di accesso ai progetti
• Connessioni in uscita insolite dal server GitLab
• Accesso non autorizzato a segreti memorizzati nelle variabili CI/CD
• Modifiche inaspettate ai pacchetti, al rilascio o ai repository

Se si sospetta un compromesso, le organizzazioni dovrebbero isolare il server, preservare i log e gli artefatti forensi, ruotare le credenziali e i token potenzialmente esposti e convalidare l’integrità dei repository e dei flussi di lavoro CI/CD prima di riportare l’istanza in produzione.

Poiché le installazioni di GitLab spesso agiscono come infrastrutture fidate all’interno delle pipeline di sviluppo software, i rispondenti dovrebbero anche determinare se un attaccante potrebbe aver modificato il codice sorgente, gli artefatti, le immagini dei container, i template di infrastruttura come codice o i flussi di lavoro di distribuzione. Un server GitLab compromesso può creare un rischio di catena di fornitura a valle anche dopo che il server originale è stato riconcilato.

La piattaforma SOC Prime’s AI-Native Detection Intelligence può aiutare le organizzazioni a rafforzare la loro postura di rilevamento contro lo sfruttamento emergente delle vulnerabilità fornendo contenuti di rilevamento basati su comportamento continuamente aggiornati e mappati su MITRE ATT&CK®.

Disconoscimento di responsabilità: I contenuti di rilevamento potrebbero non essere disponibili per ogni CVE. Controllare la piattaforma SOC Prime per la copertura attuale. Se i rilevamenti pertinenti non sono ancora disponibili, tornare a controllare poiché nuove informazioni sulle minacce e contenuti di rilevamento sono continuamente aggiunti.