Ing. Calogero Bono
Il progetto Git ha rilasciato la versione 2.56.1 per correggere sei vulnerabilità di sicurezza. Una di queste permette di eseguire codice altrui quando si clona in modo ricorsivo un repository malevolo. Le altre riguardano scritture su file non previsti e danni alla memoria durante merge e patch binarie. Conta perché Git è dentro editor, strumenti di automazione e server di molte aziende, e va aggiornato ovunque.
Qualche termine, prima di entrare nei fatti. Clone ricorsivo è la copia di un repository insieme ai suoi sottomoduli. Un sottomodulo è un repository dentro un altro repository. Gli hook sono programmi che Git avvia in momenti precisi. Il path traversal usa percorsi con componenti speciali per uscire dalla cartella consentita. Il CVE è il codice che identifica una vulnerabilità pubblica.
Che cosa ha rilasciato il progetto Git?
Secondo il blog di GitHub, le correzioni sono nella versione 2.56.1. Esistono anche backport per le serie 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2.
GitHub consiglia di passare alla 2.56.1 o alla versione corretta della propria serie, e di aggiornare anche le applicazioni che includono una copia di Git. Chi ha letto il nostro percorso su Git per sviluppatori sa quanto lo strumento sia diffuso nei flussi di lavoro quotidiani.
Come si arriva a eseguire codice con un clone ricorsivo?
Il difetto è tracciato come CVE-2026-111760. È un troncamento di intero nella gestione dell'indice. Un percorso lunghissimo supera il controllo di Git, ma viene poi scritto su disco con un nome più corto, che un attaccante può far diventare .git.
Così si sostituisce il file .git di un sottomodulo con un collegamento simbolico verso una cartella con hook o configurazioni ostili. Come spiega The Hacker News, Git rifiuta di sostituire una cartella .git con un collegamento simbolico, ma in un sottomodulo appena clonato .git è un file. Quando Git usa quella cartella, il codice dell'attaccante può partire.
La correzione scarta i percorsi troppo lunghi prima che la lunghezza venga troncata.
Quali sono le altre cinque vulnerabilità?
- CVE-2026-113408. Clonando un repository vuoto con il protocollo v2, un server malevolo può indicare un nome con path traversal. Con il backend dei riferimenti a file, un aggiornamento successivo può scrivere fuori dalla cartella prevista.
- CVE-2026-114467. Un tag con più di due firme GPG, se unito con merge, corrompe lo stack e può causare un blocco del servizio.
- CVE-2026-114469. Una patch binaria piccola ma che si espande molto aggira il limite di circa 1 GiB e manda Git in crash.
- CVE-2026-105437. Un merge molto grande, con molti conflitti e un attributo conflict-marker-size elevato, corrompe la memoria heap.
- CVE-2026-114466. Tre funzioni di fast-import possono leggere file arbitrari o crearne e aggiungervi dati.
Per l'ultimo caso, Git ora rifiuta quelle funzioni nei flussi in ingresso, salvo l'opzione --allow-unsafe-features, da usare solo se ti fidi del programma che genera il flusso.
Chi rischia di più, e cosa ha già aggiornato GitHub?
Sono più esposti i server che fanno merge per conto degli utenti. GitLab, che ha assegnato CVE-2026-105437, indica git merge-tree come bersaglio probabile, perché un server lo può usare per verificare se una merge request è unibile. L'attributo si imposta in un file .gitattributes del repository, quindi chi può aprire una richiesta potrebbe innescare il difetto.
GitHub dichiara di aver corretto github.com e GitHub Enterprise Cloud. Per Enterprise Server servono le versioni 3.19.15, 3.20.11, 3.21.9 o 3.22.4. GitHub Desktop, l'app Copilot, Codespaces e Actions riceveranno Git corretto.
Limiti da conoscere
Le fonti non riportano exploit attivi né un livello di gravità per ciascun CVE. Non sappiamo se qualcuno abbia già sfruttato i difetti. Secondo The Hacker News, martedì alle 19.09 UTC Git for Windows non aveva ancora una versione basata sulla 2.56.1, quindi i tempi per quella piattaforma possono cambiare. Mancano anche i tempi per GitHub Desktop, Copilot, Codespaces e Actions.
Cosa cambia per chi lavora con il digitale
Il primo passo è censire dove gira Git. Non solo sul tuo computer, ma nei programmi che ne includono una copia, nei sistemi di integrazione continua e nei servizi che elaborano repository altrui. Chi gestisce server con repository di terzi deve aggiornare anche le automazioni. Se non puoi farlo subito, il workaround di GitLab è aggiungere conflict-marker-size=7 al file info/attributes di ogni repository, oppure disattivare quei controlli sui repository non fidati. Chi si affida a un hosting con aggiornamenti di sicurezza gestiti delega parte di questo lavoro.
Il nostro parere
Le vulnerabilità sono sei, ma il messaggio è uno. Git va trattato come software che elabora input non fidato, non come un semplice strumento locale. Cloniamo, uniamo e applichiamo patch da fonti esterne senza pensarci, e le automazioni lo fanno al posto nostro. Il rischio più concreto sta nelle copie di Git nascoste dentro altri programmi, che nessuno aggiorna finché non se ne ricorda. Le precauzioni elencate da GitHub vanno bene come ripiego, ma sono ripieghi. A proposito di strumenti che usano Git in modo intensivo, abbiamo scritto di GitHub Rubicon, dove il tema dell'input non fidato pesa ancora di più.
Domande frequenti
Quale versione di Git devo installare?
Installa la 2.56.1 oppure la versione corretta della tua serie, cioè 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 o 2.50.2. Aggiorna anche le applicazioni che includono una propria copia di Git.
Basta non clonare repository sconosciuti?
Aiuta, ma non basta. GitHub indica di clonare solo da server fidati ed evitare cloni ricorsivi, merge e patch binarie da fonti non fidate, precisando che queste precauzioni non sostituiscono gli aggiornamenti.
Qual è la vulnerabilità più grave?
Le fonti non danno una classifica. Quella che permette di eseguire codice durante un clone ricorsivo è CVE-2026-111760, ed è quella su cui si concentra la copertura.
Git for Windows è già aggiornato?
Non ancora, secondo l'ultimo controllo di The Hacker News. Martedì alle 19.09 UTC non risultava una versione basata sulla 2.56.1 tra i tag di rilascio.
Gli utenti di GitHub devono fare qualcosa?
Dipende. GitHub ha già corretto github.com e le versioni Enterprise Cloud. Chi usa Enterprise Server deve passare a una delle versioni indicate, e chi usa strumenti locali deve aggiornare Git.
Gli aggiornamenti di Git da seguire nei prossimi giorni
La correzione esiste, ma la distribuzione è a pezzi. Conviene seguire chi ancora deve rilasciare la sua versione.
- Controlla quando Git for Windows pubblica una build basata sulla 2.56.1 e aggiorna subito.
- Verifica quando arrivano le versioni corrette di GitHub Desktop, dell'app Copilot, di Codespaces e di Actions.
- Se gestisci un server di code hosting, valuta il workaround di GitLab finché non puoi aggiornare.
