Git 2.56.1 corregge sei falle: repository malevoli possono eseguire codice sui PC

🛡️ Executive Summary

• Git corregge sei vulnerabilità con la versione 2.56.1. Il problema più grave, CVE-2026-111760, permette l’esecuzione di codice durante la clonazione ricorsiva di repository appositamente costruiti.
• Le altre falle riguardano reference, merge, patch binarie e fast-import. Gli errori possono provocare scritture indesiderate, accesso a file e corruzione della memoria.
• GitHub distribuisce correzioni anche per i servizi enterprise. Gli aggiornamenti riguardano GitHub Enterprise Server e le versioni Git dalla 2.50 alla 2.56.

Git pubblica un aggiornamento di sicurezza urgente che corregge sei vulnerabilità, compresa una falla capace di trasformare la clonazione di un repository malevolo nell’esecuzione di codice sul computer della vittima. Il progetto open source ha distribuito Git 2.56.1 il 10 novembre 2026, accompagnandolo con correzioni per sei rami di manutenzione precedenti. Il problema più rilevante è CVE-2026-111760, una vulnerabilità nella gestione dei percorsi che consente a un repository costruito appositamente di manipolare il file .git di un submodule e indirizzare Git verso configurazioni o hook controllati dall’attaccante. Le altre cinque falle coinvolgono la gestione delle reference, le operazioni di merge, l’applicazione delle patch binarie e il sistema di importazione dei repository. La minaccia riguarda sviluppatori, amministratori DevOps e servizi automatizzati che elaborano codice proveniente da fonti esterne, perché alcune operazioni considerate ordinarie possono diventare vettori di compromissione quando Git riceve dati manipolati.

CVE-2026-111760 permette RCE durante la clonazione dei repository

La vulnerabilità principale sfrutta un errore di integer truncation nella gestione dell’indice di Git. Il software verifica i percorsi prima di scrivere i file nella directory di lavoro, anche per impedire la sovrascrittura dei metadati interni del repository. Tuttavia, un percorso estremamente lungo poteva superare la validazione iniziale e venire successivamente scritto con un nome più corto, a causa della troncatura di un valore intero. La differenza tra il percorso controllato e quello effettivamente utilizzato consentiva di aggirare una protezione progettata per difendere i file interni di Git.

Il problema assume particolare gravità durante una clonazione ricorsiva che include submodule. In un submodule appena creato, .git è normalmente un file che rimanda alla directory contenente i metadati del repository principale. Un aggressore poteva costruire il contenuto del progetto in modo da sostituire questo file con un collegamento simbolico verso una directory contenente hook o configurazioni malevole. Quando Git utilizzava successivamente quella directory, i comandi definiti dall’attaccante potevano essere eseguiti con i privilegi del processo che stava effettuando la clonazione. La dinamica è documentata nell’ advisory ufficiale GHSA-vp2w-7xxj-jvxr e confermata nel comunicato di sicurezza pubblicato da GitHub.

La correzione impedisce che percorsi di lunghezza eccessiva vengano accettati prima della troncatura, eliminando la condizione necessaria per manipolare il file .git. Non significa che ogni semplice operazione git clone comporti automaticamente un’esecuzione remota: l’attacco richiede un repository predisposto e il percorso vulnerabile associato alla gestione dei submodule. Il precedente più vicino riguarda GitSpawn, la tecnica che sfruttava configurazioni Git per ottenere esecuzione di codice negli agenti AI. Sono vulnerabilità differenti, ma entrambe dimostrano che il download di codice può coinvolgere meccanismi eseguibili non immediatamente visibili allo sviluppatore.

Git corregge path traversal e scritture fuori dalle directory previste

La seconda vulnerabilità, CVE-2026-113408, riguarda il protocollo Git v2 e la gestione delle reference pubblicizzate dal server remoto. Durante la clonazione di un repository vuoto, un server malevolo poteva comunicare una HEAD simbolica associata a un ramo non ancora creato, utilizzando componenti di path traversal nel nome. Con il backend delle reference basato su file, una successiva operazione di aggiornamento poteva quindi scrivere informazioni al di fuori della directory destinata alle reference Git.

Il difetto è rilevante perché le reference identificano branch e altri oggetti fondamentali del repository. Il software deve quindi trattare i nomi comunicati dai server remoti come input non attendibili, anche quando arrivano attraverso il normale protocollo di sincronizzazione. Git 2.56.1 introduce una validazione più rigorosa dei nomi delle reference e delle destinazioni dei collegamenti simbolici ricevuti dal server, impedendo che percorsi manipolati vengano accettati e utilizzati per scritture indesiderate. Il rischio richiama le problematiche della sicurezza dei repository e degli attacchi ai sistemi GitHub, dove l’affidabilità delle operazioni di gestione del codice dipende anche dai controlli eseguiti sulle informazioni ricevute.

Merge e firme GPG esponevano Git alla corruzione della memoria

Due vulnerabilità interessano le operazioni di merge, utilizzate quotidianamente per combinare modifiche provenienti da branch differenti. CVE-2026-114467 riguarda l’elaborazione delle firme GPG associate ai messaggi di commit o ai tag. Git assumeva che il numero delle firme da rimuovere non superasse due e utilizzava una struttura di memoria di dimensioni fisse. Un messaggio contenente un numero superiore di firme poteva provocare una scrittura oltre i limiti dell’array sullo stack, causando corruzione della memoria e potenzialmente un’interruzione del processo. Il difetto poteva manifestarsi durante il merge di un tag appositamente costruito, interessando anche piattaforme che eseguono tali operazioni per conto degli utenti.

