Falla in Claude Code: una issue su GitHub arriva ai segreti della CI

Una issue su GitHub aperta da qualcuno senza alcun diritto sul repository è bastata per arrivare ai segreti della sua pipeline di build. Novee Security lo ha mostrato al Black Hat USA il 5 agosto 2026 su tre agenti di codice basati su IA insieme: Claude Code di Anthropic, Gemini CLI di Google e Codex di OpenAI. Nessuno degli attacchi ha rotto un modello. Hanno rotto l'impalcatura attorno al modello, il codice ordinario che decide quali comandi il modello può eseguire.

Come una issue su GitHub arriva ai segreti della CI

Tutti e tre gli agenti si collegano all'integrazione continua allo stesso modo. Un evento del repository, una issue o una pull request, avvia un workflow, il workflow lancia l'agente su un runner e l'agente legge il testo dell'evento come parte del compito. Quel testo lo scrive chi ha aperto la issue. Su un repository pubblico, chiunque.

L'iniezione di prompt per questa via è un problema noto, e ognuno di questi strumenti ha uno strato di validazione che dovrebbe contenerla. La ricerca riguarda il fallimento di quello strato, non la credulità del modello. Su un runner stanno le credenziali che servono alla pipeline: token del repository, chiavi cloud, le chiavi API dell'agente stesso. Chi esegue un comando sul runner arriva a tutto questo.

La falla di Claude Code: un disaccordo sulle virgolette e un contatore di download

La catena contro Claude Code è partita da un disaccordo sulle virgolette. Il validatore dei comandi rimuoveva il testo tra virgolette singole prima di applicare i suoi ventitré controlli di sicurezza, presumendo che una shell trattasse quel contenuto come dati inerti. Poi l'impalcatura passava il comando privo di quelle virgolette. Un valore infilato nel flag --receive-pack di git risultava quindi innocuo in fase di validazione e veniva eseguito sul runner.

Quello che segue è la parte interessante. Anthropic ha corretto, e i ricercatori hanno trovato una seconda via con tac, un comando di sola lettura che rovescia il contenuto di un file, stampando una chiave API al contrario in un log di build pubblico. Corretta anche quella. Il terzo giro, tracciato come CVE-2026-54316, ha rinunciato a stampare qualsiasi cosa: la chiave è uscita un carattere alla volta attraverso il contatore pubblico dei download di un modello su Hugging Face, con la risposta letta dall'esterno. Il punteggio è 9,1 su CVSS v3.1 e 6,0 su CVSS v4; Anthropic la classifica come moderata perché l'attaccante deve prima far entrare contenuto non fidato nel contesto dell'agente. Sono interessate le versioni dalla 0.2.54 in poi, la correzione è arrivata nella 2.1.163, avviso GHSA-fg94-h982-f3mm.

Gemini CLI: il punteggio peggiore dei tre

Allo strumento di Google è andata peggio. CVE-2026-12537 porta un punteggio CVSS di 10,0: il launcher del container analizzava la lista di strumenti consentiti una volta sola, alla registrazione, e a runtime non verificava nulla. Sotto il flag --yolo ogni comando richiesto dal modello veniva approvato in automatico, e un'iniezione di comandi di sistema tramite un file .gemini/.env preparato eseguiva codice sull'host di CI ancora prima che partisse la sandbox. Sono vulnerabili tutte le versioni fino alla 0.39.0 inclusa, la correzione è nella 0.39.1, con l'azione GitHub aggiornata a run-gemini-cli 0.1.22 e avviso GHSA-wpqr-6v78-jr5g.

Con Codex è andata diversamente. Due passaggi di Codex condividevano lo stesso checkout all'interno di un unico job, così il primo poteva scrivere un file AGENTS.md che il secondo caricava poi come istruzioni. La posizione di OpenAI è che la sandbox si è comportata esattamente come documentato, quindi non è stata rilasciata alcuna patch di versione. A cambiare sono state le indicazioni sul workflow: passaggi separati in job distinti e file di istruzioni del repository dichiarati esplicitamente parte della superficie di input non fidata.

Perché l'accesso rubato continua a funzionare

Una ricerca separata di Silverfort, pubblicata il 28 luglio 2026, spiega perché un solo furto vale così tanto. Su macOS, Claude Code CLI scrive il proprio pacchetto OAuth nel portachiavi come password generica, sotto il nome di servizio "Claude Code-credentials", creata tramite /usr/bin/security senza argomenti di controllo degli accessi. La voce eredita la lista di accesso predefinita, che si fida dello strumento che l'ha creata. Poiché quello strumento è un binario Apple di uso generale richiamabile da qualsiasi processo, una sola riga di comando restituisce l'intero pacchetto, senza Touch ID e senza password.

Il pacchetto contiene un token di accesso a vita breve e un token di refresh a vita lunga, insieme alle credenziali dei server MCP collegati. Il problema è il token di refresh: può essere scambiato con nuovi token di accesso finché qualcuno non lo revoca, e non è legato né a un dispositivo né a un indirizzo. Anthropic non lo classifica come vulnerabilità, sostenendo che i processi dello stesso utente sono già fidati, ma dichiara di seguire un irrigidimento del controllo degli accessi come miglioramento in ottica di difesa in profondità. Vale la pena notare che l'app desktop della stessa azienda fa il contrario: lì i token sono cifrati con una chiave legata alla firma del codice, e qualsiasi tentativo esterno di raggiungerla fa comparire la richiesta della password.

Cosa fare se usate questi agenti

• Aggiornare per primo: Claude Code 2.1.163 o successiva, Gemini CLI 0.39.1 insieme a run-gemini-cli 0.1.22. Per Codex non c'è nulla da installare, va cambiato il workflow.
• Non far avviare l'agente da eventi pubblici: un workflow che parte a ogni issue o pull request da qualunque account consegna la superficie di input a estranei. Servono un'etichetta, il commento di un manutentore o un controllo sul fork.
• Ridurre i segreti del runner: date al job il token più stretto con cui riesce a lavorare e tenete le chiavi cloud a lunga durata fuori dai workflow che un agente può toccare.
• Separare i passaggi: se due esecuzioni dell'agente condividono un checkout, la prima può scrivere le istruzioni che la seconda seguirà. Job distinti, checkout distinti.
• Ruotare al sospetto, non alla prova: uscire e rientrare, poi rinnovare le chiavi in console. Ripulire la macchina non invalida un token di refresh già uscito.
• Sorvegliare la stessa sessione su due macchine: il riutilizzo di credenziali da host diversi è proprio il segnale che questi token rendono possibile, perché nulla li lega al dispositivo.

Perché riguarda anche chi non sviluppa

Lo schema si ripete man mano che gli agenti diventano più autonomi: l'attacco non arriva dalla rete come traffico ispezionabile, arriva come contenuto e viene eseguito dentro una sessione già fidata. Abbiamo raccontato la stessa forma quando un browser con IA poteva essere dirottato da un post che l'utente non aveva mai cliccato, ed è per lo stesso motivo che è pericolosa una catena come la falla nel modulo di accesso di WordPress che finisce in codice sul server, pur richiedendo solo che un amministratore apra una pagina. Qui passa anche il limite onesto degli strumenti di privacy di rete. Una VPN nasconde il traffico alla rete in cui vi trovate e sposta la posizione apparente; non ha alcuna visibilità su ciò che il vostro stesso agente decide di eseguire e non si frappone tra un processo e il portachiavi dello stesso portatile. La cifratura in transito non è mai stata il confine che questi attacchi attraversano.

Conclusione