Gli assistenti di programmazione AI come Claude Code, Cursor e Grok Build possono eseguire comandi arbitrari nell'istante in cui uno sviluppatore apre un repository non attendibile, senza alcun clic o prompt. Il difetto deriva dal modo in cui questi strumenti invocano la funzione core.fsmonitor di Git per scansionare i file di un progetto.

Perché il problema è rilevante ora

Gli sviluppatori si affidano sempre più agli agenti AI per suggerire codice, rifattorizzare funzioni o persino scrivere interi moduli. Questi agenti hanno bisogno di un'istantanea rapida dell'area di lavoro, quindi eseguono git status in background. Quando Git legge il file .git/config di un repository, qualsiasi valore assegnato a core.fsmonitor viene trattato come un comando shell che Git eseguirà. Un malintenzionato può inserire un comando creato ad hoc in quella voce di configurazione, e la chiamata Git in background dell'IA lo attiverà prima ancora che l'utente digiti una singola riga di codice.

Il codice viene eseguito con i privilegi dello sviluppatore stesso, aggirando il sandbox in cui normalmente opera l'agente AI. In pratica, un repository compromesso può installare malware, esfiltrare credenziali o alterare i file sorgente, il tutto mentre lo sviluppatore crede che l'assistente stia semplicemente offrendo suggerimenti.

Come si sviluppa l'attacco

  1. Preparazione – Un attaccante crea un repository il cui .git/config contiene una riga come core.fsmonitor = /path/to/malicious/script.
  2. Consegna – Il repository viene consegnato come file zip, copiato da una chiavetta USB, sincronizzato tramite un drive condiviso o comunque posizionato sulla macchina della vittima con la cartella .git già presente.
  3. Trigger – Lo sviluppatore apre la cartella in un IDE abilitato all'IA. L'assistente esegue git status per raccogliere il contesto. Git legge la configurazione locale, esegue il comando core.fsmonitor e lo script malevolo viene eseguito immediatamente.

Un semplice git clone non espone questo rischio perché il clone crea una nuova directory .git priva della configurazione manomessa. L'attacco funziona solo quando l'attaccante può fornire una cartella .git preesistente.

Cosa c'è in gioco

  • I singoli sviluppatori possono vedere le proprie macchine compromesse senza rendersene conto, perdendo qualsiasi dato a cui l'agente AI può accedere.
  • I team che condividono codice tramite drive interni o file zip di consulenti possono diffondere il payload su molte workstation.
  • I fornitori di strumenti rischiano danni reputazionali se gli utenti attribuiscono la violazione all'assistente AI piuttosto che all'interazione sottostante con Git.

Poiché il comando malevolo eredita i diritti dell'utente, può modificare qualsiasi file che lo sviluppatore può modificare, incluse le chiavi SSH, gli script di build o le credenziali di deployment.

Passaggi di mitigazione che gli sviluppatori possono adottare oggi

  • Non fidarsi delle impostazioni Git locali. La configurazione di un repository sovrascrive i valori globali ogni volta che un assistente AI interroga il progetto.

  • Ispezionare la voce core.fsmonitor prima di aprire una cartella con un assistente: 

    git config --get core.fsmonitor

    Se appare qualsiasi valore, trattalo come sospetto.

  • Rimuovere la voce con: 

    git config --local --unset core.fsmonitor

  • Controllare altre chiavi rischiose che Git può eseguire: hooksPath, sshCommand, pager, editor, filter. Usa lo stesso schema git config --get per verificare che siano vuote.

  • Preferire clone puliti per qualsiasi codice che si intende fornire a uno strumento AI. Se è necessario lavorare con un file zip o una cartella trasferita, elimina la sua directory .git e reinizializza il repository, oppure esegui prima i controlli sopra indicati.

Di chi è la responsabilità

La vulnerabilità non è un difetto dei modelli linguistici che alimentano Claude Code, Cursor o Grok Build; è una conseguenza del modo in cui questi strumenti raccolgono le informazioni sui file. Alcuni fornitori hanno iniziato a isolare (sandbox) le chiamate Git in modo più rigoroso, ma il comportamento predefinito si affida ancora alle impostazioni del repository locale. Finché l'industria non adotterà uno standard che rimuova o ignori le voci di configurazione potenzialmente pericolose quando un agente AI scansiona un'area di lavoro, gli sviluppatori dovranno rimanere l'ultima linea di difesa.

Cosa monitorare in futuro

  • Aggiornamenti degli strumenti che sanificano esplicitamente la configurazione Git prima di invocare git status.
  • Linee guida guidate dalla community per uno sviluppo sicuro assistito dall'IA, che probabilmente includeranno controlli pre-volo raccomandati.
  • Ricerca sulla sicurezza che potrebbe scoprire ulteriori chiavi di configurazione Git capaci di eseguire codice, espandendo la checklist oltre le cinque evidenziate sopra.

In sintesi: un assistente AI può essere un comodo compagno di programmazione, ma eseguirà volentieri qualsiasi comando nascosto nella configurazione Git di un repository. Verifica l'area di lavoro prima di lasciare che l'assistente la tocchi.