CVE-2026-63395: symlink in isomorphic-git, come verificare e aggiornare alla 1.38.6

CVE-2026-63395 è una vulnerabilità di isomorphic-git, la libreria JavaScript che implementa Git per Node.js e browser. Nelle versioni precedenti alla 1.38.6, il comando git.checkout scrive file attraverso directory che in realtà sono collegamenti simbolici, senza controllarli. Un repository malevolo può quindi far scrivere file fuori dalla working tree, con possibile esecuzione di codice sull'host. Il punteggio CVSS è 8.8 (gravità alta), non risulta sfruttamento attivo nel catalogo CISA KEV e la correzione è disponibile nella versione 1.38.6. Se usi isomorphic-git in un'applicazione, in un tool di CI o in un servizio che clona repository di terzi, aggiorna subito.

Cosa è successo: la vulnerabilità CVE-2026-63395 in isomorphic-git

Il problema è un classico percorso non sicuro nel checkout. Un repository controllato dall'attaccante prima inserisce una directory che è in realtà un symlink verso una cartella esterna, poi in un commit successivo sostituisce lo stato dell'albero con un file figlio sotto quel percorso. isomorphic-git segue il collegamento simbolico nei componenti iniziali del path e scrive il file dove punta il link, non dentro la working tree.

Lo scenario tipico indicato dall'advisory è un clone seguito da un pull. Un singolo clone è sufficiente se il symlink esiste già sul disco o se l'applicazione che usa la libreria accede all'albero tra le due operazioni. La correzione ufficiale, contenuta nella pull request 2370, fa due cose: rifiuta i symlink nei componenti iniziali del percorso di destinazione durante il checkout e respinge nomi di voce dell'albero pericolosi come punto, doppio punto e .git, allineandosi al comportamento di verify_path di Git. La stessa modifica include anche una gestione più robusta dei cicli di riferimenti simbolici e dell'allocazione in applyDelta.

Chi è colpito: versioni vulnerabili di isomorphic-git

• isomorphic-git prima della 1.38.6: vulnerabile.
• isomorphic-git 1.38.6 e successive: corrette.

L'impatto dipende dal filesystem usato dalla libreria:

• Node fs su Linux o macOS: il sistema operativo risolve il symlink e la scrittura finisce fuori dalla working tree. È il caso più grave: scrittura arbitraria di file sull'host e possibile esecuzione di codice.
• Node fs su Windows: la creazione del symlink viene di solito bloccata senza privilegi aggiuntivi, quindi l'attacco in genere non riesce.
• Provider browser o in memoria: l'impatto resta confinato al filesystem virtuale e il problema si presenta solo se il provider implementa creazione e risoluzione dei symlink.

Attenzione alla dipendenza indiretta. isomorphic-git è spesso incluso da altri pacchetti: editor web, strumenti di deploy, bot che sincronizzano repository, plugin di piattaforme low-code. Potresti essere esposto senza averlo mai installato in modo esplicito.

Quanto è grave: punteggio CVSS e sfruttamento attivo

Il vettore è CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, punteggio 8.8. In pratica: l'attacco arriva dalla rete, non serve autenticazione, la complessità è bassa, ma è richiesta un'interazione (far clonare o aggiornare un repository malevolo). L'impatto su riservatezza, integrità e disponibilità è alto, perché scrivere un file arbitrario sull'host significa poter sovrascrivere script di avvio, chiavi SSH, crontab, file di configurazione o codice che verrà eseguito.

Al momento la vulnerabilità non risulta nel catalogo CISA KEV, quindi non c'è evidenza pubblica di sfruttamento attivo. Non è un motivo per rimandare: il fix è pubblico e il diff mostra con chiarezza il percorso da sfruttare.

Come capire se sei esposto: verifica versione, esposizione e log

Verifica la versione installata

