Il 10 novembre ANSA ha titolato così: “le password salvate sul computer finiscono sui siti pubblici”. Sembra una di quelle notizie allarmistiche da bar, invece sotto c’è una ricerca seria, con numeri concreti e un colpevole preciso. Il colpevole non è un malware, non è un attacco informatico e non è nemmeno un bug nel senso classico del termine. È un pulsante: quello che clicchi quando Claude Code ti chiede il permesso di eseguire un comando e tu rispondi “Sì e non chiedere più”.
Qui ti spiego cosa è successo, perché il file incriminato finisce su GitHub, come controllare in pochi minuti se il tuo progetto è esposto e ti lascio un prompt pronto da dare a Claude, più una skill da installare in Claude Code per rifare l’audit quando vuoi.
Di cosa parleremo..
Cos’è successo, in breve
La società di sicurezza Apiiro ha pubblicato la ricerca il 5 novembre 2026. I ricercatori hanno scandagliato GitHub cercando un file dal nome poco poetico: .claude/settings.local.json. Ne hanno trovati 104.185 in 103.617 repository pubblici.
Di questi, 1.122 file contenevano almeno un segreto vero, per un totale di 1.379 segreti distinti. Contando anche le copie dello stesso segreto in più repository, le occorrenze salgono a 2.539 in 1.994 repository. Le organizzazioni coinvolte sono 63: dalle squadre di studenti alle software house, fino a università e aziende sanitarie.
Dentro c’erano password di database con dati medici, token di API, chiavi cloud e credenziali SSH di root, in un caso quelle di un’università. Non roba da demo.
Il pulsante che ha causato tutto
Claude Code, come gli altri agenti che scrivono codice, chiede il permesso prima di eseguire comandi sul tuo computer. Se approvi un comando che si ripete spesso, per non essere interrotto ogni trenta secondi scegli “Sì e non chiedere più”.
Quella scelta viene salvata come regola nel file .claude/settings.local.json, nella cartella del progetto. Ed è qui che nasce il problema: la regola non contiene solo “consenti curl”, contiene il comando intero, spesso con dentro il segreto. Un esempio realistico:
{
"permissions": {
"allow": [
"Bash(curl -H "Authorization: Bearer sk-live-..." https://api.example.com/v1/sync)",
"Bash(psql postgres://admin:[email protected]:5432/produzione)"
]
}
}
Il file è JSON in chiaro, senza cifratura. Non è una scelta assurda: serve a farti riusare la regola senza reinserire la password ogni volta. Il punto è che quel file non dovrebbe mai uscire dalla tua macchina. Se hai letto la mia guida completa a Claude Code, lo riconosci: è la stessa logica dei permessi, vista dal lato meno comodo.
Da sapere: il file non è protetto nemmeno sul tuo disco. È in chiaro in un percorso noto e identico su ogni progetto, quindi qualunque malware in esecuzione sul computer sa esattamente dove andare a leggere. La comodità di non reinserire la password ha un prezzo che di solito non vedi.
Perché il file finisce su GitHub
Anthropic lo sa e prova a proteggerti: quando Claude Code crea il file dentro un repository Git, aggiunge il percorso al gitignore globale del tuo utente. Nella maggior parte dei casi funziona. Non funziona in tre situazioni precise.
- La cartella diventa un repository dopo. Se il file esisteva già e solo in seguito lanci
git init, la regola globale può non essere ancora attiva. - Cloni il progetto su un’altra macchina. La regola vive nel tuo utente, non nel repository: su un computer nuovo o su un runner di integrazione continua non c’è.
- Qualcuno ha già committato il file. A quel punto il gitignore non serve più a niente, perché Git traccia quello che ha già in archivio.
C’è un quarto dettaglio, il più fastidioso. Le istruzioni di commit di Claude Code dicono al modello di non committare .env e credentials.json. Il file settings.local.json non è in quella lista. In diversi casi è stato l’agente stesso a metterlo dentro un commit, senza che l’utente se ne accorgesse.
Il risultato è un file che arriva su GitHub con un nome innocuo, dentro una cartella che nessuno guarda, in un repository magari pubblico da anni. Non serve un attacco: basta un push distratto.
Quanto è grave davvero
Il tasso di errore è basso: l’1,1% dei file trovati conteneva segreti. Ma su centomila file pubblici l’1,1% significa oltre mille progetti esposti. Non tutti erano repository abbandonati.
Le credenziali trovate erano attive in molti casi, non semplici segnaposto. Apiiro parla di password di database sanitari, chiavi di servizi cloud, token di integrazione e accessi SSH con privilegi elevati. Roba che, se usata, apre direttamente la porta di casa.
C’è anche un problema di persistenza. Se rimuovi il file dal repository, il segreto resta nella storia Git, nei commit vecchi e nelle copie forkate da altri. GitHub conserva le fork anche quando l’originale viene ripulito. Un oggetto Git può restare raggiungibile per anni.
La ricerca ha anche riprodotto il comportamento sulle versioni più recenti dei modelli, Opus 5.5 e Fable 5.1. Non è un residuo del passato, è il funzionamento attuale.
Attenzione agli scanner: Apiiro ha passato i file a gitleaks e TruffleHog, due strumenti molto usati per cercare segreti. 215 segreti su circa 1.100 non sono stati rilevati da nessuno dei due. Se ti affidi solo a loro, una parte del problema ti passa davanti senza fare rumore.
Cosa dice Anthropic
La questione non è nuovissima. Un bug report su GitHub la segnalava già ad agosto 2025, con altri casi simili arrivati nei mesi successivi. Tutti chiusi automaticamente dopo 60 giorni di inattività.
Dopo la pubblicazione della ricerca, Boris Cherny, responsabile di Claude Code, ha scritto su Hacker News che il team sta “valutando cosa fare per prevenirlo”. Ha aggiunto che questi file non dovrebbero mai finire nel controllo di versione e che i casi osservati sembrano legati a file creati e committati a mano. Ha anche suggerito di usare la modalità automatica e gli scanner di segreti, ammettendo però che anche in auto mode i comandi sensibili possono finire nel file.
Al momento in cui scrivo non c’è una correzione rilasciata, solo promesse e workaround. La parte operativa tocca a te. Conviene farla adesso. Qualche mese fa è andata meglio con l’estensione 2.1.313 manomessa: lì la correzione è arrivata in poche ore. Qui il problema è di progetto, non di pacchetto. Si muove più lentamente.
Come verificare se il tuo progetto è esposto
Il controllo completo richiede dieci minuti. Fallo su ogni progetto in cui hai usato Claude Code. Per sicurezza controlla anche quelli in cui hai usato altri agenti che salvano i permessi in locale.
1. Cerca il file sul disco
find . -name "settings.local.json" -path "*.claude*" -not -path "*/node_modules/*"
2. Controlla se è tracciato da Git
git ls-files | grep -i "settings.local.json"
Se il comando restituisce una riga, il file è dentro il repository. Non significa che sia già pubblico, ma significa che al prossimo push può partire.
3. Guarda la storia, non solo il presente
git log --all --oneline -- .claude/settings.local.json
Se escono dei commit, il file è stato committato almeno una volta. Anche se oggi non c’è più, il contenuto resta nella storia.
4. Cerca il segreto nella storia
git log --all -p -S "password" -- .claude/settings.local.json | head -100
Cambia la parola cercata con quella che usi di solito: Bearer, api_key, token, postgres://. Se trovi un segreto in chiaro, consideralo compromesso.
5. Cerca su GitHub
La ricerca code di GitHub è lo strumento più diretto. Vai su github.com/search, scegli Code e cerca:
path:.claude/settings.local.json org:TUA-ORG
Sostituisci TUA-ORG con la tua organizzazione o con il tuo username. Poi guarda i fork: apri il repository, clicca sul numero di fork e cerca lo stesso file nelle copie. È il passaggio che quasi tutti saltano.
Da fare subito, anche se il controllo è pulito: aggiungi .claude/settings.local.json al .gitignore del repository, non solo a quello globale. È una riga che vale più di qualunque scanner.
Il prompt da dare a Claude
Se non vuoi fare tutto a mano, puoi far fare l’audit a Claude. Il prompt che uso è questo. Funziona sia in Claude Code sia in una chat con il progetto caricato. Copialo così com’è.
Copia il prompt: clicca dentro il riquadro, poi seleziona tutto con Ctrl+A (Cmd+A su Mac) e copia.
Due raccomandazioni. La prima: chiedi sempre sola lettura, altrimenti l’agente potrebbe “ripulire” la storia Git e fare danni. La seconda: chiedi di non stampare i segreti per intero, altrimenti li rimetti in circolo nella chat e nei log.
La skill per Claude Code
Se il controllo ti serve spesso, il prompt non basta: meglio una skill. In Claude Code le skill sono cartelle con dentro un file SKILL.md. L’agente le carica quando la richiesta corrisponde. Creane una in .claude/skills/secret-audit/SKILL.md con questo contenuto:
Copia la skill: clicca dentro il riquadro, poi seleziona tutto con Ctrl+A e copia.
Da quel momento puoi scrivere “fai un secret audit di questo progetto” e Claude segue la procedura senza che tu debba riscrivere il prompt. La skill è volutamente conservativa: non modifica niente e si ferma prima di qualunque azione distruttiva. Se vuoi capire meglio come funzionano queste istruzioni, ho spiegato il concetto di prompt nel glossario.
Cosa fare se trovi una credenziale
L’ordine conta. Non iniziare dalla pulizia di Git: quella è la parte che sembra urgente e invece arriva dopo.
- Revoca la chiave. Se è un token API, cancellalo dal pannello del servizio. Se è una password, cambiala. Se è una chiave SSH, rimuovila da
authorized_keyse dai servizi che la accettano. - Ruota tutto quello che era nella stessa riga di comando. Spesso il comando conteneva più di un segreto: host, utente, password, token.
- Controlla i log del servizio. Se la credenziale era attiva e pubblica, qualcuno potrebbe averla usata. Cerca accessi anomali nelle ultime settimane.
- Rimuovi il file dalla storia con
git filter-repo, non con un semplicegit rm. Poi force push e avvisa i collaboratori di rifare il clone. - Chiedi a GitHub di ripulire le cache. La rimozione dal repository non elimina subito le viste cached e le fork. Per i repository pubblici esiste la procedura di supporto per la rimozione di dati sensibili.
Se il repository è pubblico e la chiave era attiva, la prudenza dice di trattarla come già compromessa. Non è pessimismo, è igiene.
FAQ
Il file settings.local.json è pericoloso anche se non lo pubblico?
Meno, ma non innocuo. È JSON in chiaro in un percorso noto: qualunque malware sul computer sa dove cercarlo. Se il disco non è cifrato, lo legge anche chi ruba il portatile. La regola è tenerlo fuori dal repository e non metterci segreti, quando puoi evitarlo.
Ho cancellato il file, sono a posto?
No. La cancellazione non tocca la storia Git e non tocca le fork. Devi riscrivere la storia, fare force push e ruotare le credenziali. Se il repository è pubblico da mesi, la parte più importante è la rotazione.
Uso Codex o Cursor, il problema mi riguarda?
Il caso specifico è di Claude Code, ma il meccanismo è generale: ogni agente che salva le approvazioni su disco può finire nella stessa trappola. Controlla i file di configurazione locale di ogni strumento che usi, non solo .claude.
gitleaks e TruffleHog non bastano?
Sono utili e vanno usati, ma non sono infallibili. Nella ricerca di Apiiro si sono persi 215 segreti su circa 1.100. Un controllo manuale dei file di configurazione e della storia, fatto una volta, copre quello che gli scanner non vedono.
Devo cambiare tutte le password?
No, solo quelle finite nel file o nei comandi approvati. Ma se il file conteneva un token con permessi ampi, cambia anche ciò che quel token poteva raggiungere. La domanda giusta non è “cosa c’era nel file”, è “cosa poteva fare quella credenziale”.
