Git 2.56.1 corregge sei vulnerabilità, e i vostri runner CI ne hanno bisogno più del vostro laptop

Il 10 novembre il progetto Git ha rilasciato Git 2.56.1, insieme a versioni corrette per le linee di manutenzione precedenti: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. Complessivamente chiudono sei CVE: CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 e CVE-2026-114466. Il progetto parla di un insieme di rilasci coordinati di correzioni di sicurezza e chiede di aggiornare appena possibile. I bug sono stati trovati da Luke Martin e pwn2addr.

Quella a cui prestare attenzione è CVE-2026-111760, valutata High con CVSS 8.0 nell'advisory di sicurezza del progetto. In breve: il codice dell'indice di Git ha un bug di troncamento di interi. Un percorso molto lungo viene controllato con il nome completo, ma poi finisce su disco con un nome più corto. Un attaccante può sfruttare questa discrepanza per sostituire il file .git di un sottomodulo con un symlink verso una directory sotto il suo controllo, piena di configurazioni o hook propri. Gli hook sono codice. Quindi un clone ricorsivo del repository sbagliato può finire con l'esecuzione del codice di qualcun altro sulla vostra macchina. L'advisory afferma che si ritiene raggiungibile solo passando --recurse-submodules.

GitHub ha già aggiornato github.com, GitHub Enterprise Cloud e Enterprise Cloud con data residency. Se gestite GitHub Enterprise Server in proprio, le versioni corrette sono 3.19.15, 3.20.11, 3.21.9 e 3.22.4.

Per la maggior parte dei team il punteggio sottostima il problema

Leggendo il vettore CVSS potreste rilassarvi un po': complessità d'attacco alta, privilegi bassi, interazione dell'utente richiesta. Su un laptop da sviluppatore è corretto: qualcuno deve clonare ricorsivamente un repository ostile.

Ma pensate a chi esegue davvero git clone nella vostra organizzazione. Per lo più non sono persone, ma i runner CI, centinaia di volte al giorno, senza nessuno che guardi e con chiavi di deploy e credenziali cloud nelle variabili d'ambiente. «Interazione dell'utente richiesta» significa poco quando l'utente è un file YAML.

Quando sviluppiamo app cloud-native per clienti enterprise, il Git che conta raramente è quello sul laptop di qualcuno. È quello incorporato in un'immagine Docker di base scelta un anno e mezzo fa, quello di un runner self-hosted, quello di un container di deploy. Aggiornare i pacchetti sul vostro Mac non tocca nulla di tutto questo. Dal nostro lavoro con PHP e Docker, la mia stima onesta è che la maggior parte dei team abbia tre o quattro versioni diverse di Git nei percorsi di build e deploy e non saprebbe elencarle senza andare a controllare.

I team mobile hanno la loro versione del problema. Nei nostri progetti nativi iOS e Android i sottomoduli sono ancora un modo comune per includere SDK condivisi, librerie native vendorizzate o un UI kit interno. Le macchine di build sono spesso Mac di lunga durata che nessuno reinstalla da una vita. Inoltre il progetto Git raccomanda espressamente di aggiornare ogni applicazione che includa una propria copia di Git, il che riguarda parecchi IDE e client desktop. Aggiornare il Git di sistema non li sistema.

Sul fronte della sicurezza, è uno schema che incontriamo di continuo. Nei nostri pentest la pipeline di build è spesso la via d'accesso più facile, perché si fida di cose che nessuno lascerebbe avvicinare alla produzione: il fork di un collaboratore esterno, il progetto di esempio di un fornitore, una dipendenza open source inclusa come sottomodulo. Si dimentica che gli hook sono eseguibili. Gli attaccanti no.

Ammetto di avere sentimenti contrastanti. Sei CVE in un colpo solo, in uno strumento così vecchio e di cui ci si fida tanto, è un po' inquietante. Allo stesso tempo, correzioni coordinate su sette linee di rilascio sono esattamente la manutenzione noiosa e competente che si vuole da un progetto da cui tutti dipendono. La correzione c'è. La parte difficile spetta a noi: trovare ogni copia.

Cosa farei questa settimana

1. Fate l'inventario di ogni binario Git, non solo dei laptop. Eseguite git --version dentro le immagini CI, i Dockerfile, i runner self-hosted e i Mac di build. Vi serve la 2.56.1, o la versione corretta per la vostra serie (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 o 2.50.2).
2. Ricostruite le immagini di base di proposito. Non date per scontato che la prossima ricostruzione programmata includa un Git corretto. Controllate la versione nell'immagine prodotta.
3. Se ospitate GitHub Enterprise Server in proprio, passate alla 3.19.15, 3.20.11, 3.21.9 o 3.22.4.
4. Cercate nella configurazione delle pipeline i checkout ricorsivi dei sottomoduli. Dove il repository padre o un sottomodulo non è del tutto sotto il vostro controllo, disattivate la ricorsione finché il runner non è aggiornato.
5. Finché non è tutto aggiornato, seguite le indicazioni provvisorie del progetto: clonate solo da server di cui vi fidate, evitate i cloni ricorsivi di ciò che non è affidabile e fate attenzione a unire contenuti o tag esterni, applicare patch binarie o fornire stream fast-import da fonti che non controllate.

Per i nostri clienti svizzeri con requisiti di compliance aggiungerei un sesto passo: annotate cosa avete aggiornato e quando. Gli auditor amano le prove, e per una patch così diffusa conviene averle pronte invece di ricostruirle dopo. Questo tipo di igiene delle pipeline rientra tra le attività quando configuriamo l'infrastruttura di build e deploy, e emerge continuamente nelle nostre revisioni di sicurezza.

Se non siete sicuri di quante copie di Git si nascondano nella vostra pipeline di build, parliamone.