Allerta GitLab: exploit pubblico per vulnerabilità critica RCE, il fix era nascosto in un bug ordinario

Introduzione

Il 24 luglio 2026 il team di ricerca depthfirst ha pubblicato un exploit completo per una vulnerabilità critica di esecuzione codice remoto (RCE) che colpisce GitLab Community Edition (CE) ed Enterprise Edition (EE) auto-ospitate. La falla consente a un utente autenticato con permessi di push di ottenere una shell sul server con i privilegi del processo git, semplicemente caricando un notebook Jupyter malevolo. La particolarità più allarmante è che GitLab aveva già distribuito una correzione il 10 giugno scorso, ma l’aveva classificata come un semplice “bug fix” ordinario, omettendola dalla tabella degli aggiornamenti di sicurezza. Di conseguenza, molti amministratori potrebbero non aver applicato la patch, lasciando esposte migliaia di istanze a un attacco ora facilitato dalla disponibilità pubblica del codice offensivo.

Analisi tecnica

La vulnerabilità risiede in due distinti bug di corruzione della memoria nel parser JSON nativo Oj (Optimized JSON), una gemma Ruby ampiamente utilizzata. Le versioni di Oj precedenti alla 3.17.3 non gestiscono correttamente alcune strutture JSON complesse, causando overflow e letture fuori limite. In GitLab, il componente ipynbdiff – incaricato di mostrare le differenze tra versioni di notebook Jupyter (file .ipynb) – utilizza internamente Oj::Parser.usual.parse per processare il contenuto dei file. Un attaccante con accesso in scrittura a un repository può creare un notebook appositamente manipolato e caricarlo tramite push. Quando qualsiasi utente (incluso l’attaccante stesso) visualizza il diff del notebook nell’interfaccia web, il parser vulnerabile viene eseguito e il payload contenuto nel file prende il controllo.

L’exploit rilasciato da depthfirst opera in due fasi:

1. Leak di memoria: sfruttando il primo bug, il payload costringe il parser a rivelare indirizzi di memoria, bypassando l’ASLR (Address Space Layout Randomization).
2. Esecuzione arbitraria: attraverso heap-spray, viene iniettato shellcode che modifica il flusso di esecuzione del processo Puma (il server applicativo di GitLab) per eseguire comandi scelti dall’attaccante.

L’exploit è ottimizzato per GitLab 18.11.3 su architettura x86-64. Su installazioni fresche il processo richiede alcuni minuti, mentre su server long-running può impiegare ore a causa della frammentazione della memoria heap. L’adattamento ad altre build x86-64 è relativamente semplice (richiede solo l’aggiornamento di offset e gadget ROP), mentre il porting su ARM64 comporta una riscrittura significativa.

Le versioni GitLab vulnerabili sono:

• dalla 15.2.0 alla 18.10.7
• dalla 18.11.0 alla 18.11.4
• dalla 19.0.0 alla 19.0.1

Le correzioni sono state introdotte con il rilascio di Oj 3.17.3 (4 giugno 2026) e integrate nelle successive versioni di GitLab: 18.10.8, 18.11.5 e 19.0.2. All’interno di GitLab è stato anche modificato ipynbdiff per utilizzare parser più robusti, eliminando il percorso di attacco.

Impatto

Ottenere una shell come utente git sul server GitLab significa compromettere pressoché totalmente la piattaforma. L’attaccante può:

• Leggere e alterare tutto il codice sorgente ospitato.
• Accedere ai segreti Rails (chiavi di crittografia, token di sessione) e alle credenziali di servizio (database, integrazioni esterne).
• Raccogliere variabili d’ambiente CI/CD, token di accesso e potenzialmente muoversi lateralmente verso altri servizi raggiungibili dall’host.
• Modificare pipeline CI/CD per distribuire payload malevoli o esfiltrare dati su larga scala.

Anche se il processo attaccato è confinato all’utente git, la portata del danno dipende dall’isolamento del contenitore o della macchina virtuale su cui GitLab è eseguito. Le istanze che girano su versioni non più mantenute (dalla 15.2 alla 18.9) non ricevono backport: restano vulnerabili senza alcuna correzione ufficiale, a meno di una migrazione forzata a una release supportata. Al 24 luglio non si registravano attacchi attivi in-the-wild, ma la pubblicazione dell’exploit cambia radicalmente il panorama delle minacce.

Mitigazione

La priorità assoluta è applicare immediatamente l’aggiornamento a una delle versioni contenenti la correzione:

• GitLab 18.10.8
• GitLab 18.11.5
• GitLab 19.0.2 (o successive)

Gli amministratori che si affidano esclusivamente alla tabella riepilogativa dei “security fix” nei release post potrebbero non aver installato la patch del 10 giugno, poiché GitLab l’ha etichettata come “bug fix”. Si raccomanda pertanto di verificare manualmente la versione in uso, specialmente in ambienti con politiche di aggiornamento selettive.

Per distribuzioni Helm o Operator su Kubernetes, è fondamentale controllare la versione dell’immagine del servizio Webservice (che esegue Puma) e non quella del chart o dell’Operator, poiché quest’ultima potrebbe mascherare una componente obsoleta.

Non esiste un workaround ufficiale o convalidato per chi non può aggiornare immediatamente. Limitare l’accesso ai repository e al rendering dei diff di notebook solo a utenti strettamente fidati riduce la superficie d’attacco, ma GitLab non fornisce un’opzione documentata per disabilitare completamente il percorso vulnerabile. Per indicazioni specifiche, si consiglia di contattare il supporto GitLab.

FAQ

1. Quali versioni di GitLab sono esattamente interessate?
Sono vulnerabili tutte le versioni autogestite dalla 15.2.0 fino alla 18.10.7, dalla 18.11.0 alla 18.11.4 e dalla 19.0.0 alla 19.0.1. Le release precedenti alla 15.2.0 utilizzano parser differenti e non sono esposte. Le versioni 18.10.8, 18.11.5, 19.0.2 e successive contengono il fix.

2. Come posso verificare se la mia istanza è stata già compromessa?
Al momento non sono stati diffusi indicatori di compromissione (IoC) pubblici. Tuttavia, data la natura dell’attacco (esecuzione di comandi arbitrari come git), si consiglia di monitorare i log di sistema per processi insoliti, connessioni di rete in uscita anomale o modifiche inattese ai file di configurazione di GitLab. L’assenza di segnalazioni non garantisce che il sistema sia pulito: l’aggiornamento tempestivo resta la contromisura essenziale.

3. Perché GitLab non ha emesso un avviso di sicurezza con un CVE?
Al momento della pubblicazione dell’exploit, GitLab non aveva ancora commentato la scelta di classificare il fix come “bug ordinario”. Solitamente vulnerabilità di questa gravità ricevono un identificatore CVE e vengono elencate nella sezione sicurezza del release post. La mancanza di trasparenza ha probabilmente esteso il periodo di esposizione per molti amministratori. Si attendono ulteriori comunicazioni ufficiali.