CVE-2026-3854: RCE su GitHub, aggiornare Enterprise ora
Falla nelle push options di GitHub: RCE su Enterprise Server. Patch disponibili, ma il disclosure del 28 aprile espone le istanze non aggiornate.
Contenuto
GitHub e GitHub Enterprise Server sono affetti da una vulnerabilità RCE catalogata come CVE-2026-3854. I dettagli tecnici sono stati resi pubblici il 28 aprile 2026, dopo che la correzione per l'ambiente cloud era stata applicata il 4 marzo. Per le organizzazioni che gestiscono istanze on-premise, la disclosure pubblica espone ora il rischio concreto di weaponization contro i server Enterprise non ancora aggiornati.
- La falla risiede in una gestione impropria delle push options durante le operazioni di git push, con sanitizzazione insufficiente del carattere delimitatore (;).
- Un utente autenticato con permessi di scrittura su un repository può ottenere l'esecuzione di codice con i privilegi dell'utente di servizio git.
- Le versioni di GitHub Enterprise Server che risolvono la vulnerabilità sono 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 e 3.20.0.
- Si raccomanda l'analisi del file /var/log/github-audit.log per individuare push contenenti parametri anomali o caratteri inattesi.
Il meccanismo tecnico: injection nel delimitatore e flusso X-Stat
Il vettore d'attacco si nasconde nelle push options, i metadati che il client git può inviare al server durante una operazione di push. L'inserimento di un carattere delimitatore (;) non sanitizzato all'interno di queste opzioni consente di iniettare parametri interni aggiuntivi. Il flusso X-Stat, responsabile del parsing server-side di tali metadati, interpreta erroneamente i campi iniettati come parametri validi, attivando una catena che porta all'esecuzione di codice.
La vulnerabilità non richiede privilegi amministrativi. È sufficiente disporre di un account autenticato con permessi di scrittura sul repository bersaglio per raggiungere il server e ottenere l'esecuzione di codice nel contesto dell'utente di servizio git. Questo livello di accesso, tipicamente assegnato a sviluppatori e contributor interni, riduce la superficie di attacco solo apparentemente: una volta ottenuta una shell, il rischio di movimento laterale all'interno dell'istanza Enterprise diventa concreto.
Un utente autenticato con permessi di scrittura su un repository può ottenere l'esecuzione di codice con i privilegi dell'utente di servizio git.
Cloud patchato a marzo, Enterprise scoperto ad aprile
La correzione per l'ambiente cloud di GitHub è stata applicata il 4 marzo 2026. I dettagli tecnici della vulnerabilità sono stati resi pubblici il 28 aprile 2026. Questo intervallo di oltre sette settimane è stato probabilmente utilizzato per consentire alle organizzazioni con installazioni on-premise di pianificare l'aggiornamento prima che il meccanismo di attacco diventasse di dominio pubblico.
Con la disclosure del 28 aprile, il codice proof-of-concept e la spiegazione tecnica del flusso X-Stat sono ora accessibili. Per le istanze di GitHub Enterprise Server che non hanno ancora applicato le patch rilasciate, questo significa che un potenziale attaccante dispone di tutti gli elementi necessari per replicare l'attacco in un ambiente controllato e successivamente puntare a target non aggiornati. Il rischio di weaponization è quindi passato da teorico a praticamente immediato.
Release corrette e profilo dell'attaccante
Le versioni di GitHub Enterprise Server che risolvono la vulnerabilità sono state identificate con precisione: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 e 3.20.0. Le aziende che utilizzano release precedenti a queste devono considerare l'aggiornamento come una priorità assoluta, poiché l'esposizione cloud è già stata chiusa e la finestra di protezione offerta dalla segretezza tecnica si è chiusa il 28 aprile.
L'attaccante ideale per questa falla è un utente già autenticato nel sistema, munito di permessi di scrittura su almeno un repository ospitato nell'istanza Enterprise. Non è richiesta l'interazione della vittima né l'escalation iniziale di privilegi. Questo profilo rende la minaccia particolarmente insidiosa per ambienti che gestiscono repository interni con accesso esteso a team di sviluppo, fornitori o contractor che operano con credenziali aziendali valide.
Cosa fare adesso: verifica dei log e aggiornamento
Per chi gestisce istanze on-premise di GitHub Enterprise Server, il primo passo è verificare la release in esecuzione e pianificare l'aggiornamento a una delle versioni corrette: 3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.7, 3.19.4 o 3.20.0. L'aggiornamento non può essere rimandato, dato che la disclosure pubblica fornisce a potenziali aggressori la mappa tecnica completa della falla.
Parallelamente, è necessario analizzare il file /var/log/github-audit.log per individuare push contenenti parametri anomali o caratteri inattesi. L'attenzione deve concentrarsi sulle operazioni effettuate da account autenticati con permessi di scrittura, poiché solo questi profili possono attivare il flusso X-Stat vulnerabile. Eventuali entry che mostrino l'utilizzo del carattere ; all'interno delle push options meritano un'ispezione approfondita.
Le organizzazioni dovrebbero inoltre ricostruire, attraverso i log di auditing, la cronologia delle operazioni di push avvenute nel periodo compreso tra la correzione cloud e la disclosure pubblica. Se un attaccante avesse già ottenuto accesso a credenziali valide, potrebbe aver sondato o sfruttato la falla prima che i dettagli diventassero noti. Non esistono al momento conferme di sfruttamento attivo in-the-wild, ma la mancanza di evidenze pubbliche non esclude scenari di accesso stealth.
Infine, chi opera istanze cloud gestite direttamente da GitHub deve confermare che la correzione del 4 marzo sia effettivamente attiva nel proprio perimetro, anche se l'infrastruttura SaaS non è sotto il controllo diretto del team interno. Per le installazioni Enterprise on-premise, l'assenza di un piano di aggiornamento entro le prossime ore espone l'intera pipeline di sviluppo a un rischio di compromissione concreto e documentato.
La disclosure ritardata rispetto alla correzione cloud ha senso solo se le aziende on-premise completano il ciclo di patching. Lasciare scoperto il flusso X-Stat dopo il 28 aprile significa offrire a un attaccante autenticato una superficie di attacco riproducibile e ormai pubblica. In questo scenario, la velocità di aggiornamento diventa l'unico controllo di sicurezza in grado di fare la differenza tra un incidente evitato e una compromissione.
Domande frequenti
GitHub.com è ancora vulnerabile?
No. La correzione per l'ambiente cloud è stata applicata il 4 marzo 2026. La vulnerabilità interessa ora principalmente le istanze on-premise di GitHub Enterprise Server che non sono state aggiornate.
Chi ha scoperto e segnalato la falla?
L'identità del ricercatore o dell'entità che ha scoperto e segnalato la vulnerabilità non è stata resa pubblica nell'advisory disponibile.
Sono necessari privilegi amministrativi per sfruttare la falla?
No. È sufficiente disporre di un account autenticato con permessi di scrittura su un repository. Questo requisito, più basso rispetto a quello di un amministratore, espone la minaccia a una popolazione più ampia di utenti interni ed esterni.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.