CVE-2026-3854: RCE su GitHub con un solo comando git push

Un singolo git push craftato esegue codice remoto su GitHub.com e Enterprise Server. Il fix cloud è attivo, ma quasi il 90% delle istanze on-prem restava a ris…

Contenuto

CVE-2026-3854: RCE su GitHub con un solo comando git push
CVE-2026-3854: RCE su GitHub con un solo comando git push

Wiz Research ha pubblicato il 28 aprile 2026 i dettagli tecnici di CVE-2026-3854, una vulnerabilità di esecuzione remota di codice che colpisce GitHub.com e GitHub Enterprise Server tramite un singolo comando git push con opzioni malevole. La falla sfrutta la mancata sanitizzazione del delimitatore ; nell'header interno X-Stat per sovrascrivere parametri di sicurezza e compromettere l'intera istanza, inclusi i nodi storage condivisi in cloud. Sebbene GitHub abbia già chiuso la breccia sui propri sistemi cloud il 4 marzo 2026 in meno di sei ore dalla segnalazione, al momento della disclosure quasi l'88% delle istanze on-premise risultava ancora vulnerabile, rendendo urgente l'applicazione delle patch.

Punti chiave
  • Un singolo comando git push con opzioni craftate consente l'iniezione di campi nell'header interno X-Stat tramite il delimitatore ;, sfruttando la semantica last-write-wins dei parser downstream.
  • Su GitHub.com la catena ha permesso RCE su nodi storage condivisi con rischio cross-tenant; su GitHub Enterprise Server consente il bypass della sandbox e il pieno controllo del server.
  • Il fix cloud è stato deployato il 4 marzo 2026 in meno di sei ore dalla segnalazione, ma i dettagli tecnici sono stati pubblicati il 28 aprile 2026 per dare tempo alle installazioni on-premise di aggiornarsi.
  • Alla data della disclosure quasi l'88% delle istanze GitHub Enterprise Server era ancora vulnerabile; GitHub afferma di non aver rilevato exploitation malevola al di fuori dei test controllati dei ricercatori Wiz.

Così una git push sovrascrive i parametri di sicurezza

Il cuore della falla sta in un errore di parsing tra il front-end git e i servizi interni di GitHub. Quando un utente autenticato invia una push con opzioni craftate, il componente babeld inserisce i valori push_option_x nell'header interno X-Stat senza rimuovere il carattere ; usato come separatore. Se l'attaccante inserisce un punto e virgola nel valore dell'opzione, genera campi aggiuntivi che i servizi a valle interpretano come parametri legittimi.

A valle, il parser del servizio gitrpcd e del pre-receive hook applicano una logica last-write-wins: l'ultimo campo con lo stesso nome sovrascrive i precedenti. Iniettando rails_env, custom_hooks_dir e repo_pre_receive_hooks, l'attaccante sostituisce la configurazione di sicurezza prevista con valori arbitrari, passando da un ambiente sandboxato a un'esecuzione diretta come utente di servizio git.

Wiz ha trovato la vulnerabilità analizzando i binari closed-source della pipeline git di GitHub con strumenti di reverse engineering assistiti da intelligenza artificiale, in particolare IDA MCP. L'approccio ha permesso di mappare il flusso dei metadati tra servizi scritti in linguaggi diversi, individuando la discrepanza esatta nel trattamento del delimitatore interno.

Da sandbox bypassata a pwnaggio totale del server

Sull'istanza on-premise, il pre-receive hook gestisce due percorsi di esecuzione in base al valore di rails_env. In condizioni normali il valore di produzione attiva una sandbox che limita i comandi; sovrascrivendolo con qualsiasi altro valore, il sistema esegue il codice direttamente come utente git, bypassando i vincoli di sicurezza. Da qui è possibile caricare hook arbitrari e prendere il controllo completo del server.

Avere esecuzione non sandboxed come utente git significa accesso completo al filesystem, lettura e scrittura inclusi, e visibilità sulla configurazione dei servizi interni. Il ricercatore Sagi Tzadik di Wiz ha descritto lo scenario come un pwnaggio totale dell'istanza GHES, con possibilità di movimento laterale e persistenza a livello di piattaforma.

Sulla versione cloud GitHub.com la stessa catena ha permesso l'esecuzione di codice su nodi storage condivisi tra più tenant. Secondo Wiz, questo ha esposto oltre un milione di repository pubblici e privati a rischio di accesso cross-tenant, anche se GitHub ha dichiarato di non aver rilevato exploitation malevola al di fuori dei test controllati dei ricercatori.

"With unsandboxed code execution as the git user, we had full control over the GHES instance, including filesystem read/write access and visibility into internal service configuration" — Sagi Tzadik, Wiz security researcher (via The Hacker News)