CVE-2026-105437 riguarda invece il calcolo della memoria necessaria a produrre il risultato di un merge molto grande. La combinazione di numerosi conflitti e di un attributo conflict-marker-size elevato poteva generare un overflow durante la determinazione delle dimensioni del buffer. Git rischiava così di allocare meno memoria del necessario e di scrivere oltre i limiti disponibili, compromettendo l’heap. La vulnerabilità assume particolare importanza nei servizi di code hosting che verificano automaticamente la possibilità di integrare una pull request o una merge request. Il problema si inserisce nel più ampio quadro delle falle di Gitea che avevano permesso di trasformare le operazioni sui repository in esecuzione di codice, pur utilizzando un meccanismo tecnico differente.

Patch binarie e fast-import aprivano nuovi percorsi di attacco

La quinta vulnerabilità, CVE-2026-114469, riguarda il trattamento delle patch binarie. Git applica un limite di circa 1 GiB alle patch perché alcune procedure non sono progettate per gestire in sicurezza dimensioni superiori. Il controllo prendeva però in considerazione la dimensione del contenuto ricevuto, non quella effettiva dopo la decompressione. Una patch compressa relativamente piccola poteva quindi espandersi oltre il limite previsto, provocando una lettura fuori dai confini della memoria e il crash del programma. La nuova versione controlla anche le dimensioni dichiarate del contenuto decompresso prima di elaborarlo.

CVE-2026-114466 interessa invece git fast-import, utilizzato per costruire repository attraverso flussi di istruzioni. Alcune funzionalità consentivano l’accesso a percorsi esterni al progetto e non erano sottoposte agli stessi controlli già introdotti per altre opzioni. In particolare, rewrite-submodules-from, rewrite-submodules-to ed export-pack-edges potevano essere sfruttate per leggere file arbitrari o creare e modificare file in posizioni non previste. La correzione impedisce l’utilizzo di queste funzionalità attraverso un flusso di input non attendibile, salvo autorizzazione esplicita mediante --allow-unsafe-features. La nuova opzione non deve essere interpretata come una soluzione di sicurezza: serve a consentire funzionalità potenzialmente rischiose quando la fonte del flusso è considerata affidabile.

Git 2.56.1 disponibile con aggiornamenti per sei versioni precedenti

Il comunicato ufficiale del manutentore Junio C Hamano conferma il rilascio coordinato delle correzioni e invita gli utenti a distribuire gli aggiornamenti senza ritardi. Oltre a Git 2.56.1, sono disponibili le versioni 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. La pubblicazione comprende anche ulteriori protezioni contro le dimensioni eccessive delle voci dell’indice, miglioramenti alla gestione dei buffer e interventi di manutenzione sulla compatibilità del software.

GitHub ha applicato le correzioni a github.com e a GitHub Enterprise Cloud, comprese le installazioni con residenza dei dati. Per GitHub Enterprise Server sono indicate le versioni 3.19.15, 3.20.11, 3.21.9 e 3.22.4. La società sta inoltre coordinando gli aggiornamenti dei prodotti che distribuiscono una propria copia di Git, tra cui GitHub Desktop, GitHub Copilot, Codespaces e Actions. Quest’ultimo aspetto è importante: aggiornare il comando Git installato sul computer non garantisce che altre applicazioni utilizzino automaticamente quella versione. L’attenzione ai componenti incorporati diventa ancora più rilevante dopo le recenti campagne contro la supply chain di GitHub Actions, che hanno mostrato quanto i sistemi di automazione possano amplificare gli effetti di una compromissione.

Repository non attendibili, la priorità è aggiornare Git e gli ambienti CI/CD

Gli amministratori possono verificare la versione installata attraverso il comando git --version, ma devono considerare anche i pacchetti distribuiti dalla propria distribuzione Linux. Alcuni manutentori applicano infatti le patch di sicurezza alle versioni già presenti nei repository senza necessariamente aggiornare il numero della release principale. È quindi necessario verificare la presenza della correzione nei changelog dei pacchetti, non limitarsi a confrontare superficialmente le numerazioni.

In attesa degli aggiornamenti, GitHub raccomanda di evitare la clonazione ricorsiva di repository non attendibili, non effettuare merge di contenuti o tag sospetti e non elaborare patch binarie o flussi fast-import provenienti da fonti sconosciute. Queste precauzioni riducono l’esposizione, ma non sostituiscono le correzioni. Le organizzazioni dovrebbero prestare particolare attenzione ai runner CI/CD, ai servizi che elaborano richieste di merge e agli ambienti nei quali codice esterno viene scaricato ed eseguito automaticamente.

Continua con: GitSpawn e l’esecuzione di codice negli agenti AI tramite Git e le vulnerabilità Gitea sfruttate attraverso gli hook Git.

Git 2.56.1 dimostra che la sicurezza della supply chain non comincia soltanto dai pacchetti e dalle dipendenze, ma dagli strumenti incaricati di recuperare e integrare il codice sorgente. Un repository malevolo non deve necessariamente contenere un programma da eseguire volontariamente: può sfruttare le debolezze del sistema che lo interpreta e lo gestisce. Per questo la clonazione di progetti non attendibili, l’esecuzione automatica di merge e l’utilizzo di Git all’interno delle pipeline devono essere trattati come operazioni potenzialmente esposte a contenuti ostili, anche quando vengono eseguite attraverso strumenti consolidati.