SneakPeek: l’anteprima di Claude Code esponeva le credenziali

Dopo i test di Anthropic portati offline, di cui abbiamo già scritto, la nuova notizia riguarda uno strumento che molti sviluppatori usano ogni giorno: Claude Code Desktop. I ricercatori di Noma Labs (Noma Security) hanno trovato una falla, chiamata SneakPeek, nel pannello di anteprima che mostra i file HTML creati o modificati da Claude: un file HTML preparato ad arte poteva eseguire JavaScript, leggere file locali e inviarli a un server remoto. Anthropic l’ha corretta, dopo un primo tentativo che i ricercatori sono riusciti ad aggirare.

I dettagli tecnici vengono quasi tutti da CSO Online, che ha letto in anteprima il rapporto di Noma pubblicato il 14 ottobre; Dark Reading e Cybersecurity360 confermano scoperta, impatto e correzione.

Cosa è successo

Lo scenario descritto da Noma è semplice: l’attaccante mette un file HTML malevolo in un repository pubblico, all’apparenza legittimo, e aspetta che uno sviluppatore chieda a Claude Code di esaminarlo. Quando l’applicazione mostra il file nell’anteprima, lo script parte senza altre azioni dell’utente. Dark Reading la definisce una minaccia «zero-click»; secondo CSO Online, per la precisione, basta la richiesta di esaminare il file, senza nessun altro clic.

Tra i dati che lo script poteva leggere ed esfiltrare ci sono chiavi private SSH, credenziali AWS e segreti di GitHub; Dark Reading cita anche i token OAuth di Claude.

Il punteggio è CVSS 8.7 (v4.0), gravità alta, assegnato da Anthropic. Al 14 ottobre non c’era ancora un CVE: secondo Noma, Anthropic stava preparando un GitHub Security Advisory e aveva chiesto l’identificativo. Le fonti non indicano la versione di Claude Code Desktop che contiene la correzione definitiva.

Dettagli tecnici

L’anteprima di Claude Code Desktop usa un pannello di rendering basato su Electron e Chromium. Noma ha individuato tre punti deboli che, insieme, formavano la catena:

1. Soglia di 256 KB. I file HTML sotto i 256 KB venivano convertiti in URL data: codificati in base64, con una Content Security Policy restrittiva che bloccava gli script. Quelli più grandi venivano invece scritti su disco e aperti come URL file://, senza quella CSP. All’attaccante bastava gonfiare il file oltre la soglia.
2. Origine sbagliata. Caricato tramite file://, il contenuto riceveva in Chromium l’accesso al file system locale, invece di restare confinato in un’origine opaca e isolata.
3. Filtro non attivo. L’applicazione ha un meccanismo per bloccare l’accesso a file://, ma secondo Noma non era attivo durante il rendering di file statici, compreso il caso in cui lo sviluppatore apriva i report dei test locali.

La prima correzione di Anthropic bloccava le letture di file dal contesto principale della pagina. Noma l’ha aggirata spostando il codice di lettura in un Web Worker, un thread separato che la correzione non copriva. Dopo la segnalazione del bypass, Anthropic è intervenuta più a fondo, sull’architettura dell’anteprima, e secondo Noma il problema ora è risolto del tutto.

Un punto conta per chi difende: lo script girava nel processo di rendering dell’anteprima, non come azione dell’agente. I controlli pensati per il modello, come permessi degli strumenti e conferme, non lo vedevano. Secondo Sysdig, citata da CSO Online, nemmeno i log dell’agente registrerebbero l’esecuzione: letture di file e connessioni in uscita si vedono solo a livello di sistema.

Mappatura MITRE ATT&CK indicativa, ricavata dai fatti riportati: T1204.002 (User Execution: Malicious File), T1552.001 (Unsecured Credentials: Credentials In Files), T1552.004 (Unsecured Credentials: Private Keys), T1005 (Data from Local System), T1041 (Exfiltration Over C2 Channel).

Impatto per le aziende europee e italiane

Le postazioni degli sviluppatori custodiscono le chiavi della produzione: accessi SSH ai server, credenziali dei cloud, token dei repository e delle pipeline. Una sola postazione compromessa può aprire la strada all’infrastruttura cloud dell’azienda e, attraverso i repository, alla catena di fornitura del software.

Per i soggetti NIS2, l’articolo 21 chiede misure per la sicurezza della catena di approvvigionamento e dello sviluppo dei sistemi: gli assistenti di programmazione con IA rientrano in questo perimetro e vanno inventariati, aggiornati e governati come gli altri strumenti. Vale anche per i fornitori di software della sanità e della pubblica amministrazione, che lavorano spesso su codice e repository di terzi.

Cosa fare subito

1. Aggiorna Claude Code Desktop all’ultima versione su tutte le postazioni e controlla che gli aggiornamenti automatici siano attivi; segui il GitHub Security Advisory annunciato per la versione corretta e il CVE.
2. Fai l’inventario: quali macchine hanno Claude Code Desktop o altri assistenti con anteprima HTML, e con quali versioni.
3. Togli le credenziali di lunga durata dalle postazioni (~/.aws/credentials, chiavi SSH senza passphrase, token personali): usa credenziali temporanee e con permessi ristretti, come suggerisce anche Noma.
4. Ruota le credenziali se prima dell’aggiornamento gli sviluppatori hanno fatto esaminare a Claude Code Desktop file HTML di repository non fidati.
5. Apri il codice di terzi in ambienti separati (macchine virtuali, container, ambienti di sviluppo remoti senza segreti), non nella postazione con gli accessi alla produzione.
6. Sorveglia a livello di sistema le letture di file come ~/.ssh/id_* o ~/.aws/credentials da parte dei processi dell’applicazione e le connessioni in uscita verso destinazioni insolite.

Come aiuta ARXDOME

ARX Sentry tiene l’inventario del software di ogni computer, così sai dove è installato Claude Code Desktop e in quale versione, e raccoglie log ed eventi di sicurezza di macchine e firewall: esecuzioni sospette e traffico in uscita bloccato arrivano nelle pagine del SOC. ARX Horizon arricchisce ogni connessione con la reputazione degli indirizzi di destinazione.

Ultimo aggiornamento: 21 ottobre 2026