RCE su GitHub via git push: a rischio il backend aziendale

CVE-2026-3854 in GitHub Enterprise Server consente RCE con un solo git push. L'88% delle istanze self-hosted è ancora vulnerabile: il pericolo è immediato.

Contenuto

RCE su GitHub via git push: a rischio il backend aziendale
RCE su GitHub via git push: a rischio il backend aziendale

Il 28 aprile 2026 è emerso che una vulnerabilità in GitHub Enterprise Server, tracciata come CVE-2026-3854, consente l'esecuzione remota di codice tramite una singola operazione git push. I ricercatori di Wiz hanno dimostrato che i valori delle push option controllati dall'utente non vengono sanificati prima di essere inseriti in header interni multi-servizio, permettendo l'iniezione di metadati aggiuntivi che alterano l'esecuzione degli hook e aggirano le sandbox. Con quasi il 90% delle istanze self-hosted ancora esposte, il rischio concreto per le aziende è immediato e richiede un intervento di patching urgente.

Punti chiave
  • La falla CVE-2026-3854 consente RCE su GitHub Enterprise Server a chi abbia soli privilegi di push access su un repository.
  • Il meccanismo sfrutta la mancata sanificazione dei valori delle git push options inseriti in header interni che adottano un delimiter interpretabile come separatore.
  • L'attacco permette di alterare metadati come rails_env e le directory di hook, eseguendo codice arbitrario come utente git e aggirando le sandbox.
  • GitHub avrebbe rilasciato patch per le versioni 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 e 3.19.3, ma quasi il 90% delle istanze self-hosted risulterebbe ancora vulnerabile.

Come funziona l'injection nei protocolli interni GitHub

Durante una git push, il client può allegare coppie chiave-valore note come push options, destinate a controllare comportamenti lato server come il triggering di CI o la gestione dei merge. Nel caso di GitHub Enterprise Server, questi valori transitano attraverso un ecosistema di microservizi interni che si scambiano metadati tramite header dedicati.

Il formato di tali header utilizza un delimiter che non viene trattato come carattere riservato: se l'input dell'utente contiene quel medesimo carattere, il parser a valle lo interpreta come separatore di un nuovo campo. Di conseguenza, l'attaccante può iniettare coppie chiave-valore non previste, modificando il comportamento dei servizi successivi. La radice del problema non risiede nel codice open source di Git, ma in un protocollo ad hoc chiuso usato per orchestrare l'infrastruttura backend, dove l'assunzione implicita di trust tra servizi ha generato una falla di improper neutralization of special elements.

Dalle push option al controllo del backend: la catena d'attacco

Una volta iniettati i metadati aggiuntivi attraverso il delimiter vulnerabile, la catena d'attacco descritta dai ricercatori permette di deviare l'esecuzione degli hook server-side, i processi che GitHub utilizza per elaborare eventi di repository. Alterando il valore rails_env, l'attaccante può forzare una modalità di esecuzione non sicura, disattivando protezioni che normalmente limitano il contesto operativo degli script.

Combinando poi tecniche di redirect della hook directory e path traversal, riesce a far eseguire file arbitrari con le credenziali dell'utente git. Da quel punto, il compromesso può estendersi verticalmente all'intero sistema che ospita l'istanza, mettendo a rischio l'integrità di tutti i repository e dei dati interni ospitati sulla stessa macchina. Non è noto se esistano indicatori di compromissione pubblici per rilevare exploitation passata, il che rende complessa la verifica retroattiva dello stato di sicurezza per i team di incident response.

Dalla segnalazione alla patch: una risposta rapida ma adozione lenta

Il report di Wiz è datato 4 marzo 2026. Stando alla cronologia riportata da SecurityAffairs, GitHub avrebbe rilasciato le patch entro circa due ore dalla ricezione della segnalazione, distribuendo fix per le versioni 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 e 3.19.3. Nonostante la velocità del vendor, al momento della pubblicazione della ricerca il 28 aprile 2026, quasi il 90% delle istanze self-hosted risultava ancora vulnerabile.

L'indagine non avrebbe rilevato exploitation al di fuori dei test controllati dei ricercatori, né compromissioni documentate di dati clienti, ma l'esposizione massiccia suggerisce una problematica di governance degli aggiornamenti nelle infrastrutture on-premise e self-managed, dove i team devono pianificare finestre di manutenzione che spesso slittano per settimane o mesi, lasciando il perimetro aperto a chiunque abbia un accesso in scrittura.

