GitHub RCE critica: una git push esegue codice sui server

GitHub RCE critica: una git push esegue codice sui server

La vulnerabilità CVE-2026-3854, scoperta da Wiz Research e resa pubblica il 28 aprile 2026 con punteggio CVSS 8.7, consente a un utente autenticato con permessi di push di ottenere codice remoto sui server backend di GitHub.com e GitHub Enterprise Server con una singola git push craftata. Il bug colpisce il parsing interno dell'header X-Stat: sebbene GitHub.com sia stato corretto in meno di due ore il 4 marzo, circa l'88% delle istanze self-hosted risultava ancora esposto alla disclosure. Le aziende con server non aggiornati corrono il rischio concreto di compromissione totale.

Il meccanismo X-Stat: come una git push diventa codice arbitrario

Il bug risiede nel passaggio di metadati tra i servizi interni di GitHub. Quando un utente esegue una git push con opzioni custom, i dati vengono incapsulati nell’header interno X-Stat che viaggia dal servizio babeld al servizio gitrpcd. Il problema è la mancata sanitizzazione del carattere delimitatore ;: un attaccante può iniettare nuovi campi all’interno di una singola push option, sfruttando la semantica last-write-wins del parser per sovrascrivere valori legittimi.

Le push options sono una estensione del protocollo git che consente di inviare parametri opzionali al server durante la fase di push. In condizioni normali, questi metadati guidano il comportamento dei hook server-side senza alterare l’ambiente di esecuzione. La mancata escaping del carattere ; nell’header X-Stat ha invece permesso di ridefinire quell’ambiente, violando il trust boundary tra servizi che dovrebbero operare in contesti di privilegio separati.

I ricercatori di Wiz hanno confermato la vulnerabilità analizzando i binari di babeld e dei pre-receive hook, oltre a catturare il traffico di rete su un’istanza GitHub Enterprise Server live. In laboratorio, una push option contenente il delimitatore ; ha generato campi X-Stat non previsti dal flusso normale, dimostrando che il protocollo interno interpreta l’input dell’utente come configurazione di servizio.

Dalla sandbox al filesystem: la catena di tre injection su GHES

Su GitHub Enterprise Server la vulnerabilità si traduce in un percorso di escalation completo. L’attaccante deve concatenare tre injection consecutive nel flusso X-Stat: innanzitutto sovrascrivere rails_env, quindi deviare custom_hooks_dir verso una directory controllata e infine manipolare repo_pre_receive_hooks. La sequenza bypassa le protezioni di sandboxing che normalmente isolano l’esecuzione dei pre-receive hook.

Il risultato è l’esecuzione di codice arbitrario con i privilegi dell’utente git sul server backend. Come hanno documentato i ricercatori, questo livello di accesso garantisce il controllo completo sull’istanza, inclusa la lettura e scrittura del filesystem e la visibilità sulla configurazione dei servizi interni. Non è noto se tecniche simili possano essere riproposte su GitHub.com, dove l’architettura multi-tenant presenta tuttavia una superficie di attacco differente.

Alexis Wales, CISO di GitHub, ha confermato che concatenando diversi valori iniettati i ricercatori hanno sovrascritto l’ambiente di elaborazione, bypassato le protezioni di sandboxing e ottenuto esecuzione di comandi arbitrari sul server.

"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

GitHub.com e il rischio cross-tenant: milioni di repo su nodi storage condivisi

La stessa classe di vulnerabilità ha coinvolto GitHub.com, dove la piattaforma gestisce repository multi-tenant su nodi storage condivisi. I ricercatori di Wiz hanno verificato che, in caso di exploit riuscito sulla infrastruttura cloud, milioni di repository pubblici e privati di altri utenti e organizzazioni risultavano accessibili dal nodo compromesso. Il vendor ha corretto il servizio il 4 marzo 2026 in meno di due ore dalla ricezione del report, e alcune ricostruzioni indicano circa 75 minuti tra validazione interna e deploy effettivo.

GitHub ha dichiarato che la telemetria sul code path anomalo — mai attivato in condizioni normali — ha mappato ogni occorrenza ai soli test condotti dai ricercatori, escludendo accessi o esfiltrazioni di dati cliente. Non è tuttavia possibile escludere a priori che exploit non rilevati dalla telemetria siano avvenuti prima del fix, anche se al momento non esistono evidenze in questo senso.

GitHub ha riconosciuto la collaborazione di Wiz qualificando la scoperta come uno dei risultati più gravi mai gestiti nel proprio Bug Bounty program, senza tuttavia rivelare l’entità esatta del premio assegnato.

Cosa fare adesso

Per le organizzazioni che gestiscono GitHub Enterprise Server on-premise, la priorità è l’applicazione immediata delle versioni patchate indicate nel bollettino ufficiale del vendor. L’installazione del fix chiude il vettore X-Stat prima che possa essere sfruttato in un attacco mirato.

Gli amministratori devono inoltre analizzare gli audit log dell’istanza e monitorare le registrazioni del servizio gitrpcd per individuare occorrenze del code path anomalo, confrontando le timeline con la data della disclosure pubblica. Qualora l’aggiornamento non fosse immediatamente fattibile, è consigliabile limitare i permessi di push sui repository critici fino al completamento della manutenzione.

Infine, è necessario valutare la potenziale compromissione dell’host: l’accesso come utente git espone tutti i repository locali, i segreti e i token dei runner. Una revisione forense dei sistemi e il rinnovo delle credenziali interne rappresentano contromisure prudenziali dopo l’installazione della patch.

La scoperta di Wiz mette in luce un paradosso ricorrente nelle infrastrutture cloud: la velocità di risposta del vendor non coincide automaticamente con la protezione effettiva della base installata. Mentre GitHub.com è stato blindato in meno di due ore, il ritardo di adozione delle patch su sistemi self-hosted amplifica il rischio trasformando una vulnerabilità zero-day gestita in una minaccia persistente per il parco Enterprise. Per le aziende italiane, l’alert di CERT-AGID ribadisce che la governance del ciclo di patching interno resta il vero perimetro difensivo.

Domande frequenti

Perché l’exploit richiede i permessi di push?

Il vettore d’attacco sfrutta le git push options, parametri trasmessi solo durante una operazione di push. Un utente con accesso esclusivamente in lettura non genera il flusso dati necessario a iniettare i campi malevoli nell’header X-Stat.

Qual è il rischio concreto per chi usa GitHub.com oggi?

La piattaforma cloud è stata corretta il 4 marzo 2026 in meno di due ore e non richiede azioni agli utenti. Resta tuttavia il problema teorico della condivisione di nodi storage multi-tenant, che ha esposto milioni di repository al rischio di accesso incrociato nel breve intervallo precedente al fix.

Cosa significa "last-write-wins" nel contesto dell’header X-Stat?

Il parser che elabora l’header X-Stat assegna priorità all’ultimo valore incontrato per ciascun campo. Inserendo un delimitatore ; seguito da una coppia chiave-valore, l’attaccante sovrascrive la configurazione legittima impostata dal servizio babeld, deviando il comportamento del servizio gitrpcd.

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://thehackernews.com/2026/04/researchers-discover-critical-github.html
• https://cipherssecurity.com/cve-2026-3854-how-the-github-enterprise-server-rce-works-and-how-to-verify-youre-patched/
• https://github.blog/security/securing-the-git-push-pipeline-responding-to-a-critical-remote-code-execution-vulnerability/