CVE-2026-3854: RCE in GitHub con un solo git push, 88% istanze…

Wiz Research ha scoperto una vulnerabilità RCE in GitHub Enterprise Server sfruttabile con un singolo comando git push. Il 88% delle istanze self-hosted rimane non

Il 4 marzo 2026 Wiz Research ha divulgato a GitHub una vulnerabilità di esecuzione di codice remota critica, poi catalogata come CVE-2026-3854, che permette a qualsiasi utente autenticato con accesso push di ottenere il controllo completo di un server GitHub Enterprise Server con un unico comando. GitHub ha validato il report in 40 minuti e distribuito la correzione a GitHub.com in meno di due ore, ma il dato che condiziona il rischio reale è un altro: secondo Wiz, l'88% delle istanze GHES self-hosted rimaneva vulnerabile al momento della disclosure.

Punti chiave

CVE-2026-3854 ha un punteggio CVSS 4.0 di 8.7 (HIGH) assegnato da GitHub come CNA, e 8.8 nella valutazione NVD con CVSS 3.1: classificazione CWE-77, command injection.
L'exploitation richiede un singolo git push -o con un valore craftato che sfrutta la mancata sanificazione del punto e virgola nel header interno X-Stat.
GitHub.com è stato patchato entro il 4 marzo 2026; su GHES self-hosted la vulnerabilità comporta compromissione totale del server, su GitHub.com accesso cross-tenant a milioni di repository.
Wiz ha utilizzato tooling AI-augmented, specificamente IDA MCP per reverse engineering automatizzato di binari closed-source, riducendo tempi precedentemente definiti "troppo onerosi".

Come funziona la catena di exploitation: dall'header interno al controllo del server

Il meccanismo si origina in babeld, componente che gestisce le operazioni git push: i valori delle push option fornite dall'utente vengono copiati direttamente nel header interno X-Stat senza sanificare il carattere ;. Wiz ha confermato la vulnerabilità tramite packet capture su istanza GHES live, documentando come il delimitatore semicolon permetta di iniettare campi aggiuntivi nella mappa di parsing, che segue semantica "last-write-wins".

La catena di exploitation si sviluppa in tre fasi. In primo luogo, l'injection bypassa il sandboxing delle hook di pre-receive ridefinendo l'ambiente di esecuzione. In secondo luogo, viene reindirizzata la directory custom_hooks_dir. In terzo luogo, il percorso repo_pre_receive_hooks viene manipolato tramite path traversal per ottenere esecuzione di codice non sandboxed come utente git. Sagi Tzadik, ricercatore di Wiz, ha dichiarato: "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".

Su GitHub.com la stessa catena ha permesso l'esecuzione di codice su nodi di storage condivisi, con accesso verificato a milioni di repository pubblici e privati appartenenti ad altri utenti e organizzazioni. Il vettore di attacco non richiede privilegi amministrativi: è sufficiente qualsiasi account con permesso di push.

L'AI che legge il binario che nessuno può vedere: il metodo Wiz

Il dato metodologico che distingue questa ricerca è l'uso di reverse engineering automatizzato su codice proprietario. Wiz ha impiegato IDA MCP, un plugin che integra modelli linguistici nel disassemblatore IDA Pro, per analizzare binari closed-source di GitHub in tempi definiti "precedentemente impraticabili". La dichiarazione pubblicata dalla società è precisa: "By leveraging AI-augmented tooling—particularly automated reverse engineering using IDA MCP—we were able to do what was previously too costly".

Il paradosso è evidente: lo stesso strumento che accelera la scoperta di vulnerabilità può accelerare anche l'analisi offensiva di software che non distribuisce codice sorgente. Per i vendor di software proprietario, questo rappresenta un cambiamento di scenario. La segretezza del binario non costituisce più una barriera predittiva contro l'analisi sistematica.

La risposta di GitHub e il gap di patching nelle istanze self-hosted

Alexis Wales, CISO di GitHub, ha confermato la timeline operativa: il report Wiz è arrivato attraverso il Bug Bounty program il 4 marzo 2026, la validazione interna ha richiesto 40 minuti, il fix è stato deployato a GitHub.com entro le 7:00 p.m. UTC, meno di due ore dopo la validazione. Wales ha inoltre dichiarato che ogni occorrenza rilevata nei log corrisponde all'attività di testing dei ricercatori, con "no customer data accessed, modified, or exfiltrated".

La discrepànza tra cloud e self-hosted emerge tuttavia nei numeri. Mentre GitHub.com è stato corretto in giornata, le istanze GHES gestite dai clienti dipendono da patch rilasciate in versioni specifiche. Secondo il record NVD, le versioni interessate e le relative correzioni includono rami 3.14, 3.15, 3.16, 3.17, 3.18 e 3.19, con build patch indicativamente nella serie .24/.25 o successive a seconda del ramo. Wiz riporta che l'88% delle istanze GHES scansionate rimaneva vulnerabile al momento della pubblicazione della ricerca.

Il dossier non specifica il denominatore assoluto di istanze totali nè il numero esatto di installazioni patchate, né quantifica la ricompensa Bug Bounty, descritta solo come "one of the highest rewards".

Cosa fare adesso

Verificare la versione di GitHub Enterprise Server installata e confrontarla con le build patch indicate nell'advisory GHSA-64fw-jx9p-5j24; aggiornare a una versione corretta se l'istanza rientra nelle serie affette.
Auditare i log di accesso per identificare comandi git push con opzioni -o non usuale, in particolare valori contenenti caratteri di delimitazione, mappandoli contro l'attività di testing documentata di Wiz.
Rivedere le politiche di accesso push per limitare il privilegio a utenti con necessità operativa documentata, riducendo la superficie di account che potrebbero teoricamente innescare la catena di exploitation.
Monitorare i canali ufficiali di GitHub Security e il feed NVD per CVE-2026-3854 per eventuali revisioni metriche o estensioni del range di versioni affette.

"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

Domande frequenti

GitHub.com è ancora a rischio?
No. La piattaforma cloud è stata corretta il 4 marzo 2026 entro due ore dalla validazione del report. Il rischio residuo riguarda esclusivamente le istanze GHES self-hosted non aggiornate.

È necessario essere amministratore per sfruttare la vulnerabilità?
No. Qualsiasi utente autenticato con permesso di push su un repository può innescare la catena, come confermato dalla descrizione del vettore CVSS con PR:L (privilege required low).

L'uso di AI nella scoperta è verificato o è una narrative di marketing?
Wiz dichiara esplicitamente l'uso di IDA MCP per reverse engineering automatizzato. Il dossier non permette di stabilire se la vulnerabilità sarebbe stata individuabile senza tooling AI, né se l'analisi fosse già iniziata manualmente. L'affermazione sulla metodologia è tratta dalla fonte primaria senza corroborazione indipendente sul dettaglio operativo.

La lezione che emerge dal caso CVE-2026-3854 non è solo tecnica: un protocollo interno con trust implicito tra componenti, progettato presumibilmente per isolare ambienti multi-tenant, si è rivelato vulnerabile a una injection elementare. L'uso dell'intelligenza artificiale per decostruire binari proprietari introduce una variabile di velocità che i programmi di sicurezza dei vendor dovranno integrare nelle loro proiezioni di rischio.

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

Fonti

Fonti e riferimenti