Un file di configurazione di Claude Code è comparso in 1.122 copie pubbliche su GitHub con almeno una password, un token o una chiave, secondo l’indagine di Apiiro. L’assistente può salvare letteralmente un comando shell quando l’utente sceglie «Yes, and don’t ask again»; se il comando contiene una credenziale e il file viene pubblicato, quella credenziale resta esposta.
Apiiro ha identificato 1.379 segreti distinti in quelle copie di .claude/settings.local.json. L’azienda non ha verificato se fossero ancora tutti funzionanti, ma un’organizzazione avvisata ha confermato che la propria chiave era ancora attiva. Il conteggio esteso, che include la cronologia Git, i file di configurazione condivisi e i registri delle conversazioni degli agenti, arriva a 2.539 segreti in 1.994 repository.
Cosa salva Claude Code quando ricorda un’autorizzazione
Claude Code di solito chiede l’autorizzazione prima di eseguire comandi shell. Accettando «Yes, and don’t ask again», l’utente crea una regola che consente di eseguire nuovamente i comandi corrispondenti senza chiedere un’altra volta. La documentazione di Claude Code indica che questa approvazione viene salvata nel file locale del progetto, .claude/settings.local.json.
La regola conserva ciò che è stato approvato. A volte si tratta di uno schema, come npm test *; altre volte, di un comando specifico. In quest’ultimo caso, se qualcuno ha scritto una password o un token direttamente nel comando, il valore può essere salvato in testo semplice insieme alla regola. I ricercatori di Apiiro hanno riprodotto il comportamento con i modelli Opus 5.5 e Fable 5.1.
Il file è pensato per le impostazioni personali di un progetto, non per essere condiviso con il team. Claude Code cerca di escluderlo da Git: quando lo crea per la prima volta all’interno di un repository, lo aggiunge al file globale delle esclusioni Git dell’utente. Questa protezione si applica ai repository di quella persona su quel computer, ma non viene inserita nella configurazione del progetto.
L’esclusione globale non rimuove neppure i file già aggiunti al controllo delle versioni. Apiiro osserva che Claude Code non inserisce automaticamente .claude/settings.local.json nel .gitignore del progetto. Perciò la regola non accompagna il repository e non protegge gli altri collaboratori né gli altri team. La documentazione di Anthropic indica inoltre che, se l’utente crea il file manualmente, deve aggiungerlo autonomamente a .gitignore.
La differenza tra un file locale e uno condiviso è importante: .claude/settings.json è la configurazione di progetto che un team può versionare intenzionalmente, mentre .claude/settings.local.json è destinato alle preferenze personali di una persona per quel progetto. Apiiro ha trovato segreti anche nel file condiviso, ma in misura minore.
1.379 segreti nelle copie pubbliche
Apiiro ha individuato 104.185 copie di .claude/settings.local.json in 103.617 repository pubblici di GitHub. Di queste, 1.122 — circa l’1,1% — contenevano almeno un segreto. Per classificare un valore come tale, i ricercatori hanno verificato se corrispondesse a formati di chiavi noti o se una password o un token comparisse accanto all’indirizzo di un server pubblico. Anche un revisore basato sull’IA doveva confermare la classificazione.
Più di un terzo dei segreti consentiva l’accesso diretto a database. L’insieme comprendeva 379 password di database, 43 credenziali SSH per server pubblici, 42 token di GitHub, GitLab e npm e 23 chiavi AWS. Apiiro ha inoltre segnalato alcuni esempi particolarmente rilevanti: una chiave cloud con autorizzazioni di amministratore appartenente a un fornitore di database e la password proprietaria di un database di cartelle cliniche.
I file appartenevano a 63 organizzazioni, perlopiù aziende software di varie dimensioni. Secondo Apiiro, il giorno del conteggio tutti i file contenenti segreti erano ancora presenti nel branch predefinito dei rispettivi repository. In metà di questi repository erano presenti da almeno 217 giorni.
La cronologia Git aggiunge altre esposizioni che non compaiono più nella versione attuale: Apiiro ha trovato altri 734 segreti in versioni precedenti dei file appartenenti a 509 repository. Spesso il file era già stato eliminato, ma il segreto era rimasto nella cronologia. Ha inoltre individuato 211 fork di 74 repository che conservavano gli stessi segreti degli originali.
Il conteggio più ampio include 298 copie di .claude/settings.json contenenti segreti, su un totale di 76.011 file condivisi. Apiiro ha aggiunto anche la cronologia precedente e i registri delle conversazioni degli agenti, arrivando a 2.539 segreti distribuiti in 1.994 repository.
La cronologia delle segnalazioni e i limiti dell’indagine
L’esposizione non era un comportamento appena individuato. Una segnalazione di bug di Claude Code presentata l’11 agosto 2025 avvertiva già che i comandi approvati contenenti chiavi API e token venivano salvati parola per parola in settings.local.json. Un bot ha chiuso la segnalazione il 3 gennaio per inattività durante 60 giorni. iTWire riferisce che la chiusura è stata un’azione automatica di manutenzione, non una risoluzione tecnica.
Apiiro afferma che le quattro segnalazioni correlate citate sono state chiuse dallo stesso bot; la più recente, il giorno precedente alla pubblicazione della sua indagine. Secondo l’azienda, Anthropic non ha risposto a nessuna di esse. Separatamente, a febbraio 2026 la società di sicurezza ironPeak ha descritto di aver trovato comandi approvati contenenti password di database e chiavi API in un file di configurazione di Claude inviato al repository. Ha anche pubblicato uno strumento per cercare segreti nei file di configurazione degli agenti e nella loro cronologia.
Secondo iTWire, Apiiro ha raccolto dati pubblici da GitHub tra il 1° e il 3 novembre. La classificazione combina formati e contesto con una revisione basata sull’IA; non costituisce una verifica indipendente della validità di ogni credenziale. I ricercatori non hanno neppure provato le chiavi trovate né stabilito se qualcuno le avesse utilizzate. L’azienda ha comunicato di aver avvisato le organizzazioni interessate il 2 e il 3 novembre e che una di esse ha confermato che la chiave esposta era ancora attiva.
In 539 dei 1.105 repository che Apiiro è riuscita a tracciare, un commit che includeva Claude come coautore ha modificato il file. Questo dato non dimostra che Claude abbia inserito o pubblicato tutte le credenziali; mostra però che le modifiche al file potevano far parte di commit attribuiti all’assistente.
Apiiro ha confrontato la documentazione di 16 agenti di programmazione e ha confermato che Claude Code era l’unico a salvare per impostazione predefinita il comando approvato completo in un file del progetto. Questo confronto riguarda il comportamento documentato analizzato dai ricercatori, non dimostra che gli altri agenti non possano esporre segreti in altri modi.
Ruotare le credenziali prima di ripulire Git
La raccomandazione principale di Apiiro è cambiare prima tutte le password, i token e le chiavi comparsi in questi file e occuparsi della pulizia in seguito. Eliminare il file corrente non rimuove le versioni precedenti di Git, i fork né le copie scaricate da altre persone. La rotazione riduce il rischio che una credenziale esposta continui a garantire l’accesso mentre si esaminano queste copie.
Per individuare il problema, Apiiro consiglia di cercare .claude/settings.local.json e .claude/settings.json in tutta l’organizzazione e di esaminare la cronologia di ogni repository, anche se il file non è più presente. Consiglia inoltre di smettere di tracciare il file locale con git rm --cached .claude/settings.local.json, aggiungerlo al .gitignore del repository e rimuovere dalla copia locale qualsiasi regola contenente un segreto.
L’azienda raccomanda di non inserire credenziali letterali nei comandi. Una regola può fare riferimento a una variabile come $DB_URL invece di salvare il valore segreto; propone inoltre di autorizzare schemi di comandi anziché comandi singoli. iTWire avverte che assegnare la password letteralmente all’interno di un’assegnazione di variabile in linea lascerebbe comunque il valore nel testo salvato.
La ricerca non dovrebbe limitarsi a GitHub. Apiiro osserva che il file è JSON non cifrato e può finire in un pacchetto npm, un’immagine Docker, un archivio ZIP o una cartella sincronizzata. Consiglia inoltre di trattare directory di agenti come .claude/, .cursor/, .gemini/ e .specstory/, oltre ai relativi file di memoria, come possibili contenitori di segreti su computer e repository.
Anche i normali strumenti di rilevamento non hanno individuato tutti i casi. Apiiro ha eseguito gitleaks e TruffleHog sulle copie senza utilizzare la fase di verifica di questi strumenti. Gitleaks ha segnalato 564 dei 1.122 file contenenti segreti e TruffleHog 643; nessuno dei due ne ha rilevati 215. Secondo i ricercatori, molti errori riguardano password incorporate nei comandi: espressioni come PGPASSWORD=, sshpass -p o mysql -p possono sembrare testo ordinario anziché una chiave con un formato riconoscibile.
Per i team di sicurezza, Apiiro propone di includere questi file nelle scansioni dei segreti in pre-commit e CI, includere la cronologia Git e verificare che lo scanner rilevi le password all’interno dei comandi, non solo le chiavi con formati noti. Raccomanda inoltre di aggiungere il file locale di Claude Code ai modelli organizzativi di .gitignore e di controllare per prime le credenziali associate ai server pubblici.
Il precedente del worm Shai-Hulud spiega perché Apiiro chiede di controllare anche i computer di sviluppo: a settembre 2025, quel malware ha eseguito TruffleHog sui computer infetti e lo scanner ha contrassegnato più della metà dei file come contenenti segreti. L’indagine attuale non stabilisce che le credenziali di Claude Code siano state utilizzate. Documenta però che, almeno in un caso segnalato, una chiave era ancora attiva.
Fonti: The Hacker News, Claude Code Docs, iTWire, NEXSIGHT CYBER WIRE
