Quando sono sicure le AI Cloud? Claude Code poteva esporre token GitHub e credenziali

Una vulnerabilità in Claude Code ha permesso per mesi di aggirare la sandbox dell'agente AI tramite un bug nella gestione degli hostname SOCKS5. Il problema avrebbe potuto consentire l'esfiltrazione di token GitHub, credenziali cloud e dati infrastrutturali sensibili. La questione solleva dubbi sulla gestione delle patch silenziose e sulla reale affidabilità delle protezioni integrate negli agenti di intelligenza artificiale.

E’ bello aprire Visual Studio Code, collegarlo ad un server via SSH e dare in mano lo sviluppo “vibe” a Claude Code. Ma far accedere Claude all’intero codice sorgente delle applicazioni, potrebbe essere un grave rischio per la sicurezza.

E ovviamente, se il codice sorgente è relativo ad un sistema di “sicurezza nazionale”, tutto cambia da male a peggio perché non entra solo in gioco il concetto di “tecnologia sovrana”, “spesa del cloud”, “data sovereignty” e “vendor lock-in”, ma anche di “jurisdictional control”, cioè la possibilità che infrastrutture, dati o software strategici europei ricadano sotto giurisdizioni extra-UE.

Claude Code ha scoperto negli ultimi mesi una vulnerabilità che ha permesso di aggirare la sandbox dell’agente AI. Secondo il ricercatore Aonan Guan, il problema avrebbe potuto essere sfruttato per il furto di dati, ma gli sviluppatori di Anthropic hanno corretto il bug senza emettere un avviso pubblico, un bollettino di sicurezza separato o un identificativo CVE.

Lo specialista spiega che, in condizioni normali, la sandbox di Claude Code consente solo connessioni in uscita verso host approvati tramite un proxy locale con lista di autorizzazione. Tuttavia, Guan ha scoperto un bug nella gestione dei nomi host SOCKS5 con un byte nullo.

Quindi, se la policy consentisse solo connessioni a *.google.com, un utente malintenzionato potrebbe inviare un nome host come attacker.comx00.google.com. Il filtro rileverebbe la terminazione .google.com e consentirebbe la richiesta, mentre il sistema operativo troncherebbe la stringa al byte zero, stabilendo così la connessione al server dell’attaccante.

Secondo il ricercatore, il problema esisteva dall’ottobre 2025 (data di rilascio pubblico della sandbox) ed è rimasto rilevante per circa cinque mesi e mezzo, fino al rilascio di Claude Code 2.1.90 nella primavera del 2026. Nel frattempo, gli sviluppatori di Anthropic hanno affermato di aver trovato e corretto la vulnerabilità ancor prima che Guan segnalasse il bug: la patch è apparsa nel repository sandbox-runtime il 27 marzo ed è stata inclusa in Claude Code 2.1.88 il 31 marzo.

Tuttavia, il ricercatore ora critica la risposta dell’azienda. Sottolinea che gli utenti di Claude Code non hanno ricevuto alcuna notifica del problema. Inoltre, un’altra vulnerabilità di bypass della sandbox (CVE-2025-66479) è stata segnalata non come un problema di Claude Code, ma come un bug nella libreria sandbox-runtime. Secondo Guan, questo bug trasformava di fatto la modalità “blocca tutto il traffico in uscita” in una modalità “consenti tutto”.

“Un utente senza un ambiente sandbox sa di non avere alcuna protezione. Ma un utente con un ambiente sandbox compromesso crede di essere protetto”, osserva il ricercatore.

La nuova vulnerabilità è diventata particolarmente pericolosa se combinata con le iniezioni di prompt. Guan aveva precedentemente descritto l’ attacco Comment and Control, che interessava Claude Code Security Review, Gemini CLI Action e GitHub Copilot Agent. Si è poi scoperto che gli agenti di intelligenza artificiale in GitHub Actions potevano essere compromessi tramite commenti, descrizioni di problemi e pull request appositamente creati.

Combinando questa tecnica con la possibilità di aggirare la sandbox, un utente malintenzionato potrebbe costringere Claude a eseguire istruzioni dannose e a divulgare tutti i dati disponibili: token GitHub, credenziali cloud, variabili d’ambiente e altre informazioni sull’infrastruttura.

Come fa notare Guan, le aziende si limitano sempre più a rilasciare patch “silenziose” senza emettere bollettini di sicurezza o avvisare gli utenti. Di conseguenza, i ricercatori ricevono ricompense per la segnalazione di bug, gli sviluppatori risolvono il problema, ma i proprietari dei sistemi vulnerabili potrebbero non sapere mai di aver utilizzato sistemi con la sicurezza di fatto disabilitata per mesi.

Il ricercatore scrive che gli agenti di intelligenza artificiale dovrebbero essere trattati più come dipendenti aziendali che come normali software. Prima di concedere a un agente l’accesso all’infrastruttura, i suoi diritti devono essere limitati, il suo ambiente isolato e si deve tenere conto della possibilità che tale strumento esegua istruzioni provenienti dall’esterno.

Luigi Zullo

Ricercatore di sicurezza informatica con esperienza nell’analisi delle vulnerabilità, nella mitigazione del rischio cyber, nelle attività di red teaming ed ethical hacking e nella protezione di sistemi complessi. Specializzato in penetration testing e Threat Intelligence, contribuisce al rafforzamento della resilienza digitale di infrastrutture e reti aziendali.

Aree di competenza: Penetration Testing, Threat Intelligence, Red Teaming, Vulnerability Assessment, Incident Response