GitSpawn: file .git/config malevoli eseguono codice negli agenti IA prima di qualsiasi azione

Daniel Reyes Ingegnere Principale (IA/ML), YuSMP Group · Sicurezza IA/ML, agenti LLM e sistemi IA in produzione per team statunitensi ed europei

La risposta breve

Come funziona davvero GitSpawn

La chiave di configurazione core.fsmonitor di Git è stata introdotta come ottimizzazione delle prestazioni: invece di scansionare l'intero albero di lavoro a ogni git status, Git può delegare la verifica a un osservatore del filesystem esterno. Il valore della chiave è un comando shell che Git esegue direttamente, passandogli l'ora dell'ultima verifica e aspettando in cambio un elenco di percorsi modificati. In modo critico, Git non dispone di alcun meccanismo per convalidare o isolare questo comando — esegue qualsiasi stringa presente nella configurazione con i privilegi del processo chiamante.

Gli assistenti IA di coding chiamano regolarmente git status, git diff e comandi correlati in background per comprendere lo stato attuale di un repository prima di generare suggerimenti o eseguire azioni agentiche. Quando un tale strumento apre una cartella di progetto contenente un .git/config artigianale, la prima chiamata Git in background attiva l'hook fsmonitor, eseguendo il payload dell'attaccante. Il prompt workspace-trust dell'agente — progettato per impedire alle impostazioni dello spazio di lavoro malevole di eseguire codice — si attiva dopo la raccolta iniziale del contesto Git, non prima. Il payload è già stato eseguito.

Nel proof of concept di Manifold Security, la voce malevola sembrava qualsiasi altra riga di ottimizzazione delle prestazioni a un revisore di codice superficiale. Il ricercatore ha confermato che il payload veniva eseguito prima che l'utente avesse confermato qualsiasi dialogo di fiducia in ogni agente testato. L'attacco è silenzioso: l'agente non mostra errori né avvertimenti; continua a caricare lo spazio di lavoro come se niente fosse.

Come la configurazione malevola vi raggiunge

Questo è il dettaglio più importante per una valutazione accurata delle minacce — e uno che alcune coperture secondarie hanno confuso: un normale git clone non riproduce la vulnerabilità. Quando si clona un repository remoto, Git recupera il database degli oggetti e ricrea l'albero di lavoro, ma non copia il .git/config remoto nel proprio. Il .git/config sulla propria macchina viene generato da zero da Git stesso e contiene solo le impostazioni locali. La voce malevola non arriva mai.

GitSpawn richiede che la directory .git/ venga consegnata intatta, con il .git/config controllato dall'attaccante già all'interno. I vettori di consegna realistici sono:

• Archivi ZIP e tarball. Quando un progetto viene condiviso come cartella compressa, la directory .git/ è inclusa per impostazione predefinita. Un collega che invia via e-mail uno ZIP “starter repo”, un fornitore che fornisce un template di integrazione, o un wiki interno che collega a uno scaffold impacchettato sono tutti canali di consegna validi.
• Unità di rete condivise e archiviazione cloud. La copia di una cartella di progetto da un'unità condivisa preserva .git/ intatto. Comune nei team che usano un NAS condiviso o la sincronizzazione di file cloud invece del corretto controllo di versione per gli strumenti interni.
• USB o supporti esterni. Meno comune nello sviluppo moderno, ma ancora presente in ambienti air-gapped o regolamentati.

L'implicazione pratica per i team è di trattare qualsiasi cartella di progetto ricevuta come archivio con la stessa cautela che si applicherebbe a un eseguibile: verificare la fonte, cercare voci .git/config inattese e considerare di aprire cartelle non attendibili in un ambiente container isolato prima di caricarle in un IDE assistito da IA.

Quali strumenti sono interessati e quali sono stati corretti

Manifold Security ha testato sette agenti IA di coding e ha scoperto che tutti hanno attivato il payload fsmonitor. La cronologia della divulgazione, i CVE e lo stato delle patch al 3 settembre 2026:

Manifold Security ha seguito una divulgazione responsabile, notificando ogni fornitore prima della pubblicazione. Anthropic, Block, OpenAI e Cursor hanno risposto e rilasciato patch prima del writeup pubblico. xAI, Alibaba e il manutentore di Hermes Agent non hanno fornito una correzione entro il periodo di divulgazione. Manifold ha confermato che un percorso di esecuzione secondario in Claude Code potrebbe rimanere aperto nelle versioni fino alla 2.1.252 — Anthropic lo ha riconosciuto e lo sta tracciando separatamente.

Cosa significa per i team di sviluppo

Il messaggio immediato è semplice: aggiornate i vostri strumenti IA di coding. Ma l'implicazione più ampia è strutturale, e riguarda qualsiasi team che ha iniziato a far girare agenti IA con accesso in scrittura al codice o ai filesystem.

