GitHub RCE: un git push craftato comprometteva il server

GitHub RCE: un git push craftato comprometteva il server

Wiz Research ha divulgato il 28 aprile 2026 una vulnerabilità critica in GitHub.com e GitHub Enterprise Server che permetteva esecuzione remota di codice tramite una singola operazione git push craftata. La falla, tracciata come CVE-2026-3854, sfrutta la mancata sanificazione del delimitatore ';' nell'header interno X-Stat e trasforma qualsiasi account con permessi di push in un vettore di compromissione totale, soprattutto per le istanze self-hosted. La scoperta, avvenuta con reverse engineering assistito da intelligenza artificiale su binari closed-source, ridefinisce i rischi delle pipeline che gestiscono il codice dell'intero settore.

La catena di exploit su GitHub Enterprise Server

"A single git push command was enough to exploit a flaw in GitHub's internal protocol and achieve code execution on backend infrastructure", ha riassunto Wiz Research. Su GitHub Enterprise Server questa singola operazione si traduce in una compromissione totale del server. Come ha spiegato Alexis Wales, CISO di GitHub, "by chaining several injected values together, the researchers demonstrated that an attacker could override the environment the push was processed in, bypass sandboxing protections that normally constrain hook execution, and ultimately execute arbitrary commands on the server".

La catena richiede tre iniezioni successive nell'header X-Stat: la sovrascrittura del campo rails_env per bypassare la sandbox dei pre-receive hook, la modifica di custom_hooks_dir per reindirizzare la directory degli hook e l'iniezione di repo_pre_receive_hooks per eseguire path traversal e comandi arbitrari come utente git.

Con esecuzione di codice non sandboxed come utente git, l'attaccante ottiene controllo completo sull'istanza, con accesso in lettura e scrittura al filesystem e visibilità sulle configurazioni interne dei servizi. Secondo quanto riferito dai ricercatori, questo scenario espone l'intera superficie del server, dai sorgenti ai segreti condivisi, senza necessità di privilegi amministrativi iniziali oltre al permesso di push su un repository.

"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

Perché il punto e virgola ha aperto una falla nel protocollo interno

Il nucleo del difetto sta nella maniera in cui la pipeline git di GitHub elabora le push options fornite dall'utente durante l'operazione di push. Il servizio babeld copia direttamente questi valori nell'header X-Stat senza sanificare il carattere ';', che funge da delimitatore tra le coppie chiave=valore del protocollo interno. Poiché il parser downstream applica una semantica last-write-wins, qualsiasi push option contenente un punto e virgola consente al valore iniettato di uscire dal campo designato e sovrascrivere silenziosamente chiavi di sicurezza successive. Come ha osservato Wiz Research, "when multiple services written in different languages pass data through a shared internal protocol, the assumptions each service makes about that data become a critical attack surface".

Questa discontinuità tra le assumizioni del servizio che genera l'header e quelle del componente che lo consuma trasforma l'X-Stat da semplice veicolo di metadati in un canale di iniezione. La mancata validazione dell'input utente prima del passaggio tra servizi scritti in linguaggi diversi permette di alterare il comportamento dei processi backend che gestiscono l'intera pipeline di ricezione del codice.

GitHub.com e il rischio cross-tenant sui nodi condivisi

La stessa vulnerabilità ha interessato GitHub.com, dove l'exploit permetteva l'esecuzione di codice su nodi storage condivisi tra più tenant. I ricercatori hanno confermato che, sui nodi compromessi, erano accessibili milioni di repository pubblici e privati appartenenti ad altri utenti e organizzazioni, ampliando il rischio da incidente isolato a potenziale esposizione cross-tenant di massa.

GitHub ha mitigato la falla sui propri servizi cloud il 4 marzo 2026, in meno di 6 ore dalla segnalazione di Wiz. La società ha riprodotto internamente la vulnerabilità in circa 40 minuti e ha rilasciato la correzione entro le 19:00 UTC della stessa giornata. In una nota ufficiale, la piattaforma ha dichiarato: "GitHub greatly appreciates the collaboration, professionalism, and partnership that Wiz has shown throughout this process. A finding of this caliber and severity is rare, earning one of the highest rewards available in our Bug Bounty program".

