Git: repository malevoli possono eseguire codice durante clonazioni ricorsive (CVE-2026-111760)

Cosa è successo

Il 11 novembre 2026 il progetto Git ha rilasciato nuove versioni che correggono sei difetti di sicurezza. Il più grave è CVE-2026-111760. La clonazione ricorsiva di un repository malevolo, cioè comprensiva dei suoi submodule, può eseguire il codice dell'attaccante sulla macchina che esegue la clonazione.

La causa è un troncamento di interi nel modo in cui Git gestisce il proprio indice. Un percorso molto lungo supera il controllo di sicurezza di Git, ma Git lo scrive poi su disco con un nome più corto. L'attaccante può scegliere quel nome più corto. In questo modo può sostituire il file .git di un submodule con un collegamento simbolico a una directory che contiene hook o configurazioni malevoli. Quando Git usa poi quella directory, viene eseguito il codice dell'attaccante. La correzione fa sì che Git rifiuti percorsi così lunghi prima che la loro lunghezza possa essere troncata.

Le stesse versioni correggono altri cinque difetti:

• CVE-2026-113408: Quando si clona un repository vuoto tramite il protocollo Git v2, un server malevolo può inviare un nome di branch che contiene attraversamento di percorso. Con il backend di riferimento basato su file, un successivo aggiornamento di quel branch può scrivere al di fuori della directory dei riferimenti di Git.
• CVE-2026-114467: L'unione di un tag che contiene più di due firme GPG danneggia la memoria dello stack e può causare un denial of service. Anche i servizi di hosting che eseguono tali unioni per i propri utenti possono essere interessati.
• CVE-2026-114469: Una patch binaria che si espande a una dimensione molto grande può superare il limite di dimensione delle patch di Git, pari a circa 1 GiB, e far andare in crash Git con una lettura fuori dai limiti.
• CVE-2026-105437: Un'unione molto grande con molti conflitti e un attributo conflict-marker-size di valore elevato può far scrivere Git oltre la fine di un buffer nell'heap. GitLab indica che i server di hosting del codice sono i bersagli più probabili, tramite git merge-tree, che i server eseguono per verificare se una pull o merge request può essere unita.
• CVE-2026-114466: Tre funzionalità di git fast-import (rewrite-submodules-from, rewrite-submodules-to ed export-pack-edges) potevano essere usate per leggere file arbitrari, oppure per creare file e aggiungervi dati. Git ora le rifiuta in un flusso di input, a meno che non sia impostato --allow-unsafe-features.

Nessuna delle fonti segnala finora attacchi in corso.

Chi è interessato

Sono interessati tutti i sistemi che eseguono una versione di Git precedente a queste versioni corrette: 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. Sui server, questi aspetti sono particolarmente rilevanti:

• Server di build, CI e deployment che clonano repository in modo ricorsivo (git clone --recursive, --recurse-submodules oppure git submodule update --init), soprattutto repository o submodule di terze parti. Perché la CVE-2026-111760 funzioni, il repository clonato deve essere malevolo. Se si clonano solo repository fidati di propria gestione, il rischio è molto minore, ma è comunque consigliato aggiornare.
• Server Git self-hosted che eseguono unioni o verifiche di merge su contenuti inviati dagli utenti (CVE-2026-105437, CVE-2026-114467).
• GitHub Enterprise Server: le correzioni sono nelle versioni 3.19.15, 3.20.11, 3.21.9 e 3.22.4.
• Applicazioni che includono una propria copia di Git. Hanno bisogno di un aggiornamento dal proprio fornitore.

Non interessati: github.com e GitHub Enterprise Cloud. GitHub ha già applicato le correzioni su questi servizi. I server web che hanno Git installato ma non clonano né uniscono mai contenuti provenienti dall'esterno non sono esposti, in pratica, al difetto di clonazione. Si consiglia comunque di aggiornarli durante la prossima manutenzione.

Alla data del 10 novembre 2026, ore 19:09 UTC, Git per Windows non aveva ancora rilasciato una versione basata su Git 2.56.1. Gli amministratori Windows dovrebbero monitorare tale rilascio.

Cosa fare ora

1. Verificare la versione installata su ciascun server con git --version.
2. Installare una versione corretta dal gestore pacchetti del sistema operativo (ad esempio apt update && apt install --only-upgrade git oppure dnf upgrade git). Le distribuzioni spesso includono le correzioni nelle proprie versioni dei pacchetti, quindi consultare l'avviso di sicurezza della propria distribuzione per individuare il pacchetto corretto. Se si compila Git autonomamente, aggiornare alla 2.56.1 o alla versione corretta della propria serie.
3. Aggiornare GitHub Enterprise Server alla 3.19.15, 3.20.11, 3.21.9 o 3.22.4, a seconda della propria linea di rilascio. Aggiornare le altre applicazioni che includono una propria copia di Git non appena il rispettivo fornitore rilascia una correzione.
4. Finché tutti i sistemi non sono aggiornati, seguire le indicazioni provvisorie di GitHub. Questi passaggi non sostituiscono l'aggiornamento:
   • Clonare solo da server di cui ci si fida.
   • Non clonare in modo ricorsivo repository di cui non ci si fida.
   • Non unire contenuti o tag di cui non ci si fida.
   • Non elaborare patch binarie o flussi fast-import provenienti da fonti di cui non ci si fida.
5. Sui server di hosting Git che non possono ancora essere aggiornati, proteggersi dalla CVE-2026-105437. Aggiungere conflict-marker-size=7 al file info/attributes di ciascun repository, oppure disattivare le verifiche di merge per i repository non attendibili.
6. Riavviare i servizi di lunga durata che richiamano Git, come i runner CI o i daemon di hosting Git, in modo che usino il nuovo binario.

Come verificare se si è interessati

• Eseguire git --version. Sono interessate le versioni precedenti alla versione corretta della propria serie: 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 o 2.56.1. Per i pacchetti di distribuzione, confrontare la versione del pacchetto con l'avviso della propria distribuzione anziché con il numero di versione upstream.
• Cercare nei script di build e deployment e nelle configurazioni CI le stringhe --recursive, --recurse-submodules e submodule update. Verificare quali repository clonati provengono da terze parti.
• Cercare copie di Git al di fuori del gestore pacchetti, ad esempio con which -a git. Verificare anche il Git incluso nei runner CI, nei container e in altre applicazioni.

Fonti

• https://nvd.nist.gov/vuln/detail/CVE-2026-111760
• https://thehackernews.com/2026/11/git-patches-flaw-that-lets-malicious.html