Il 4 marzo e il 28 aprile: due date che raccontano la risposta

Il report di Wiz è stato inviato a GitHub e la compagnia ha riprodotto il bug in circa 40 minuti, identificando la root cause alle 17:45 UTC del 4 marzo 2026. La coordinazione tra i team ha permesso di isolare il problema prima che i dettagli tecnici diventassero pubblici, limitando la finestra di rischio sul cloud.

La mitigazione su GitHub.com è stata deployata in poche ore dalla segnalazione: The Hacker News parla di circa 2 ore, mentre Wiz indica un intervallo massimo di 6 ore. Questa discrepanza minore non altera l'ordine di grandezza della risposta, che è risultata tempestiva rispetto alla criticità della falla.

GitHub ha poi osservato un intervallo di quasi sette settimane per consentire agli amministratori di GitHub Enterprise Server di applicare le patch prima della disclosure completa. I dettagli tecnici sono stati resi pubblici il 28 aprile 2026, con il CERT-AGID che ha diffuso un advisory governativo italiano nelle ore successive alla pubblicazione dei ricercatori.

Cosa fare adesso

Gli amministratori di GitHub Enterprise Server devono aggiornare immediatamente alle versioni corrette: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7 o 3.18.8, 3.19.4, 3.20.0 o successive. Ogni istanza non patchata rimane esposta alla catena RCE descritta, con compromissione totale del server come conseguenza diretta.

È necessario esaminare i log di audit delle push git degli ultimi mesi alla ricerca di opzioni anomale che contengano il carattere ; o valori inattesi per rails_env e custom_hooks_dir. Poiché l'exploit richiede permessi di push e autenticazione, il controllo deve concentrarsi su utenti interni o compromessi con accesso in scrittura ai repository.

Dopo il patching, si raccomanda di verificare che non siano presenti hook pre-receive non autorizzati o modifiche persistenti nella directory custom_hooks_dir. Un attaccante potrebbe aver sfruttato la finestra pre-disclosure per installare backdoor silenziose, anche se GitHub afferma di non aver rilevato exploitation malevola al di fuori dei test controllati.

Infine, le organizzazioni dovrebbero monitorare i processi eseguiti dall'utente di servizio git alla ricerca di variazioni anomale dell'ambiente rails_env o di esecuzioni fuori dalla sandbox prevista. Questo controllo è particolarmente rilevante per le istanze GHES che non possono essere aggiornate tempestivamente per vincoli di change management.

Quando la fiducia tra servizi diventa un attacco

Il caso CVE-2026-3854 dimostra che l'input autenticato non è sufficientemente sicuro quando attraversa confini di trust tra servizi scritti in linguaggi diversi con parser leggermente diversi. Una feature git standard come le push options, completamente legittima per l'utente, si è trasformata in un vettore di RCE perché il sistema interno non ha mai previsto che quel delimitatore potesse essere reinserito dal payload stesso.

Il paradosso è che la pipeline di GitHub non si fidava dell'utente esterno, ma si è fidata ciecamente del proprio metadato interno X-Stat, trattandolo come sicuro per definizione. L'intelligenza artificiale nel reverse engineering ha accelerato la scoperta, ma la lezione architetturale resta umana: ogni delimitatore di protocollo interno deve essere trattato con la stessa diffidenza riservata all'input raw da internet.

La vulnerabilità non nasce da un difetto crittografico o da un errore di autenticazione, ma da un'igiene del parsing trascurata tra componenti che si presumevano affidabili. Per le aziende con GHES on-premise, il rischio non si esaurisce con il patching: la priorità immediata è verificare che nessuno abbia sfruttato il gap temporale tra il fix cloud e la disclosure per lasciare una porta aperta. Nel breve termine, la metrica più rilevante non è la scala di severità formale, ma la percentuale di istanze ancora esposte.

Domande frequenti

L'attacco richiede un client git modificato o privilegi speciali?
No. L'exploit funziona con un client git standard; l'unico requisito è un utente autenticato con permesso di push sul repository target. Non sono necessari privilegi amministrativi a livello di piattaforma.

Gli utenti di GitHub.com devono ancora intervenire?
No. La correzione è stata applicata lato server il 4 marzo 2026. Gli utenti del servizio cloud non devono installare patch né modificare configurazioni; il rischio attuale riguarda esclusivamente le installazioni on-premise non aggiornate.

Perché la pubblicazione dei dettagli tecnici è avvenuta settimane dopo il fix cloud?
GitHub ha atteso circa sette settimane per permettere agli amministratori di GitHub Enterprise Server di installare gli aggiornamenti prima che il metodo di exploit diventasse pubblico e facilmente replicabile da eventuali attori malevoli.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews