RCE in GitHub: un solo git push esegue codice sui server backend

RCE in GitHub: un solo git push esegue codice sui server backend

Il 28 aprile 2026 Wiz Research ha reso pubblica la vulnerabilità RCE CVE-2026-3854 che colpisce GitHub.com e GitHub Enterprise Server. Un utente autenticato con soli permessi di scrittura può eseguire codice arbitrario sui server backend con un singolo git push manipolato, sfruttando la mancata sanitizzazione del delimitatore ; nell’header interno X-Stat. La disclosure arriva a quasi un mese dalla correzione su cloud, ma rivela che quasi il 90% delle istanze on-premise rimaneva ancora esposto, trasformando una falla già patchata in un rischio attivo per la supply chain.

"A single git push command was enough to exploit a flaw in GitHub's internal protocol and achieve code execution on backend infrastructure" — Wiz Research

X-Stat e il delimitatore dimenticato: anatomia della falla

Il nucleo del difetto risiede nel componente babeld, che gestisce le operazioni git sui server GitHub. Quando un utente invia un push con opzioni personalizzate — parametri legittimi usati per attivare hook o configurazioni CI — babeld le inserisce direttamente nell’header interno X-Stat senza rimuovere o codificare il carattere punto e virgola. Poiché il protocollo multi-servizio usa proprio il ; come delimitatore dei campi, un attaccante può iniettare coppie chiave-valore arbitrarie che i servizi a valle interpreteranno come parametri legittimi, sovrascrivendo quelli originali con logica last-write-wins.

L’header X-Stat funge da canale di metadati tra servizi scritti in linguaggi diversi; ogni modulo assume che il contenuto sia già affidabile. Questa assenza di validazione incrociata trasforma una funzione ausiliaria in un vettore di attacco capace di modificare il comportamento del motore di esecuzione dei hook. L’injection non richiede privilegi amministrativi: basta l’accesso in scrittura a un repository, condizione comune a collaboratori e bot di integrazione in migliaia di organizzazioni.

Dalla sandbox all'RCE: la catena di tre injection

Wiz Research ha dimostrato una catena di exploit in tre fasi. La prima injection imposta rails_env=nonprod, spostando l’esecuzione dell’hook da un ambiente sandboxato a uno non protetto. La seconda sovrascrive custom_hooks_dir con un percorso controllato dall’attaccante, indicando dove il server cercherà gli script da eseguire. La terza definisce repo_pre_receive_hooks, attivando il codice malevolo prima che il push venga accettato.

Con l’esecuzione non sandboxata come utente git, l’attaccante ottiene controllo completo sull’istanza: lettura e scrittura del filesystem, accesso alle configurazioni interne dei servizi e visibilità sui secret del nodo. Su GitHub.com i nodi storage colpiti erano condivisi tra più tenant; Wiz ha verificato che milioni di repository pubblici e privati di altri utenti risiedevano fisicamente sullo stesso server, aprendo a un rischio di cross-contaminazione massiccio e silenzioso.

AI nel black-box: come Wiz ha letto i binari di GitHub

L’aspetto rivoluzionario della scoperta non è solo la gravità della falla, ma il metodo. Wiz Research ha impiegato strumenti di reverse engineering assistiti da intelligenza artificiale, in particolare IDA MCP, per analizzare rapidamente i binari closed-source di GitHub. L’approccio ha abbassato drasticamente il costo e il tempo necessari a mappare un protocollo interno opaco, dimostrando che l’AI può scalare l’auditing di piattaforme cloud precedentemente considerate inaccessibili a un’ispezione esterna sistematica.

Resta tuttavia un limite metodologico: non è chiaro se l’intelligenza artificiale abbia individuato autonomamente la superficie di attacco o se abbia solo accelerato l’analisi dopo una direzione iniziale dei ricercatori. Ciò non muta l’esito, ma segna comunque un cambio di paradigma: le difese basate sull’opacità del codice binario perdono efficacia quando modelli linguistici e decompiler neurali possono ricostruire semantica e flusso dati a partire dal solo bytecode.

Milioni di repository sullo stesso nodo: il rischio multi-tenant

La ricerca ha confermato che su GitHub.com la vulnerabilità non si limitava al repository target dell’attaccante. I nodi storage affetti ospitavano milioni di repository altrui, pubblici e privati, condividendo filesystem e processi a livello di infrastruttura. Un RCE su un nodo multi-tenant avrebbe quindi permesso di ispezionare, copiare o alterare codice e secret appartenenti ad account e organizzazioni senza alcuna relazione di trust con l’utente malevolo.

GitHub ha mitigato la minaccia sull’ambiente cloud in circa 6 ore dalla segnalazione di Wiz, applicando la correzione definitiva il 4 marzo 2026. Nonostante la velocità di risposta, la latenza tra fix cloud e disclosure pubblica — oltre un mese — ha lasciato spazio a un’ignoranza diffusa tra gli amministratori di istanze on-premise, che spesso non percepiscono la criticità fino alla pubblicazione dell’advisory.

Il profilo di rischio cambia radicalmente tra SaaS e on-premise: su GitHub.com il provider ha potuto intervenire centralmente, mentre chi gestisce GHES internamente deve ora assumere il ruolo di primo attore nella catena di difesa, senza la visibilità globale che invece possiede la piattaforma cloud.

Cosa fare adesso

La natura critica e semplice dell’exploit rende quattro azioni immediate non negoziabili per chi gestisce codice su infrastruttura propria.

1. Aggiornare immediatamente GitHub Enterprise Server alle versioni indicate negli advisory di GitHub e CERT-AGID, verificando che la build installata includa la correzione per CVE-2026-3854.
2. Verificare i log di git push degli ultimi mesi alla ricerca di push options anomale contenenti parametri come rails_env, custom_hooks_dir o repo_pre_receive_hooks, segnalando eventuali occorrenze al team di sicurezza.
3. Rivedere le policy di accesso in scrittura, limitando i permessi a repository sensibili e disabilitando accessi legacy di bot e collaboratori esterni non strettamente necessari.
4. Ispezionare le istanze GHES per file hook non autorizzati o modifiche al filesystem al di fuori dei canali di deployment ufficiali, poiché un eventuale compromissione precedente potrebbe aver lasciato backdoor persistenti.

La vicenda dimostra che la multi-tenancy cloud, quando affiancata a protocolli interni non sufficientemente validati, può trasformare una falla locale in una miniera di accesso cross-tenant. L’uso dell’intelligenza artificiale per il reverse engineering di binari closed-source sposta inoltre l’equilibrio tra attaccanti e difensori, rendendo l’opacità una difesa sempre più fragile. Per le aziende che ospitano codice su GHES, il messaggio è netto: la patch esiste, ma il tempo di reazione rimane il vero fattore di rischio.

FAQ

La vulnerabilità è stata sfruttata attivamente prima della patch?

Non ci sono evidenze di sfruttamento malevolo. Secondo la ricostruzione di GitHub riportata da The Hacker News, non sono state rilevate exploitation in natura.

Perché quasi il 90% delle istanze GHES era ancora vulnerabile alla disclosure?

Il fix applicato il 4 marzo 2026 ha riguardato esclusivamente l’ambiente cloud gestito da GitHub. Le installazioni on-premise dipendono da aggiornamenti manuali degli amministratori, che spesso attendono l’advisory pubblico per pianificare il patching.

L’intelligenza artificiale ha trovato la falla da sola?

Wiz Research ha utilizzato tool AI-augmented come IDA MCP, ma non è noto se l’intelligenza artificiale abbia operato in modo completamente autonomo o abbia accelerato un’indagine avviata manualmente dai ricercatori.

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

Fonti

• https://cert-agid.gov.it/news/github-e-github-enterprise-server-vulnerabilita-rce-cve-2026-3854/
• https://www.wiz.io/blog/github-rce-vulnerability-cve-2026-3854
• https://www.hendryadrian.com/github-and-github-enterprise-server-rce-vulnerability-cve-2026-3854/
• https://thehackernews.com/2026/04/researchers-discover-critical-github.html