Aprire un repo clonato può eseguire codice prima del trust dialog: la coppia di bug di Claude Code

C'è un gesto che ogni sviluppatore compie decine di volte alla settimana senza pensarci: clona un repository e ci apre dentro il suo agente di coding per capire cosa c'è. Due vulnerabilità di Claude Code, pubblicate a pochi mesi di distanza, hanno trasformato quel gesto innocuo in un vettore d'attacco, ed è il motivo per cui ripeto da tempo che "git clone più apri l'agente" è il nuovo "apri l'allegato". La prima è CVE-2025-59536, pubblicata il 3 ottobre 2025: aprendo Claude Code in una directory non fidata, il codice del progetto veniva eseguito prima che l'utente accettasse il prompt di fiducia (advisory ufficiale GHSA-4fgq-fpq9-mr3g, fix nella versione 1.0.111). La seconda è CVE-2026-21852, pubblicata il 21 gennaio 2026: le impostazioni del repository venivano applicate prima della conferma di trust, permettendo a un repo ostile di catturare la API key dell'utente (advisory GHSA-jh7p-qr78-84p7, fix nella 2.0.65). Sono bug distinti, con meccanismi e gravità diversi, e confonderli è il primo errore da evitare. Le analizzo entrambi e poi mostro la difesa che applico in proprio.

Il trust dialog è una promessa dell'interfaccia, non un confine di sicurezza, se qualcosa viene eseguito prima che tu clicchi. Entrambi questi bug nascono dallo stesso peccato originale: un'azione compiuta a monte del momento in cui l'umano avrebbe dovuto autorizzarla.

Cosa hanno in comune e cosa le distingue?

La radice condivisa è una sola, ed è concettuale prima che tecnica: il trust boundary, il confine oltre il quale il codice di un progetto va considerato fidato, era poroso. In entrambi i casi l'agente faceva qualcosa di consequenziale (eseguire codice, applicare configurazioni che innescano richieste di rete) prima che quel confine fosse stato esplicitamente attraversato dall'utente. Da lì in poi, però, le due vulnerabilità divergono in modo netto, e la tabella seguente è il modo più rapido per tenerle separate.

Già da questa tabella emerge un punto che vale un articolo a sé, ed è puro segnale di competenza per chi scrive di sicurezza: il punteggio CVSS dipende dalla versione dello standard. CVE-2026-21852 è 5.3 in CVSS v4.0 e 7.5 in v3.1 sullo stesso identico bug. Non è un errore, è una divergenza nota tra le due metodologie di scoring, e citare "CVSS 5.3" o "CVSS 7.5" da soli, senza dire quale versione e chi ha assegnato il punteggio, è disinformazione tecnica. Lo scrivo perché è esattamente il genere di sciatteria che riconosci nei contenuti di sicurezza generati senza competenza: un numero nudo, staccato dal suo vettore. La regola, sempre, è riportare versione, stringa del vettore e assessor, perché lo stesso identificativo può raccontare due storie di gravità diversa a seconda di come lo si misura, e un decisore che legge "Medium" dove un altro standard dice "High" prende decisioni di priorità sbagliate.

Se gestisci un team che usa agenti di coding e vuoi impostare una postura di sicurezza che tenga conto di questa classe di vulnerabilità, nel mio hub dedicato all'AI per la sicurezza aziendale raccolgo gli articoli con la metodologia che applico sul campo.

CVE-2025-59536: l'atto di aprire è l'atto di eseguire

Il primo bug è il più grave dei due, 8.7 in v4.0, ed è anche il più istruttivo perché viola un'assunzione mentale profonda. Quando apri un agente in una cartella, ti aspetti che guardare il progetto sia un'operazione passiva, e che qualcosa di attivo accada solo dopo una tua azione esplicita. CVE-2025-59536 rompe questa assunzione: in una directory non fidata, il codice del progetto veniva eseguito prima che il prompt di fiducia comparisse. Tradotto in scenario d'attacco: preparo un repository ostile, lo metto su una piattaforma pubblica con un nome appetibile, e aspetto che qualcuno lo cloni e ci apra Claude Code per ispezionarlo. Nel momento in cui lo fa, ottengo esecuzione di codice sulla sua macchina, con i suoi permessi, prima ancora che abbia avuto la possibilità di dire "non mi fido".

