La falla GitSpawn negli assistenti di programmazione e la misura NIS che ammette solo software aggiornato

Il primo settembre Manifold Security ha pubblicato la ricerca di Francisco Rosales su una famiglia di falle che chiama GitSpawn. Riguarda sette assistenti di programmazione con intelligenza artificiale, fra cui Claude Code di Anthropic, Codex di OpenAI e Cursor. Il meccanismo è quasi imbarazzante per quanto è ordinario. Il modello non c'entra e nemmeno la richiesta scritta dall'utente. Il problema sta nei comandi git che l'agente lancia da solo, in background, per capire in quale progetto si trova.

Cosa succede quando un agente apre una cartella

Appena si apre una cartella, quasi tutti gli agenti esaminati eseguono git status o git diff per raccogliere il contesto. Questi comandi costringono git ad aggiornare il proprio indice, e durante l'aggiornamento git legge la configurazione locale del repository, il file .git/config. Alcune impostazioni di quel file indicano un programma da eseguire. La più nota è core.fsmonitor, pensata per chiedere a un programma esterno quali file sono cambiati invece di controllarli uno per uno. Se il file la fa puntare a uno script dell'attaccante, git lo esegue con i privilegi dell'utente.

Secondo Manifold in alcuni agenti questo avveniva prima che l'utente scrivesse qualsiasi richiesta e prima della schermata che chiede se ci si fida della cartella. In certi casi succedeva addirittura prima dell'autenticazione. Nella scheda della CVE-2026-19592, pubblicata lo stesso giorno, OpenAI scrive che il programma dell'attaccante gira fuori dalla sandbox dei comandi di Codex e senza richiesta di approvazione. Il punteggio di gravità assegnato è 7,3 su 10.

C'è un limite che ridimensiona il rischio. Un normale git clone non copia la configurazione locale del repository di origine, quindi scaricare un progetto da GitHub non basta a infettarsi. Il file velenoso arriva solo quando la cartella viaggia intera, con dentro la sua .git. Manifold elenca l'archivio .zip, il disco condiviso, la cartella sincronizzata e la chiavetta. Sono proprio i canali con cui il codice passa fra un'impresa e un fornitore esterno. Un prototipo a fine progetto si consegna spesso come archivio con la cartella .git dentro, perché il cliente erediti la storia delle modifiche, e chi lo riceve lo apre con l'assistente che usa tutti i giorni.

Chi ha corretto e chi no

Manifold ha inviato otto segnalazioni fra il 26 giugno e il 20 luglio. Il primo settembre ha verificato di nuovo sull'ultima versione disponibile tutti i risultati ancora aperti. Claude Code aveva chiuso il percorso di core.fsmonitor con la versione 2.1.196. Cursor aveva corretto e Codex pure, a partire dalla versione 0.131.0 della riga di comando. Goose aveva corretto con la 1.44.0. Restavano aperti Hermes Agent, Qwen Code, Grok Build e un secondo percorso dentro Claude Code. Quest'ultimo passa dal comando ultrareview, sfrutta un'altra impostazione di git della stessa famiglia e nella versione 2.1.252 non era neutralizzato.

Le risposte dei produttori contano quanto le correzioni. Alibaba ha accettato la segnalazione su Qwen Code senza rilasciare una correzione. La segnalazione su Grok Build è stata chiusa come doppione di una precedente classificata come informativa, cioè senza impatto sulla sicurezza. Per Hermes Agent Manifold racconta sei tentativi di contatto su cinque canali e un avviso privato su GitHub mai preso in esame. Il codice CVE-2026-71963 lo ha assegnato VulnCheck, un ente terzo, e non il progetto.

Anche Claude Code mette in difficoltà chi deve seguire le vulnerabilità. Il changelog ufficiale della versione 2.1.265, dell'8 settembre, riporta una correzione alle sonde git status e git diff di Claude Code. Queste eseguivano i clean filter configurati da un repository annidato dentro la cartella di lavoro, un'altra impostazione di git capace di lanciare comandi. Il changelog non dice se sia il percorso segnalato da Manifold. Chi si occupa di sicurezza lo ricostruisce solo leggendo le note di rilascio riga per riga. Chi ha disattivato l'aggiornamento automatico può non accorgersene affatto.