"GitHub Enterprise Server customers should upgrade immediately – at the time of this writing, our data indicates that 88% of instances are still vulnerable." — Wiz, citato da SecurityAffairs

Perché i delimiter ad hoc tra microservizi sono un rischio sistemico

L'incidente mette in luce un pattern architetturale pericoloso: servizi eterogenei che si scambiano metadati attraverso formati delimitati senza sanificazione rigorosa e senza un layer di validazione intermedio. Quando ogni microservizio assume che il predecessore abbia già validato i dati, la catena di trust diventa un singolo punto di fallimento collassante.

In questo caso, è bastato un git push per compromettere l'infrastruttura backend di una piattaforma usata da milioni di sviluppatori. La lezione si estende oltre GitHub: qualsiasi organizzazione che utilizza protocolli interni custom per orchestrare servizi — API non documentate, header proprietari, formati binari legacy — dovrebbe trattare ogni byte proveniente dall'utente finale, e ogni metadato che ne deriva, come untrusted per default, indipendentemente da quanti hop interni quel dato abbia attraversato.

Cosa fare adesso

  • Aggiornare immediatamente le istanze self-hosted a una delle versioni patchate rilasciate da GitHub: 3.14.24, 3.15.19, 3.16.15, 3.17.12, 3.18.6 o 3.19.3. Chi non riesce a pianificare il downtime dovrebbe almeno forzare il reboot dei servizi applicativi dopo l'update per garantire l'attivazione del fix.
  • Revisionare i log delle operazioni di push recenti alla ricerca di push option anomale o pattern sospetti che possano indicare tentativi di injection, anche se non è disponibile un set pubblico di IoC per confronto automatizzato.
  • Restringere temporaneamente i permessi di push ai soli account essenziali fino al completamento dell'aggiornamento, riducendo la superficie di attacco interna e limitando il numero di utenti che possono innescare la catena di exploitation.
  • Isolare network-side le istanze non patchate, se possibile, limitando l'accesso remoto da reti non aziendali fino a quando il fix non sarà applicato e verificato con un controllo della versione attiva.

La scoperta di Wiz non è una falla isolata, ma il sintomo di una fragilità diffusa: quando i protocolli interni trattano i dati utente come trusted, i confini tra microservizi collassano con un solo carattere.

Per le aziende che ospitano codice su GitHub Enterprise Server, la domanda non è più se aggiornare, ma quanto velocemente. L'architettura a zero-trust non può fermarsi al perimeter network se poi i metadati che attraversano i servizi interni viaggiano senza validazione.

Domande frequenti

La vulnerabilità interessa anche gli utenti di GitHub.com (cloud)?

Non è confermato che la stessa catena d'attacco sia exploitable in produzione sull'infrastruttura cloud multi-tenant di GitHub.com. La fonte disponibile indica una potenzialità teorica su nodi storage condivisi nell'ambiente cloud, ma le patch e l'alert si concentrano su GitHub Enterprise Server self-hosted.

Chi utilizza il SaaS pubblico non dispone di azioni di mitigazione autonome oltre all'attesa di conferme dal vendor, dato che l'architettura cloud non è gestita localmente.

Perché un semplice git push può portare a esecuzione remota di codice?

Perché i valori delle push option inseriti dall'utente finiscono in header interni senza che un delimiter pericoloso venga neutralizzato. Questo permette di spezzare la struttura del messaggio e iniettare metadati falsi, come la modalità di esecuzione o il percorso degli hook, fino a ottenere il controllo del processo backend.

Il problema non è nel protocollo Git standard, ma nel modo in cui GitHub Enterprise Server lo integra con i propri microservizi interni, assumendo che i dati interni siano già puliti.

Cosa rischia un'azienda che non applica la patch?

Un attaccante con accesso in scrittura a un repository può ottenere l'esecuzione di codice arbitrario sul server Enterprise Server, con conseguente compromissione del sistema, accesso a tutti i repository ospitati sulla stessa istanza e potenziale esfiltrazione di dati interni.

L'esposizione è concreta: quasi il 90% delle istanze risulta ancora vulnerabile, e l'assenza di IoC pubblici rende difficile escludere a priori un accesso non autorizzato già avvenuto prima del patching. Per questo gli amministratori dovrebbero considerare l'aggiornamento come un'operazione di incident prevention e non solo di routine.

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

Fonti

Link utili

Apri l'articolo su DeafNews