Gli assistenti di codice AI possono essere dirottati da una voce malevola in .git/config che sfrutta la funzione core.fsmonitor di Git, consentendo a un repository non attendibile di eseguire comandi sulla macchina di uno sviluppatore nell'istante stesso in cui l'assistente scansiona i file.

La falla è emersa in diversi agenti popolari: Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build e Hermes. Negli agenti patchati l'exploit non funziona più; gli altri rimangono vulnerabili. Non sono necessari clic o prompt extra, e il codice malevolo viene eseguito con i privilegi dell'utente stesso, al di fuori di qualsiasi sandbox che l'agente AI possa fornire.

Come l'attacco raggiunge uno sviluppatore

  • Un collaboratore esterno zippa un progetto e lo invia via email.
  • Un collega condivide una cartella su un'unità di rete.
  • Viene consegnata una chiavetta USB contenente un codebase.

In ogni caso, il repository arriva come una directory che contiene già una cartella .git. Quando un assistente AI apre la cartella, solitamente esegue git status in background per generare una visualizzazione del codice. Git velocizza questa operazione con l'impostazione core.fsmonitor, che istruisce Git a chiamare un programma esterno per monitorare il file system alla ricerca di modifiche. Se il file .git/config del repository definisce un comando malevolo per core.fsmonitor, Git lo esegue automaticamente, senza consultare l'utente.

Poiché il comando è lanciato dallo stesso Git, eredita i diritti dell'utente e bypassa qualsiasi sandbox che lo strumento AI possa aver configurato. L'exploit non si attiva durante un normale git clone, git fetch o git pull; si attiva solo quando il repository viene scompattato con i suoi metadati .git già presenti.

Perché il problema è importante

Gli sviluppatori si affidano sempre più agli assistenti AI per suggerire completamenti, rifattorizzare il codice o generare interi moduli. Questi strumenti hanno bisogno di un rapido snapshot dell'albero dei file del progetto, quindi invocano i comandi Git silenziosamente. Se un repository malevolo può eseguire codice in quel momento, un attaccante ottiene un punto d'appoggio sulla workstation dello sviluppatore senza alcun avviso visibile. Il payload potenziale spazia dal furto di credenziali all'installazione di backdoor persistenti, il tutto mentre l'utente crede di stare semplicemente "controllando" il codice con un assistente AI.

Come rilevare un repository avvelenato

Prima di consegnare un repository a un assistente, esegui:

git config --get core.fsmonitor

Un output non vuoto significa che un programma è impostato per essere eseguito automaticamente. Per un controllo più ampio, elenca eventuali impostazioni Git sospette:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Se individui voci che non hai aggiunto, cancellale con:

git config --local --unset core.fsmonitor

Nota che impostare git config --global core.fsmonitor false non ti protegge. Le impostazioni locali del repository sovrascrivono sempre quelle globali, quindi un repository malevolo può semplicemente ignorare una regola globale.

Stato attuale delle patch

  • Claude Code – patchato (fsmonitor)
  • Cursor – patchato
  • OpenAI Codex – patchato
  • Goose – patchato
  • Qwen Code – non patchato
  • Grok Build – non patchato
  • Hermes – non patchato

Gli sviluppatori che utilizzano gli agenti non patchati dovrebbero considerare qualsiasi repository in entrata come potenzialmente pericoloso finché non cambiano strumenti o non applicano politiche Git locali più rigorose.

Controargomentazione della comunità Git

Il core.fsmonitor di Git è una funzione di prestazione legittima, non un bug. I manutentori sostengono che la responsabilità di convalidare il contenuto del repository prima di invocare i comandi Git spetti a chi effettua la chiamata. Disabilitare la funzione globalmente è una mitigazione semplice, ma come già notato, le sovrascritture locali possono vanificare tale protezione. La discussione più ampia ora si concentra sul fatto se gli assistenti AI debbano isolare in una sandbox tutte le invocazioni esterne di Git o rifiutarsi di elaborare i repository che contengono hook fsmonitor personalizzati.

Cosa monitorare in futuro

  • Aggiornamenti dagli agenti AI non patchati, specialmente eventuali dichiarazioni riguardanti l'isolamento (sandboxing) delle chiamate Git.
  • Possibili cambiamenti nella gestione predefinita di Git per core.fsmonitor in cartelle non attendibili.
  • Strumenti di terze parti in grado di sanificare il file .git/config di un repository prima che raggiunga un assistente.

Conclusione

Una singola riga in un file di configurazione nascosto può trasformare una comodità basata sull'IA in un vettore di esecuzione di codice remoto. Finché gli agenti vulnerabili non saranno corretti, la pratica più sicura è sottoporre ad audit ogni repository che arriva al di fuori di un normale flusso di lavoro di clonazione e rimuovere qualsiasi hook core.fsmonitor o simili prima di consentire a un assistente AI di toccare il codice.