• Nella cartella del progetto esegui npm ls isomorphic-git (o l'equivalente con pnpm e yarn): mostra la versione effettiva e chi la richiede come dipendenza.
• Cerca la stringa isomorphic-git in package-lock.json, pnpm-lock.yaml o yarn.lock: lì trovi la versione risolta, non quella dichiarata.
• Per le immagini Docker, entra nel container ed esegui lo stesso controllo: l'immagine può essere stata costruita con un lock file vecchio.

Verifica l'esposizione reale

Chiediti chi decide quale repository viene clonato. Se l'URL arriva da un utente, da un webhook, da un form o da un marketplace di contenuti, sei nel caso peggiore. Se la libreria clona solo repository interni e di fiducia, il rischio scende ma non sparisce, perché un account compromesso può inserire un commit malevolo.

Indicatori da controllare

• Nelle working tree gestite dalla libreria, cerca collegamenti simbolici con find . -type l -ls e verifica dove puntano. Un link verso home, /etc, .ssh o percorsi fuori dal progetto è un segnale forte.
• Controlla file modificati di recente fuori dalla working tree: authorized_keys, .bashrc, .profile, crontab dell'utente che esegue il servizio, file di configurazione dell'applicazione.
• Rivedi i log applicativi per operazioni di clone e pull verso origini sconosciute.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La patch c'è: la versione isomorphic-git 1.38.6, pubblicata nella release ufficiale su GitHub. Per applicarla:

1. Aggiorna la dipendenza con npm install isomorphic-git@1.38.6 (o versione superiore) e rigenera il lock file.
2. Se la libreria arriva come dipendenza indiretta, aggiorna il pacchetto che la include oppure forza la versione con le override del gestore di pacchetti e verifica di nuovo con npm ls.
3. Ricostruisci immagini e artefatti, poi distribuisci su tutti gli ambienti, compresi CI runner e strumenti interni.
4. Esegui i test: la modifica ora restituisce un errore di percorso non sicuro quando trova un symlink nei componenti iniziali, quindi flussi che prima passavano potrebbero fallire in modo legittimo.

Come per altre librerie Node, il problema non è il singolo pacchetto ma la catena di dipendenze. Ne avevo parlato per il driver MongoDB per Node.js: vale lo stesso metodo.

Cosa fare subito: mitigazioni e hardening

1. Aggiorna alla 1.38.6. È l'unica misura risolutiva.
2. Blocca i repository non attendibili finché non hai aggiornato: disattiva le funzioni che clonano URL forniti dagli utenti.
3. Isola il processo. Esegui l'applicazione con un utente dedicato senza privilegi, in un container con filesystem di sola lettura salvo la cartella di lavoro, e senza accesso a chiavi SSH o segreti sul disco.
4. Ispeziona le working tree esistenti alla ricerca di symlink e rimuovile se provengono da origini non verificate.
5. Ruota le credenziali a cui il processo aveva accesso, se hai trovato indicatori sospetti o se il servizio clonava repository pubblici.
6. Segmenta la rete in modo che il server che esegue il clone non possa raggiungere direttamente database e sistemi interni critici.

Se sospetti una compromissione: incident response e analisi forense

Se trovi un symlink che punta fuori dalla working tree o file di sistema modificati senza spiegazione, non spegnere la macchina e non cancellare nulla. Isola l'host dalla rete, conserva i log dell'applicazione e del sistema, esporta la memoria se possibile e fai una copia forense del disco prima di qualsiasi bonifica. Solo così si capisce cosa è stato scritto, quando e con quali privilegi, e si può valutare l'obbligo di notifica al Garante entro 72 ore ai sensi del GDPR se sono coinvolti dati personali.

Nel mio studio seguo la risposta all'incidente con acquisizione forense e analisi; per i costi faccio riferimento al listino, con incident response da 1.500 a 6.000 euro e maggiorazione del 50% per le urgenze. Una checklist generale per le prime ore la trovi nell'articolo sul malware in azienda.

Fonti ufficiali

• Advisory GHSA-9qw7-j9xw-fv9c
• Release isomorphic-git v1.38.6
• Pull request 2370 con la correzione
• Commit 823843d

Hai bisogno di una verifica?

Se non sai se la tua applicazione o la tua pipeline usa isomorphic-git, oppure hai trovato tracce sospette, posso fare un audit delle dipendenze e, se serve, una copia forense dei sistemi coinvolti. Richiedi un preventivo gratuito, rispondo entro 24 ore, oppure scrivimi dalla pagina contatti, anche su WhatsApp.