CVE-2026-3854: RCE su GitHub, circa l'88% server on-premise vulnerabili
Wiz Research scopre CVE-2026-3854: RCE su GitHub tramite push options e iniezione X-Stat. Circa l'88% delle istanze Enterprise è ancora esposto.
Contenuto
Wiz Research ha pubblicato il 28 aprile 2026 i dettagli tecnici di CVE-2026-3854, una vulnerabilità critica nella pipeline git interna di GitHub che consente esecuzione di codice remota tramite l’iniezione di push options non sanificate nell’header X-Stat. La scoperta, ottenuta mediante reverse engineering assistito da intelligenza artificiale su binari closed-source, ha già determinato la correzione su GitHub.com, ma lascia scoperte circa l’88% delle istanze GitHub Enterprise Server on-premise al momento della disclosure.
- La vulnerabilità CVE-2026-3854 consente RCE su GitHub.com e compromissione totale delle istanze GitHub Enterprise Server manipolando l’header interno X-Stat tramite push options.
- Wiz Research ha dimostrato la catena di attacco con analisi binaria e wire capture su GHES, rivelando una semantica last-write-wins nel parsing semicolon-delimited dell’header.
- GitHub ha mitigato il rischio su GitHub.com in circa 6 ore dalla segnalazione, ma le patch per GHES non risultano applicate nella maggior parte delle installazioni.
- L’exploit richiede un utente autenticato con permessi di scrittura su un repository e consente di alterare variabili come rails_env per bypassare la sandbox degli hook.
Da git push a esecuzione remota: il percorso dell’iniezione X-Stat
La falla si annida nel passaggio di dati tra i servizi interni della piattaforma. Durante un push, il componente babeld riceve le opzioni specificate dal client e le inoltra verso gitrpcd attraverso un header chiamato X-Stat, strutturato come mappa di campi delimitati da punto e virgola. I ricercatori di Wiz hanno dimostrato che i valori delle push option vengono incorporati nell’header senza escaping del carattere separatore, consentendo di iniettare coppie chiave-valore arbitrarie.
La mappa che parsa l’header adotta una semantica last-write-wins: se un aggressore invia una push option contenente un punto e virgola seguito da variabili critiche, queste sovrascrivono le impostazioni originali. Modificando parametri come rails_env o custom_hooks_dir, l’attaccante disabilita la sandbox dei pre-receive hook e ottiene esecuzione diretta come utente git sul nodo sottostante. Il comando dimostrativo dal CERT-AGID è sintomatico: git push origin main -o "x;rails_env=nonprod".
Reverse engineering con AI su binari closed-source
Il metodo investigativo rappresenta un aspetto rilevante della ricerca. Wiz Research ha applicato tecniche di reverse engineering assistite da modelli di intelligenza artificiale per analizzare i binari closed-source di GitHub, estraendo la logica di serializzazione dell’header X-Stat senza accesso al codice sorgente. L’operazione ha permesso di ricostruire il flusso dati da babeld a gitrpcd fino agli hook di pre-ricezione, individuando il punto esatto di mancata sanificazione.
L’uso dell’intelligenza artificiale in questa fase abbassa sensibilmente la soglia di costo e tempo per l’analisi di sistemi complessi black-box, aprendo questioni sul livello di sicurezza delle pipeline di hosting del codice anche presso vendor di prima grandezza. La dimostrazione pratica su GitHub.com ha confermato l’esecuzione di codice su nodi storage condivisi con accesso a milioni di repository pubblici e privati, prima che la mitigazione del 4 marzo 2026 intervenisse.
L’impatto su GitHub Enterprise Server: compromissione totale
Su GitHub Enterprise Server la gravità si traduce in esposizione completa del server. Una volta aggirata la sandbox tramite l’iniezione descritta, l’aggressore può compromettere l’intera istanza on-premise e accedere al codice sorgente di tutti i repository ospitati. A differenza dell’ambiente cloud, mitigato in circa 6 ore dalla segnalazione, le installazioni locali dipendono dagli amministratori per l’applicazione degli aggiornamenti rilasciati da GitHub per le versioni supportate.
Il dato più preoccupante emerge dalla misurazione di Wiz: al momento della pubblicazione del report, circa l’88% delle istanze GHES risultava ancora vulnerabile. Non è noto quante installazioni siano state analizzate per ottenere questa percentuale, né se l’exploit sia stato sfruttato attivamente prima della patch del 4 marzo 2026. La combinazione di elevata gravità e bassa adozione delle correzioni rende lo scenario particolarmente critico per le aziende che mantengono il codice in infrastrutture interne.
"at the time of this writing, our data indicates that 88% of instances are still vulnerable"
— Wiz Research
Cosa fare adesso
Le organizzazioni che utilizzano GitHub Enterprise Server devono agire immediatamente per ridurre la superficie di attacco e scongiurare compromissioni della propria proprietà intellettuale.
- Aggiornare GHES alle versioni corrette rilasciate da GitHub per tutte le release ancora supportate, applicando la patch senza ulteriore ritardo.
- Ispezionare i log dei servizi git e le attività di push sui repository critici alla ricerca di opzioni anomale o pattern contenenti punti e virgola prima della correzione.
- Limitare temporaneamente i permessi di scrittura sui repository sensibili dove l’installazione dell’aggiornamento non possa avvenire immediatamente.
- Monitorare gli alert del CERT-AGID e le comunicazioni ufficiali di GitHub per eventuali aggiornamenti sulle versioni interessate e indicatori di compromissione.
La scoperta di Wiz sposta il mirino dall’errore individuale alla robustezza delle pipeline che muovono il codice tra servizi distribuiti. Se l’intelligenza artificiale rende più accessibile l’analisi dei sistemi black-box, le piattaforme di hosting devono corrispondere con visibilità interna e sanificazione rigorosa dei confini tra componenti. Per le aziende che gestiscono codice su server propri, il tempo tra patch disponibile e patch applicata resta la variabile più pericolosa.
Domande frequenti
Qual è la differenza di rischio tra GitHub.com e GitHub Enterprise Server?
GitHub.com è stato mitigato in circa 6 ore dalla segnalazione e la correzione definitiva è stata applicata il 4 marzo 2026. GitHub Enterprise Server, invece, richiede l’intervento manuale degli amministratori e circa l’88% delle istanze risultava ancora vulnerabile al momento della disclosure.
Perché così tante istanze on-premise sono ancora esposte?
Le installazioni locali dipendono dai cicli di manutenzione interni degli utenti e non ricevono aggiornamenti automatici come l’ambiente cloud. Non è noto il numero esatto di istanze analizzate da Wiz, ma la percentuale rivela una diffusione della patch molto più lenta rispetto alla disponibilità del fix.
L’attacco può essere portato da chiunque?
No. L’exploit richiede necessariamente un utente autenticato con permessi di scrittura su un repository. Tuttavia, una volta soddisfatta questa condizione, la compromissione su GHES consente accesso al codice di tutti i repository ospitati sullo stesso server.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.