Sei vulnerabilità di Git: aggiorna anche oltre la riga di comando

Se hai aggiornato Git nel terminale, il lavoro non è finito: alcune applicazioni e ambienti di build possono eseguire una propria copia. Il 10 novembre 2026 il progetto Git ha pubblicato correzioni per sei vulnerabilità, che vanno dall’esecuzione di codice durante la clonazione ricorsiva al danneggiamento della memoria durante un merge. Occorre quindi controllare ogni ambiente che elabora repository o il loro contenuto, non soltanto il risultato di git --version nella shell.

Cosa cambia con l’aggiornamento

Le correzioni sono incluse in Git 2.56.1 e sono state retroportate nei rami supportati: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. L’aggiornamento risolve sei problemi in diverse parti di Git, relativi alla gestione di percorsi, collegamenti, firme, patch binarie, merge e flussi di importazione. GitHub ha pubblicato il 10 novembre l’analisi delle vulnerabilità e la raccomandazione di aggiornare; le note di rilascio di Git 2.56.1 elencano i CVE corretti in questa serie.

In pratica, bisogna aggiornare Git in tre contesti: sui computer di lavoro, nei sistemi di automazione e all’interno delle applicazioni che includono una propria build di Git. È facile trascurare quest’ultimo punto: aggiornare il pacchetto di sistema non modifica automaticamente le versioni incluse in ogni client o immagine di build.

Perché la clonazione ricorsiva merita attenzione

La catena più evidente inizia con la clonazione ricorsiva di un repository non attendibile. A causa del troncamento della lunghezza del percorso, una voce molto lunga poteva superare i controlli con un nome e poi essere scritta su disco in forma abbreviata. Nello scenario descritto per Git, ciò consentiva di sostituire il file .git di un sottomodulo con un collegamento simbolico a una directory contenente configurazioni o hook malevoli. Al successivo utilizzo, Git avrebbe potuto eseguire codice impostato dall’aggressore.

È importante precisare che si tratta di un repository preparato ad arte e di un’operazione specifica. I team che clonano regolarmente progetti da fonti esterne con il parametro --recurse-submodules dovrebbero dare priorità all’aggiornamento dei client e degli ambienti automatizzati. La correzione rifiuta i percorsi troppo lunghi prima che la loro lunghezza venga troncata.

Altri punti in cui Git elabora dati non attendibili

Un altro problema si verifica quando si clona un repository vuoto tramite Git protocol v2. Il server poteva fornire un riferimento HEAD con un nome di ramo contenente componenti di attraversamento delle directory; in seguito, un’operazione di aggiornamento del ramo poteva scrivere un file al di fuori della directory prevista per i riferimenti. Nelle versioni corrette, Git controlla questa destinazione e gli altri nomi di riferimento ricevuti tramite il protocollo.

Altre vulnerabilità riguardavano le operazioni di merge e le patch. Durante l’elaborazione delle firme, un array di dimensione fissa prevedeva al massimo due firme; un messaggio appositamente predisposto con un numero maggiore poteva causare una scrittura oltre i limiti dell’array e danneggiare la memoria. Quando applicava una patch binaria, il controllo delle dimensioni considerava la rappresentazione originale, sebbene i dati compressi possano espandersi notevolmente. Ora Git verifica la dimensione dichiarata dei dati non compressi prima di elaborarli.

Anche i merge di grandi dimensioni potevano causare un overflow nel calcolo della dimensione del buffer necessario e una successiva scrittura oltre i suoi limiti. Il problema riguarda anche gli hosting e le applicazioni che eseguono merge di contenuti non attendibili. Infine, tre funzionalità di git fast-import hanno ricevuto limitazioni per i comandi contenuti nel flusso di input: rewrite-submodules-from e rewrite-submodules-to potevano leggere file arbitrari, mentre export-pack-edges poteva creare file o aggiungere dati a file esistenti. Ora queste funzionalità sono bloccate, a meno che non venga specificato esplicitamente il flag --allow-unsafe-features; usalo soltanto con generatori di flussi attendibili.

Dove cercare copie separate di Git

Per chi sviluppa software, il primo passo è censire i punti da cui viene avviato Git. Controlla la versione nel terminale e usa la funzione di aggiornamento integrata negli IDE e nei client Git desktop. Poi verifica le immagini CI, i container, i runner e i processi server che eseguono clone o merge, applicano patch binarie o avviano fast-import. Avere una versione aggiornata di Git sull’host non garantisce che l’applicazione utilizzi proprio quella.

Nelle organizzazioni è utile controllare non solo le immagini di base, ma anche gli ambienti già distribuiti: un runner persistente o un servizio interno potrebbe conservare un vecchio eseguibile dopo l’aggiornamento dell’immagine di base. Per GitHub Enterprise Server, GitHub indica le versioni corrette 3.19.15, 3.20.11, 3.21.9 e 3.22.4. L’azienda ha dichiarato di aver già distribuito le correzioni su github.com e GitHub Enterprise Cloud, incluse le varianti con residenza dei dati. Le versioni di GitHub Desktop e dell’app GitHub Copilot con Git corretto sono in fase di coordinamento; devono ancora essere pubblicate anche le versioni corrette per Codespaces e GitHub Actions.

Come ridurre il rischio prima dell’aggiornamento

Se non puoi installare subito la correzione, limita temporaneamente le operazioni con dati non attendibili: clona i repository soltanto da server fidati, evita la clonazione ricorsiva di progetti non verificati, non eseguire merge dei loro contenuti e non applicare le patch binarie o i flussi fast-import che forniscono. Queste misure riducono l’esposizione agli specifici scenari vulnerabili, ma non sostituiscono l’aggiornamento.

La conclusione pratica è semplice: la correzione di Git va cercata nei punti in cui il programma esegue davvero Git. Il comando nel terminale è soltanto uno di questi; client di sviluppo, CI e servizi che elaborano repository richiedono verifiche separate.