Cosa chiede l'allegato 1 della determinazione ACN

In Italia la direttiva NIS2 è stata recepita con il decreto legislativo 138 del 2024. Le misure concrete le ha fissate l'Agenzia per la cybersicurezza nazionale con la determinazione 379907 del 19 dicembre 2025, applicabile dal 15 gennaio 2026. L'articolo 3 concede diciotto mesi dalla ricezione della comunicazione di inserimento nell'elenco dei soggetti NIS. L'Agenzia ha iniziato a inviare quelle comunicazioni il 12 aprile 2025, quindi il termine non è lo stesso per tutti. Per chi le ha ricevute quel giorno cade il 12 ottobre 2026. Il 31 ottobre che circola come data unica vale solo per chi ha ricevuto la comunicazione a fine aprile. Chi è entrato nell'elenco nel 2026 ha tempo fino al 31 luglio 2027.

Nell'allegato 1, quello per i soggetti importanti, tre misure toccano direttamente un assistente di programmazione. La ID.AM-02 chiede un inventario aggiornato delle applicazioni software, comprese quelle «commerciali, open-source e custom». La ID.RA-08 chiede di seguire almeno i canali del CSIRT Italia e di risolvere prontamente le vulnerabilità con aggiornamenti o misure di mitigazione. La più netta è la PR.PS-02, al punto 1.

Fatte salve motivate e documentate ragioni normative o tecniche, in accordo agli esiti della valutazione del rischio di cui alla misura ID.RA-05, è installato esclusivamente software, ivi compresi i sistemi operativi, per il quale è garantita la disponibilità di aggiornamenti di sicurezza.

Se la leggo accanto alla ricerca di Manifold arrivo a una conclusione netta. Un produttore che lascia senza risposta per sei settimane la segnalazione di una falla che esegue codice non dà la garanzia richiesta dalla misura. In un'impresa NIS quell'agente va disinstallato prima del termine. Tenerlo sotto osservazione non basta.

Si può obiettare che la misura ammette eccezioni motivate. Si può anche obiettare che basta controllare il file .git/config prima di aprire una cartella, come suggerisce la stessa Manifold. Sulla carta la difesa regge. In pratica chiede a ogni sviluppatore di ricordarsi un controllo manuale su ogni archivio ricevuto. Un'eccezione documentata per uno strumento gratuito, che si sostituisce in un pomeriggio con uno già corretto, è poi difficile da motivare davanti a un ispettore.

L'inventario che manca

La parte davvero debole sta altrove. Gli assistenti di programmazione raramente passano da un ufficio acquisti. Li installa il singolo sviluppatore con un comando da terminale, spesso nella versione gratuita. Così nell'inventario richiesto dalla ID.AM-02 non entrano. Quando il codice lo scrive un fornitore il problema si allarga. L'agente gira su un computer che l'impresa non gestisce e che ha comunque accesso ai suoi repository, a volte anche ai suoi server. La misura GV.SC-07 chiede di valutare proprio il livello di accesso del fornitore ai sistemi informativi e di rete. La valutazione dei fornitori però di solito si ferma al contratto e alle certificazioni. Di rado arriva a chiedere quale assistente è installato sul portatile di chi scrive il codice.

Per chi ha ricevuto la comunicazione dell'Agenzia ad aprile 2025 il lavoro da fare entro il 12 ottobre ha confini chiari. Bisogna registrare nell'inventario, con la versione installata, ogni assistente di programmazione presente sui computer dei dipendenti e dei fornitori che accedono ai repository. Poi va tolto ogni assistente che, al momento della registrazione, ha una falla di esecuzione di codice pubblica da più di trenta giorni senza correzione. Se entro il primo ottobre non avranno rilasciato una correzione, in quella lista entrano Hermes Agent, Qwen Code e Grok Build.