Il dettaglio che rende questo bug pericoloso è proprio la legittimità del gesto della vittima. Ispezionare codice sconosciuto aprendolo in un agente è una pratica raccomandata, quasi un riflesso: è il modo moderno di fare code review di una dipendenza, di un esempio, di un repository segnalato. La vulnerabilità trasforma il comportamento più prudente, guardare prima di fidarsi, nell'innesco dell'attacco. È la stessa dinamica psicologica dell'allegato email: il danno passa attraverso un'azione che sembra cautelativa.

CVE-2026-21852: il file di settings è codice

Il secondo bug è più sottile e merita attenzione proprio perché il suo punteggio più basso (5.3 in v4.0) può indurre a sottovalutarlo. Il meccanismo: nel flusso di caricamento di un progetto, le impostazioni del repository, tra cui la variabile ANTHROPIC_BASE_URL che definisce l'endpoint API a cui l'agente parla, venivano applicate prima della conferma di trust. Un repository ostile poteva quindi includere un file di configurazione che reindirizzava il traffico API verso un endpoint controllato dall'attaccante; quando l'agente partiva e tentava una richiesta, la API key Anthropic dell'utente finiva all'attaccante invece che ai server legittimi. È classificato CWE-522, insufficiently protected credentials, e la lezione che porta è una di quelle che ripeto come un mantra.

Il file di configurazione di un repository è codice eseguibile a tutti gli effetti, perché determina il comportamento di runtime dell'agente. Trattarlo come "dati di progetto" innocui è l'errore che apre la porta: un settings.json può redirigere, abilitare, esfiltrare.

Questa equivalenza, settings come codice, non è teorica. Vale per i file di configurazione degli editor, per gli hook di git, per i task runner, per qualunque file che un tool legga ed esegua all'apertura di un progetto. La superficie d'attacco di un repository non è solo il suo codice sorgente: è tutto ciò che un tool fa automaticamente quando ci entra. Una dinamica analoga, su un altro anello della catena, l'ho analizzata nel caso della RCE via pickle in LangGraph, CVE-2026-27794, nella supply chain di una pipeline LLM: cambia il componente, non il principio.

Perché questo vettore scala: il repository come esca

Capire come un attaccante monetizzerebbe questi bug non è un esercizio morboso, è il modo serio di calibrare la difesa, ed è dove il mio approccio offensivo torna utile. Il punto di forza di questa classe di vulnerabilità è che non richiede di raggiungere la vittima: la vittima viene da te. L'attaccante non deve bucare un perimetro né inviare un'email che superi i filtri antispam; deve solo pubblicare un repository abbastanza interessante perché qualcuno lo cloni e ci apra l'agente. E i pretesti per farlo abbondano nel mondo dello sviluppo.

Il primo è il typosquatting di progetti popolari: un nome quasi identico a una libreria nota, pochi star comprati, e si intercetta chi sbaglia a digitare o copia un comando da un tutorial avvelenato. Il secondo, ancora più efficace contro proprio chi si occupa di sicurezza, è la finta proof of concept: "clona questo repo per riprodurre la vulnerabilità X", esca a cui un ricercatore o un curioso abbocca per dovere professionale, aprendolo nell'agente per studiarlo. Il terzo è la dipendenza transitiva: non il repo che cloni tu, ma uno che il tuo agente esplora automaticamente seguendo un riferimento. In tutti i casi lo schema è lo stesso, ed è la ragione per cui parlo di "esca": l'attaccante prepara il terreno e aspetta che sia il comportamento normale e diligente dello sviluppatore a far scattare la trappola.

Questo capovolge la valutazione del rischio. Un bug che richiede di "aprire un repository malevolo" suona come uno scenario di nicchia, qualcosa che capita agli sprovveduti. In realtà clonare e ispezionare codice altrui è il pane quotidiano di chiunque scriva software seriamente, e farlo dentro un agente è la pratica che gli stessi vendor incoraggiano. La superficie d'attacco, quindi, non è un angolo remoto: è il flusso di lavoro centrale della professione. È esattamente per questo che la difesa non può essere "stai attento a cosa apri", che è un consiglio inutile quando aprire cose è il lavoro, ma deve essere strutturale.

