Un ricercatore di sicurezza ha pubblicato un proof-of-concept (PoC) per una vulnerabilità RCE in GitLab. La falla colpisce GitLab Community Edition ed Enterprise Edition. Gli utenti autenticati possono eseguire comandi arbitrari sul server come utente git.
La notizia è stata riportata da The Hacker News nel luglio 2026. Il ricercatore coinvolto si chiama Yuhang Wu, noto anche come depthfirst. La vulnerabilità riguarda le versioni self-managed di GitLab 18.x e 19.x.
Cosa è successo: la vulnerabilità GitLab RCE
Il meccanismo di exploit tramite Jupyter Notebook
Il vettore di attacco sfrutta i notebook Jupyter. Un utente autenticato carica un notebook appositamente modificato in un repository GitLab. Successivamente, visualizza il diff del commit contenente quel file.
In questo contesto, GitLab elabora il contenuto del notebook in modo non sicuro. Il risultato è l’esecuzione di comandi arbitrari sul server. I comandi vengono eseguiti con i privilegi dell’utente git.
Questo tipo di exploit è particolarmente insidioso. Non richiede privilegi amministrativi. Basta avere un account valido e accesso a un progetto.
Le versioni vulnerabili
Le versioni colpite dalla vulnerabilità GitLab RCE includono:
- 15.2.0 – 18.10.7
- 18.11.0 – 18.11.4
- 19.0.0 – 19.0.1
Tuttavia, le versioni patched sono già disponibili. GitLab ha rilasciato aggiornamenti per le branch 18.11 e 19.0. Gli amministratori devono aggiornare immediatamente.
Il contesto storico: GitLab e le RCE autenticate
CVE-2022-2884: un precedente importante
Questa non è la prima volta che GitLab affronta una vulnerabilità di questo tipo. In precedenza, CVE-2022-2884 aveva esposto le stesse edizioni CE/EE a un rischio analogo. In quel caso, il vettore era l’API di importazione da GitHub.
Un attaccante con un personal access token poteva inviare una richiesta HTTP modificata. Il payload veniva eseguito sul sistema GitLab durante il processo di importazione. SentinelOne e Trickest hanno documentato questa vulnerabilità in modo dettagliato.
Inoltre, il tracker interno di GitLab contiene un issue specifico denominato “RCE via github import”. Questo conferma che la classe di vulnerabilità è nota e ricorrente nell’ecosistema GitLab.
Un pattern che si ripete
Vale la pena sottolineare la continuità tra questi episodi. Le vulnerabilità RCE autenticate in GitLab seguono uno schema comune. Sfruttano funzionalità legittime della piattaforma. Le trasformano in vettori di attacco attraverso input non validati correttamente.
Di conseguenza, l’approccio difensivo non può limitarsi al patching. Le organizzazioni devono monitorare attivamente le attività anomale sulle istanze GitLab self-managed.
Impatto e rischi per le organizzazioni
Cosa può fare un attaccante dopo l’exploit
Una volta ottenuta l’esecuzione di codice remoto, le conseguenze sono gravi. L’attaccante opera come utente git sul sistema operativo sottostante. Questo gli consente di:
- Leggere il contenuto di tutti i repository ospitati sull’istanza
- Modificare o eliminare codice sorgente
- Accedere a segreti e credenziali presenti nei repository
- Spostarsi lateralmente verso altri sistemi collegati
In questo contesto, le istanze GitLab self-managed sono particolarmente esposte. Le istanze cloud gestite da GitLab.com sono invece già protette dalla patch del vendor.
Raccomandazioni per CISO e team di sicurezza
Parallelamente alla pubblicazione del PoC, il rischio di sfruttamento attivo aumenta significativamente. La disponibilità pubblica del codice proof-of-concept abbassa la soglia tecnica per gli attaccanti.
Le azioni immediate raccomandate sono:
- Aggiornare GitLab alle versioni corrette (18.11.5+ o 19.0.2+)
- Verificare i log di accesso per attività anomale sui diff dei commit
- Limitare l’accesso alle istanze self-managed tramite VPN o allowlist IP
- Riesaminare i permessi degli utenti autenticati sulle istanze critiche
- Attivare alert su upload inusuali di file Jupyter Notebook
Inoltre, è opportuno verificare se l’istanza sia già stata compromessa. La finestra temporale tra la divulgazione e il patching è critica.
Conclusioni
La pubblicazione del PoC per questa vulnerabilità GitLab RCE rappresenta un campanello d’allarme. Le falle autenticate sono spesso sottovalutate rispetto a quelle non autenticate. Tuttavia, in ambienti aziendali, un account compromesso è uno scenario realistico.
Il caso dimostra ancora una volta l’importanza della threat intelligence continua. Monitorare le pubblicazioni dei ricercatori di sicurezza consente di anticipare gli attori malevoli. La finestra tra PoC e exploit attivo si misura ormai in ore, non giorni.
Fonti:
- The Hacker News – Researcher Publishes GitLab RCE PoC
- SentinelOne – CVE-2022-2884
- Trickest – CVE-2022-2884
- GitLab Issue Tracker – RCE via GitHub Import
Fonte: Articolo originale
La pubblicazione di un PoC per vulnerabilità come questa GitLab RCE evidenzia quanto sia critica la capacità di condividere threat intelligence in tempo reale tra le organizzazioni. IsacChain consente la condivisione sicura e verificata di indicatori di compromissione e advisory tecnici tra ISAC e operatori di infrastrutture critiche, supportando al contempo la compliance NIS2 in modo automatizzato. Ogni informazione condivisa è tracciata e immutabile grazie alla verifica blockchain, garantendo integrità e non ripudio dei dati. Scopri come IsacChain può aiutare la tua organizzazione su www.isacchain.com