Nonostante la rapidità della risposta, la natura condivisa dell'infrastruttura rende il vettore particolarmente insidioso per la segregazione dei dati tra tenant indipendenti.

Cosa fare adesso

Per le organizzazioni che gestiscono istanze GitHub Enterprise Server, la priorità è applicare immediatamente gli aggiornamenti rilasciati da GitHub, dato che circa l'88% delle installazioni risultava ancora vulnerabile al momento del disclosure pubblico.

È altresì necessario limitare i permessi di push ai soli account strettamente necessari, poiché qualsiasi utente autenticato con tale diritto può innescare la catena di exploit con un singolo comando.

Le squadre di sicurezza dovrebbero analizzare i log di audit alla ricerca di operazioni git push contenenti push options anomale, verificando che i path mappati corrispondano a sessioni legittime.

Infine, va valutata l'opportunità di isolare le istanze GHES in segmenti di rete ridotti e di verificare l'integrità dei backup dei segreti interni, considerando che una compromissione totale del server espone l'intero patrimonio di codice e credenziali.

Reverse engineering AI e la nuova frontiera delle pipeline sicure

La scoperta di CVE-2026-3854 segna un cambiamento di paradigma nella ricerca di vulnerabilità su infrastrutture closed-source di livello enterprise. Wiz Research ha utilizzato strumenti di reverse engineering assistiti da intelligenza artificiale per analizzare i binari proprietari della pipeline git di GitHub, individuando la mancata sanificazione dell'input utente senza accesso al codice sorgente originale.

Questo approccio dimostra che le piattaforme centrali per la gestione del codice, anche quando non dipendono da componenti open source, espongono superfici di attacco analizzabili automaticamente a scala. Per il settore, l'implicazione è che la protezione delle pipeline di sviluppo richiede ora un modello di threat modeling che consideri non solo le dipendenze pubbliche, ma anche la robustezza dei protocolli interni che orchestrano i servizi backend e il modo in cui essi interpretano i dati in transito.

Il caso CVE-2026-3854 dimostra che la sicurezza delle piattaforme di hosting del codice dipende tanto dall'integrità dei protocolli interni quanto dalla qualità del codice visibile esternamente. Quando servizi scritti in linguaggi diversi si scambiano dati attraverso formati condivisi, le assumizioni non allineate su sanificazione e parsing diventano falle sistemiche. Per le aziende, il messaggio è che la supply chain del software inizia molto prima dell'ultimo commit: inizia nella maniera in cui la piattaforma stessa digerisce un singolo git push.

Domande frequenti

La vulnerabilità ha interessato anche gli utenti di GitHub.com senza istanze Enterprise?

Sì. Oltre a GHES, la falla ha interessato l'infrastruttura cloud di GitHub.com, permettendo l'esecuzione di codice su nodi storage condivisi. Sebbene GitHub abbia mitigato il problema il 4 marzo 2026, i ricercatori hanno confermato che sui nodi compromessi erano accessibili milioni di repository pubblici e privati di altri utenti, espandendo il rischio oltre il singolo tenant.

Perché la vulnerabilità presenta punteggi CVSS diversi tra GitHub e NVD?

GitHub ha assegnato alla vulnerabilità un punteggio di 8.7 utilizzando la versione 4.0 del framework, mentre il National Vulnerability Database riporta un valore di 8.8 secondo la versione 3.1. Questa discrepanza riflette le diverse modalità di calcolo e di contestualizzazione dell'impatto tra vendor e database pubblici, ma entrambi i punteggi collocano la falla nel range di severità elevata.

È stata rilevata exploitation malevola prima del disclosure pubblico?

Secondo quanto riferito da GitHub e Wiz, non esiste evidenza di exploitation malevola al di fuori delle attività di test condotte dai ricercatori. Ogni occorrenza rilevata è risultata mappata sulle sessioni di verifica di Wiz, senza altri utenti o account coinvolti. Rimane tuttavia sconosciuto se proof-of-concept pubblici o attacchi attivi non rilevati fossero già circolati prima del 28 aprile 2026.

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://www.penligent.ai/hackinglabs/github-cve-2026-3854-the-rce-in-the-git-push-pipeline/