The Pulse

Apiiro scopre che i file di autorizzazione di Claude Code espongono segreti su GitHub

Apiiro afferma che 1122 copie pubbliche del file di impostazioni locali di Claude Code su GitHub contengono segreti reali, 1379 in tutto, salvati quando gli sviluppatori hanno scelto «non chiedere più». Boris del team Claude Code di Anthrop

AI.info Team · Scritto con l’IA · verificato · 2026-11-09

La società di sicurezza Apiiro afferma di aver trovato su GitHub 1122 copie pubbliche di un file di impostazioni di Claude Code che contengono almeno un segreto reale, per un totale di 1379 password, chiavi e token distinti. Il file, .claude/settings.local.json, è il luogo in cui l’agente di programmazione di Anthropic registra i comandi che uno sviluppatore gli ha permesso di eseguire senza chiedere nuovamente. Quando nel comando approvato era stata digitata una password, questa veniva memorizzata insieme al comando in testo in chiaro.

La ricerca è stata scritta da Shmulik Cohen e Matan Giladi di Apiiro. La società afferma di non aver provato nessuna delle credenziali, quindi non può dire quante siano ancora funzionanti. Un’organizzazione che aveva avvertito prima della pubblicazione ha detto ai ricercatori che la propria chiave esposta era attiva.

Come un’autorizzazione diventa una password memorizzata

La stessa documentazione di Anthropic descrive il meccanismo. Quando, alla richiesta di autorizzazione per un comando di shell, uno sviluppatore sceglie «Sì, e non chiedere più», una regola allow viene registrata in .claude/settings.local.json, un file conservato nella cartella principale del repository; la regola si applica poi alle sessioni successive in quel progetto. Come spiega Apiiro, la regola salvata è a volte uno schema, come un comando di test con un carattere jolly, e altre volte la riga di comando esatta. In quest’ultimo caso, qualsiasi cosa vi sia stata digitata, per esempio una password di database dopo PGPASSWORD=, finisce nel file.

La documentazione dice anche che il file è destinato a rimanere sulla macchina dello sviluppatore. La prima volta che Claude Code lo scrive in un repository che non lo ignora già, lo strumento aggiunge una voce corrispondente al file globale delle esclusioni git dell’utente; a uno sviluppatore che crea il file manualmente viene invece indicato di aggiungerlo personalmente a .gitignore.

Secondo Apiiro, come riportano The Hacker News e iTWire, questa protezione si trova nella configurazione git di una sola persona su un solo computer. Non segue il repository in un clone appena creato o su una seconda macchina e non ha alcun effetto su una copia già tracciata da git. I ricercatori affermano di aver riprodotto il comportamento con Opus 5.5 e Fable 5.1, gli attuali modelli di Anthropic.

Che cosa ha contato la scansione

Secondo iTWire, Apiiro ha effettuato la ricerca nei contenuti pubblici di GitHub tra il 1° e il 3 novembre. Le cifre che seguono sono quelle della società, come le riportano le testate che hanno letto il suo resoconto:

• 104.185 copie del file di impostazioni locali, distribuite su 103.617 repository;
• 1122 di queste copie, circa l’1,1%, contenevano almeno un segreto, per un totale di 1379 valori distinti;
• fra questi, 379 password di database, 43 credenziali di accesso SSH per server pubblici, 23 chiavi AWS e 42 token per GitHub, GitLab e npm;
• 2539 segreti distinti in 1994 repository, aggiungendo le versioni precedenti del file, il file condiviso .claude/settings.json di cui i team effettuano intenzionalmente il commit e le trascrizioni salvate delle chat degli agenti.

Eliminare il file non pone fine all’esposizione. Le versioni precedenti nella cronologia git contenevano 734 segreti che non sono presenti in alcuna copia attuale. Apiiro conta 63 organizzazioni tra i proprietari, perlopiù società di software, tra cui un fornitore di database la cui chiave amministrativa per il cloud era presente in una delle copie.

Per Apiiro, un segreto era un valore in un formato di chiave riconosciuto oppure una password o un token collocati accanto all’indirizzo di un server pubblico; ciascuno doveva poi essere confermato da un revisore basato sull’IA. iTWire, che osserva come Apiiro venda prodotti per la sicurezza delle applicazioni e degli agenti, sottolinea che i totali sono risultati della ricerca della società e indicano un’esposizione, non una violazione dimostrata.

