La sandbox di rete di Claude Code — quella cosa che dovrebbe impedire all’agente AI di chiamare host non autorizzati — è stata bypassata completamente per oltre cinque mesi. E no, Anthropic non ha pubblicato un advisory. Neanche questa volta.
Il ricercatore Aonan Guan ha reso pubblico il secondo bypass completo della sandbox in meno di sei mesi. Non un bug isolato, sostiene, ma un pattern di implementazione fallata. Il problema? Un attacco di tipo SOCKS5 hostname null-byte injection che ha colpito ogni versione di Claude Code dalla 2.0.24 (sandbox rilasciata il 20 ottobre 2025) fino alla 2.1.89. Circa 130 versioni pubblicate. Circa 5 mesi e mezzo di esposizione.
Anthropic ha corretto il tutto in silenzio nella versione 2.1.90, rilasciata il primo aprile 2026. Senza una riga nelle note di rilascio. Senza CVE dedicato. Senza niente.
Come funziona il bypass (e perché è elegante quanto pericoloso)
Il bug nasce da una parser differential vulnerability. Due componenti del sistema interpretano la stessa stringa in modo diverso. Classico.
Claude Code instrada il traffico in uscita attraverso un proxy SOCKS5 locale che applica una policy basata su una allowlist configurata dall’utente — per esempio, solo domini *.google.com. Il filtro JavaScript usa un controllo endsWith() per validare gli hostname contro questa lista.
Ora, immagina di passare un hostname del tipo:
attacker-host.com\x00.google.com
Il filtro JavaScript vede che la stringa termina con .google.com e approva la connessione. Ma la risoluzione DNS sottostante, gestita da libc/getaddrinfo(), tratta il byte nullo \x00 come terminatore di stringa. Quindi risolve solo attacker-host.com. Risultato: il proxy dice sì, ma l’host effettivo è quello dell’attaccante.
Il commit di fix nel repository sandbox-runtime conferma tutto: ‘Block null-byte allowlist bypass’. Descrive esattamente il caso evil.com\x00.allowed.com che passava il controllo .endsWith('.allowed.com') ma veniva troncato dal DNS e connesso a evil.com.
Cosa poteva essere rubato (spoiler: tutto)
Se un attaccante riusciva a far eseguire codice dentro la sandbox — diciamo, tramite prompt injection nascosta in una issue GitHub, un commento PR, un README malevolo letto da Claude Code — il bypass trasformava il proxy in un canale di esfiltrazione verso Internet.
Le fonti elencano come potenzialmente esposti:
- Credenziali AWS da
~/.aws/e token GitHub da~/.config/gh/ - Chiavi API, environment variables, token del modello
- Metadata cloud da endpoint come
169.254.169.254 - Endpoint intranet e API interne raggiungibili dall’host
- Codice sorgente, repository privati, tutto ciò a cui l’agente aveva accesso
Il rischio era massimo su macchine di sviluppo o runner CI/CD con segreti reali, allowlist tipo wildcard (*.google.com, *.anthropic.com) e permessi concessi all’agente per leggere ed eseguire contenuti non fidati.
Il primo bypass: CVE-2025-66479 (quello della semantica rovesciata)
Questo è il secondo bypass della sandbox. Il primo, catalogato come CVE-2025-66479, riguardava una semantica di configurazione completamente errata: configurare allowedDomains: [] — che un utente intende come ‘blocca tutto’ — veniva interpretato dal codice come ‘nessuna allowlist attiva’, quindi permetteva traffico esterno senza limiti.
NVD conferma: prima di sandbox-runtime 0.0.16, la sandbox non applicava correttamente le restrizioni di rete quando non erano configurati domini consentiti.
La critica del ricercatore è che il CVE fu assegnato a sandbox-runtime — un componente interno — non a Claude Code come prodotto usato dagli utenti finali. E che non ci fu un advisory specifico per chi aveva Claude Code installato.
Quel bug fu corretto in silenzio nella versione 2.0.55 il 26 novembre 2025. La stessa release che conteneva ancora il bypass SOCKS5 null-byte.
Timeline delle versioni vulnerabili
Secondo Guan, ecco la finestra di esposizione:
| Periodo | Stato |
|---|---|
| 20 ottobre 2025 – 26 novembre 2025 | Vulnerabile sia al bug allowedDomains: [] che al bypass null-byte SOCKS5 |
| 26 novembre 2025 – 31 marzo 2026 | Primo bug corretto, ma bypass SOCKS5 ancora presente |
| Dal 1 aprile 2026 (Claude Code 2.1.90) | Bypass SOCKS5 corretto |
Le versioni affette: Claude Code 2.0.24 fino a 2.1.89. Versione corretta: 2.1.90 o successiva.
La patch (e il silenzio di Anthropic)
La correzione tecnica è nel commit fd74a3f del repository anthropic-experimental/sandbox-runtime. Vengono aggiunte validazioni come isValidHost() e controlli contro null byte, %, CRLF e altre forme di input hostname problematico.
La release Claude Code v2.1.90 del primo aprile 2026 contiene molte note — feature, bugfix, hardening PowerShell — ma non nomina esplicitamente una fix di sicurezza per questo bypass SOCKS5. Nessuna voce chiara sul network sandbox bypass.
SecurityWeek ha contattato Anthropic. La risposta riportata: il team di sicurezza aveva già identificato e corretto il problema prima della segnalazione di Guan. Apprezzano il lavoro, ma il bug era già noto internamente.
Tuttavia, al 10 maggio 2026, non risulta pubblicato alcun CVE per il bypass SOCKS5 né nel NVD né nel GitHub Advisory Database. CVE-2025-66479 rimane l’unico CVE registrato per entrambe le vulnerabilità della sandbox, ed è stato assegnato a sandbox-runtime, non a Claude Code.
La pagina degli advisory di sicurezza di Claude Code non elenca vulnerabilità della sandbox.
Cosa fare ora (se usi Claude Code)
Verifica subito la versione:
claude --version
Se è tra 2.0.24 e 2.1.89, aggiorna a 2.1.90 o successiva. Subito.
Se hai usato Claude Code in sandbox con wildcard allowlist su una macchina contenente segreti tra il 20 ottobre 2025 e la data di upgrade, tratta quel periodo come potenziale esposizione:
- Ruota token GitHub, chiavi AWS/cloud, API key
- Ruota credenziali presenti in environment variables o file di configurazione accessibili
- Controlla log di egress/SOCKS/proxy per connessioni fuori allowlist
- Rivedi runner CI e workstation dove Claude Code aveva accesso a repository privati o segreti
La lezione (che nessuno impara mai)
La raccomandazione di fondo del ricercatore è chiara: considerare la sandbox del vendor come defense-in-depth, non come boundary primaria.
Non affidatevi alla sandbox dell’agente come unico perimetro. Usate VM o container disposable, network namespace o firewall esterni non modificabili dall’agente. Niente credenziali long-lived sulla macchina di sviluppo. Tool e permessi minimi per l’agente.
Perché se una cosa può essere bypassata due volte in sei mesi, la domanda non è se succederà di nuovo. È quando.