Gli assistenti IA di coding sono stati progettati principalmente da un'angolazione della produttività — quanto velocemente possono raccogliere contesto, quante operazioni possono automatizzare, quanto perfettamente possono integrarsi nel flusso di lavoro dello sviluppatore esistente. GitSpawn espone il costo in termini di sicurezza di questa priorità di progettazione. Gli agenti che hanno attivato il payload fsmonitor lo hanno fatto perché stavano facendo esattamente ciò che dovrebbero fare: raccogliere automaticamente e immediatamente il contesto git, senza disturbare lo sviluppatore. Il confine di fiducia — workspace-trust — era progettato per gestire impostazioni dello spazio di lavoro malevole, non un hook Git militarizzato che si attiva prima che lo spazio di lavoro sia completamente caricato.

Per i team nei settori regolamentati, c'è un angolo aggiuntivo. Una macchina dello sviluppatore che fa girare un assistente IA di coding con accesso al codice sorgente, alle variabili d'ambiente e alle credenziali cloud è un obiettivo di alto valore. Un attaccante che può eseguire codice su quella macchina tramite uno ZIP di progetto condiviso può esfiltrare silenziosamente chiavi API, token di sessione e archivi di credenziali locali. Per le organizzazioni soggette a SOC 2, ISO 27001 o alla Direttiva NIS2 dell'UE, questo non è un rischio ipotetico — è una lacuna nell'inventario dei controlli relativi alla sicurezza degli endpoint degli sviluppatori che la maggior parte dei team non ha ancora sottoposto ad audit.

La terza implicazione riguarda i team che costruiscono sistemi di agenti IA, non solo quelli che li usano. Se il vostro prodotto include un agente che opera su file o repository forniti dagli utenti, la stessa superficie di attacco si applica ai vostri utenti. Un audit di come il vostro agente gestisce le operazioni Git, quali hook rispetta e quale modello di fiducia regola l'accesso ai file di terze parti è una precauzione sensata ora, prima che la prossima variante di questa classe emerga. Questo tipo di revisione è esattamente ciò che copre un penetration test incentrato sulle superfici di attacco degli agenti IA.

Prospettiva mercato Italia: L'ACN (Agenzia per la Cybersicurezza Nazionale) ha incluso la sicurezza della supply chain del software tra le priorità del Piano Nazionale per la Cybersicurezza 2022–2026, e vulnerabilità come GitSpawn rientrano esattamente negli scenari di rischio considerati. Per le organizzazioni italiane soggette alla Direttiva NIS2 — recepita in Italia con il D.Lgs. 138/2024 entrato in vigore il 16 ottobre 2024 — questa classe di falle rappresenta un rischio concreto nei processi di gestione della catena di approvvigionamento previsti dall'articolo 21. Le software house e le aziende IT italiane che adottano agenti IA di coding devono includere questa superficie di attacco nelle loro analisi di rischio SGSI e nei capitolati di fornitura software. La prassi comune nelle aziende italiane di condividere archivi di progetto tramite e-mail o piattaforme di collaboration interne rende questo vettore di attacco particolarmente rilevante nel contesto nazionale.

Cosa fare adesso

1. Aggiornate Claude Code alla versione 2.1.196 o successiva. Eseguite npm update -g @anthropic-ai/claude-code o l'equivalente per il vostro metodo di installazione. Monitorate una patch di follow-up che riguarda il percorso secondario.
2. Aggiornate Goose alla versione 1.44.0 o successiva. Controllate il vostro gestore di pacchetti o la pagina delle release GitHub di Goose per l'ultima versione.
3. Aggiornate OpenAI Codex alla versione 0.131.0 o successiva. Eseguite npm update -g @openai/codex o aggiornate tramite la CLI.
4. Aggiornate Cursor. Installate qualsiasi aggiornamento di agosto 2026 o successivo dal sito web di Cursor o dall'updater integrato nell'app.
5. Smettete di usare Grok Build, Qwen Code o Hermes Agent con cartelle di progetto non attendibili fino a quando non saranno disponibili patch. Se questi strumenti sono in uso nel vostro team, emettete oggi stesso una comunicazione di policy.
6. Verificate come vengono condivise le cartelle di progetto. Se il vostro team distribuisce repository di partenza, template di scaffold o archivi di progetto client come file ZIP, aggiungete un passaggio per rimuovere le directory .git/ prima del packaging, o documentate che i destinatari devono verificare .git/config prima di aprirli in un IDE assistito da IA.
7. Aggiungete un controllo degli hook Git al vostro processo di onboarding degli sviluppatori. Un semplice passaggio di lint che segnala core.fsmonitor, core.hooksPath o altri punti di estensione inattesi in .git/config all'apertura del progetto richiede pochi minuti da scrivere e chiude definitivamente questa classe di attacco per il vostro team.

Domande frequenti

Fonti

The Hacker News — Malicious Git Configs Can Make Claude Code, Cursor, and Codex Execute Arbitrary Commands
Manifold Security — AI Coding Agents Git Hijack: GitSpawn Research (Francisco Rosales)