La difesa: aggiornare, isolare, e non fidarsi dell'apertura

La prima contromisura è la più noiosa e la più efficace, e va detta senza giri di parole prima di qualunque tecnica raffinata: aggiornare. Entrambi i bug sono corretti, il primo in 1.0.111, il secondo in 2.0.65. Un agente di coding tenuto a una versione vecchia è esposto a vulnerabilità note e patchate, che è la forma più stupida e più comune di compromissione. La disciplina di patch management, che applichiamo agli OS e ai framework, va estesa agli strumenti AI con la stessa serietà: sono software con privilegi elevati sul tuo sistema, non gadget.

Oltre l'aggiornamento, però, c'è la postura architetturale, perché la prossima vulnerabilità di questa classe non è ancora stata scoperta e la difesa deve reggere anche per quella. Il principio è trattare ogni repository non tuo come contenuto non fidato fino a prova contraria, e non aprirlo a cuor leggero in un agente con accesso pieno alla tua macchina. Per il codice sconosciuto uso ambienti isolati, container effimeri che non vedono le mie credenziali né la mia rete interna, così che anche un'esecuzione non autorizzata cada nel vuoto. In pratica questo si traduce in poche abitudini operative che chiunque può adottare: tenere una chiave API dedicata e a basso privilegio per il lavoro esplorativo, separata da quella di produzione, così che una sua esfiltrazione costi poco e si revochi senza impatto; aprire i repository non fidati in un container o in una macchina che non monta i segreti reali e che non ha rotte verso l'infrastruttura interna; e, banalmente, leggere il settings di un repository prima di aprirlo nell'agente, perché sapere cosa un tool eseguirà automaticamente è il minimo prima di concedergli la propria shell. Sono accorgimenti a costo quasi nullo che spostano l'esito di un attacco da "compromissione della mia postazione e delle mie chiavi" a "un container usa e getta ha eseguito qualcosa di inutile".

La logica di fondo è quella del least privilege applicata agli strumenti AI: ogni capacità che l'agente non ha è una capacità che un attaccante non può abusare attraverso di lui. Non gli serve la chiave di produzione per ispezionare un repo sconosciuto, non gli serve la rete interna per leggere del codice, non gli serve il permesso di scrivere i file di configurazione per analizzarli. Togliere ciò che non serve non riduce l'utilità dell'agente nel lavoro reale, riduce solo la sua superficie d'abuso, ed è la differenza tra uno strumento potente e governato e una bomba a orologeria con i privilegi di root. E sopra l'agente eseguo un perimetro attivo, un hook che ispeziona i comandi e blocca le operazioni distruttive e i canali di esfiltrazione, perché la difesa in profondità non si affida mai a un solo strato. Il security model completo che applico, con il validatore dei comandi, gli env file in sola lettura e il blocco degli host non gestiti, l'ho descritto in dettaglio in come difendo una harness Claude Code in produzione; e le lezioni di architettura che ne stanno alla base le ho raccolte analizzando il leak dello scaffolding di Claude Code.

Vale la pena chiudere inquadrando questi due bug nel framework che li rende leggibili, la lethal trifecta formulata da Simon Willison: un agente diventa pericoloso quando combina accesso a dati privati, esposizione a contenuto non fidato e capacità di comunicare verso l'esterno. CVE-2025-59536 salta direttamente all'esecuzione a partire dal contenuto non fidato; CVE-2026-21852 usa il contenuto non fidato (il settings del repo) per dirottare il canale di comunicazione e rubare il dato privato per eccellenza, la credenziale. Sono due gambe diverse della stessa bestia. La buona notizia è che la difesa non richiede di rinunciare agli agenti di coding, che restano uno strumento di produttività enorme: richiede di trattarli per quello che sono, software privilegiato esposto a input ostile, e di applicare loro l'igiene che applichiamo a qualunque altra cosa con quei privilegi. Se vuoi una valutazione di come la tua organizzazione espone shell e credenziali agli strumenti AI, e di come ridurre quella superficie, puoi usare il modulo di preventivo gratuito: sette domande, due minuti, e ti dico se il tuo caso rientra nel mio perimetro o se ti conviene un'altra figura.