Chi ha effettuato il commit dei file

Le due parti non concordano su come i file siano arrivati su GitHub. Boris del team Claude Code di Anthropic, che pubblica con il nome bcherny, ha risposto nella discussione su Hacker News dedicata alla ricerca che il file viene automaticamente escluso da git quando Claude lo crea e ha concluso che le copie esposte erano state create manualmente e inserite nel repository con un commit.

I dati di Apiiro indicano il contrario per circa la metà dei casi che ha ricostruito. In 539 dei 1105 repository con un segreto reale che i ricercatori hanno esaminato a ritroso, il file è stato modificato da un commit che indica Claude come coautore. iTWire aggiunge un’avvertenza: quel conteggio non dimostra che Claude abbia introdotto o inviato ogni credenziale esposta.

Il problema era già noto nel sistema di tracciamento delle segnalazioni di Claude Code. Una segnalazione di bug presentata nell’agosto 2025 descriveva come i comandi approvati contenenti chiavi API e token venissero memorizzati alla lettera nell’elenco locale delle autorizzazioni. Secondo The Hacker News, un bot automatico l’ha chiusa come «non previsto» nel gennaio 2026, dopo 60 giorni di inattività; iTWire avverte che la chiusura non dimostra che il bug sia mai stato corretto.

La risposta di Anthropic finora

La risposta pubblica di Anthropic è arrivata nei suoi commenti sotto il post di Hacker News sulla ricerca. Ha esordito così:

Storicamente Claude Code non ha mai rimosso i segreti (esistono molti buoni strumenti per farlo), ma stiamo valutando cosa possiamo fare per evitarlo.

Boris (bcherny), team Claude Code, Anthropic, su Hacker News

Nella stessa discussione ha detto che il team avrebbe realizzato prototipi di diversi approcci prima di distribuirne uno, tra cui fare in modo che la modalità automatica intercetti questi comandi e aggiungere allo strumento una scansione di base dei segreti. Ha anche esortato gli utenti a passare dalle regole di autorizzazione alla modalità automatica, che ha descritto come più sicura, attiva per impostazione predefinita e gratuita in tutti i piani, e ad attivare la scansione dei segreti offerta da GitHub e da altre piattaforme che ospitano codice. Quando un altro commentatore ha fatto notare che anche la modalità automatica può salvare un’autorizzazione «consenti sempre», ha risposto: «Sì, giusta osservazione».

La modalità automatica si affida a un classificatore per valutare quali comandi Claude Code può eseguire senza chiedere autorizzazione; AI.info ha raccontato il rilascio di settembre che ha reso il classificatore lato server l’opzione predefinita per gli utenti Claude API ed Enterprise e per le distribuzioni cloud. La fuga di dati si aggiunge a una serie di notizie sulla sicurezza relative allo strumento, tra cui quella di un’estensione di Claude Code manomessa sul marketplace di Cursor.

Perché gli strumenti di scansione non hanno rilevato molti file

Gli strumenti standard di scansione dei segreti hanno rilevato solo una parte del problema. Eseguiti sui 1122 file senza il passaggio di verifica, gitleaks ne ha segnalati 564 e TruffleHog 643, mentre 215 sono sfuggiti a entrambi. La maggior parte di quelli non rilevati conteneva password incorporate in normali righe di comando, dopo PGPASSWORD=, sshpass -p o mysql -p, prive dei prefissi dei fornitori che gli strumenti di scansione cercano.

Apiiro avverte inoltre che il file è in semplice formato JSON sul disco dello sviluppatore, dove un malware può leggerlo anche se non arriva mai su GitHub. The Hacker News ricorda che nel settembre 2025 il worm Shai-Hulud ha eseguito TruffleHog sulle macchine infette.

La prima raccomandazione dei ricercatori è di sostituire ogni credenziale che il file abbia mai contenuto prima di procedere a qualsiasi operazione di pulizia, perché fork, cloni e cronologia git conservano le vecchie copie. Dopodiché: smettere di tracciare il file con git rm --cached, inserirlo nel .gitignore di ciascun repository, fare riferimento ai segreti tramite variabili provenienti da un gestore di segreti invece di digitarli nei comandi e approvare schemi di comandi anziché singoli comandi letterali.