# Indiscrezione: ricercatore pubblica exploit per vulnerabilità RCE in GitLab URL: https://menteinformatica.it/sicurezza-privacy/gitlab-rce-exploit-patch-invisibile/ Autore: Giorgio Perillo Aggiornato: 2026-10-02 Categoria: Sicurezza e Privacy --- Un ricercatore ha pubblicato **codice exploit funzionante** per una vulnerabilità di esecuzione remota di codice in GitLab. Secondo quanto riportato da The Hacker News, il [codice proof-of-concept](https://github.com/wupco/gitlab-rce-demo) è stato reso pubblico il 24 luglio e [colpisce i server](https://menteinformatica.it/sicurezza-privacy/falla-cpanel-ransomware-sorry-attacco/) self-managed alla versione **18.11.3** che non hanno ancora applicato l’aggiornamento rilasciato sei settimane prima. Il punto critico non è solo la vulnerabilità: è che GitLab non avrebbe etichettato il fix come correzione di sicurezza. A quanto emerge dalla ricostruzione di The Hacker News, la patch sarebbe comparsa nella [release del 10 giugno](https://docs.gitlab.com/releases/patches/patch-release-gitlab-19-0-2-released/) semplicemente come aggiornamento della libreria Ruby **Oj alla versione 3.17.3**, senza CVE, senza punteggio CVSS e senza alcun riferimento alla catena di attacco scoperta dai ricercatori. ## Come funzionerebbe l’attacco sulla catena Oj La vulnerabilità sfrutterebbe **due bug di corruzione della memoria** in Oj, un parser JSON per Ruby implementato in C nativo. GitLab usa questa libreria nel renderer di notebook Jupyter: un componente chiamato ipynbdiff passerebbe il JSON dei file .ipynb direttamente al parser, dentro un processo Puma a lunga vita. La catena di attacco descritta dai ricercatori di depthfirst prevede tre fasi. Prima si carica un notebook Jupyter appositamente costruito e si apre il diff del commit: questo farebbe trapelare un puntatore heap. Ripetendo l’operazione abbastanza volte, un attaccante potrebbe mappare la posizione delle librerie in memoria. Due notebook successivi completerebbero poi l’esecuzione del payload. - Nessun privilegio di amministratore richiesto - Nessun accesso a runner o pipeline CI/CD - Nessuna interazione da parte di altri utenti - Sufficiente avere accesso in push a un qualsiasi progetto In altre parole: **qualsiasi utente autenticato** con permessi di push potrebbe sfruttare la falla per eseguire comandi come utente git sul server. ## Il problema vero: un fix invisibile per sei settimane Questo è il nodo che conta davvero per chi gestisce istanze self-managed. Gli amministratori che hanno analizzato la release di giugno guardando la tabella dei fix di sicurezza non avrebbero trovato nulla di allarmante: il bump di Oj era classificato come correzione di bug ordinaria. Nessun bollettino separato, nessun identificativo CVE a cui associare una priorità. Un fix di sicurezza seppellito tra i bug ordinari, senza CVE né avviso esplicito, è quasi equivalente a nessun fix per chi gestisce decine di server. Le [correzioni nella libreria Oj](https://github.com/ohler55/oj/pull/1014) erano già state integrate a monte, ma la catena completa che porta all’RCE su GitLab non era documentata pubblicamente. Questo ha lasciato un intervallo di sei settimane in cui i server vulnerabili erano esposti senza che gli operatori avessero ragione di agire con urgenza. Secondo The Hacker News, **perché conta:** Chi gestisce un’istanza GitLab self-managed alla versione 18.11.3 o precedente dovrebbe verificare immediatamente di aver applicato la patch del 10 giugno. Con il codice exploit ora pubblico, il rischio di sfruttamento attivo aumenta in modo significativo. GitLab dovrebbe chiarire la propria politica di comunicazione per i fix di sicurezza nascosti in aggiornamenti di dipendenze: è probabile che nei prossimi giorni arrivi un bollettino ufficiale con un CVE dedicato, ma al momento non risulta ancora pubblicato. Fonte: [thehackernews.com](https://thehackernews.com/2026/07/researcher-publishes-gitlab-rce-poc.html).