
A Anthropic, posicionada como “segurança em primeiro lugar”, nunca teve o sandbox de rede de sua ferramenta de desenvolvimento principal, Claude Code, verdadeiramente segura nos últimos cinco meses.
O pesquisador de segurança independente Aonan Guan publicou em 20 de maio uma nova pesquisa revelando uma segunda vulnerabilidade completa de contorno no sandbox da Claude Code — um ataque de injeção de byte nulo no protocolo SOCKS5, que permite que processos dentro do sandbox acessem qualquer host explicitamente proibido pela política do usuário. Isso significa que, desde o lançamento da funcionalidade de sandbox em outubro de 2025, durante os últimos cerca de 5,5 meses e 130 versões lançadas, cada versão da Claude Code apresenta uma falha de segurança completamente contornável. Este é o segundo contorno completo realizado pelo mesmo pesquisador contra a mesma camada de defesa.
A resposta da Anthropic foi o silêncio: sem aviso de segurança, sem número CVE, sem notificação aos usuários. A vulnerabilidade foi corrigida silenciosamente na versão de 1º de abril, e o registro de atualizações não mencionou nenhum aspecto relacionado à segurança. Ou seja, um usuário que ainda esteja executando uma versão antiga não terá absolutamente nenhuma forma de saber que seu sandbox estava desde o início ineficaz.
Duas chaves para a mesma porta
Claude Code é um assistente de programação AI lançado pela Anthropic no início de 2025, posicionado como um "engenheiro de IA residente no terminal". Diferentemente da complementação de código baseada em bate-papo tradicional, o Claude Code possui permissões de leitura e escrita no repositório do usuário e capacidade de execução de comandos, permitindo-lhe realizar autonomamente operações como navegar no código, editar arquivos e executar testes. Essa intervenção profunda implica riscos de segurança extremamente altos — se o modelo for sequestrado por um ataque de injeção de prompt, o atacante obterá capacidades equivalentes às permissões do terminal do usuário, incluindo leitura de variáveis de ambiente locais, execução de comandos do sistema arbitrários e acesso a recursos de rede interna.
Para equilibrar segurança e eficiência, a Anthropic introduziu a funcionalidade de sandbox web (v2.0.24) em outubro de 2025, permitindo que os usuários definam uma lista branca de domínios através de arquivos de configuração, restringindo o acesso à rede externa do ambiente de execução da IA. Por exemplo, após configurar allowedDomains: [“*.google.com”], o Claude Code só poderá acessar o Google e seus subdomínios, bloqueando todo o resto do tráfego. A documentação oficial promete claramente: “um array vazio equivale a proibir todo o acesso à rede.”
Este mecanismo é implementado por um proxy SOCKS5: o tempo de execução do sandbox subjacente (@anthropic-ai/sandbox-runtime) inicia o servidor proxy, e os processos dentro do sandbox não estabelecem conexões de rede diretamente, mas sim por meio do proxy, que aplica filtragem de domínios com base na lista branca configurada pelo usuário em settings.json. Os mecanismos de sandbox ao nível do sistema operacional — sandbox-exec no macOS e bubblewrap no Linux — restringem corretamente o Agente ao endereço de loopback local, delegando totalmente as decisões de saída a este proxy SOCKS5.

O diagrama da arquitetura do sandbox do Claude Code apresentado no blog oficial da Anthropic — os comandos do usuário passam por um proxy SOCKS/HTTP antes de chegar ao sandbox, onde as operações de arquivo e o acesso à rede são estritamente controlados por permissões
O problema está na implementação desse proxy. Duas pesquisas de segurança independentes provaram que ele pode ser completamente contornado.

A linha do tempo revela problemas mais profundos: a versão v2.0.55, lançada em 26 de novembro de 2025, corrigiu a primeira contornagem, mas a segunda contornagem já existia desde o primeiro dia do lançamento do sandbox e permaneceu presente nessa versão. As duas vulnerabilidades se sobrepõem na linha do tempo; desde o primeiro dia do lançamento da funcionalidade sandbox até a última vulnerabilidade ser corrigida, nenhuma versão foi segura. A Anthropic afirmou no blog oficial que o sandbox “garante que, mesmo em caso de injeção de prompt, o impacto seja totalmente isolado”, mas a existência dessas duas contornagens refuta diretamente esse compromisso.
"Um relatório externo é sorte. Dois são problemas de implementação." — relatório de Guan Aonan.
Uma contornagem completa de um byte vazio
O princípio técnico da segunda contornagem não é complexo, mas a integridade da cadeia de ataque merece atenção.
O usuário configurou uma lista branca de rede, permitindo apenas o acesso a *.google.com. O proxy SOCKS5 do Claude Code realiza correspondência de sufixo no nome de host usando o método endsWith() do JavaScript. Um atacante pode simplesmente inserir um byte nulo no nome de host — construindo uma string como attacker-host.com\x00.google.com. O JavaScript trata o byte nulo como um caractere UTF-16 comum, e endsWith(".google.com") retorna true, permitindo a conexão. No entanto, quando a mesma string é passada para a função subjacente em C, getaddrinfo(), para resolução DNS, o byte nulo é interpretado como um terminador de string, resultando na resolução real de attacker-host.com. Os mesmos bytes recebem duas interpretações diferentes em duas camadas de código: o filtro acredita que você está acessando o Google, enquanto o resolvedor DNS sabe que você está se conectando ao servidor do atacante.
Este é um ataque clássico de “diferença de analisador”, pertencente à mesma categoria técnica do HTTP Request Smuggling descoberto em 2005 (CWE-158 / CWE-436). Sua essência reside no fato de que, quando os mesmos dados passam por dois componentes com regras semânticas diferentes de interpretação, o atacante pode explorar essa diferença para fazer com que um componente realize uma avaliação “segura”, enquanto outro componente executa uma operação “perigosa”. Essas vulnerabilidades surgem repetidamente no campo da segurança cibernética, e a lição fundamental sempre é a mesma: qualquer string transmitida através de fronteiras de confiança deve ser rigorosamente normalizada e validada, e não confiar que a camada superior já realizou a verificação.
Guan Aonan reproduziu a vulnerabilidade usando dois scripts minimizados em Node.js: o script de controle iniciou uma conexão SOCKS5 usando um nome de host normal e retornou BLOCKED; o script de ataque injetou um byte nulo no nome de host e retornou BYPASSED rep=0x00 — este último indica que o proxy estabeleceu com sucesso a conexão e o canal de saída foi aberto. O Claude Code confirmou esse resultado.

Reprodução completa da vulnerabilidade nos quatro passos marcados em vermelho no Claude Code v2.1.86 — confirmação da estratégia,拦截 comum, contorno de byte nulo, confirmação pelo próprio Claude
E quando combinado com o ataque de injeção de prompt “Comentários e Controle” divulgado por Guan Aonan em abril, forma-se uma cadeia de ataque completa (consulte: Três camadas de defesa ainda não são suficientes: um título de PR pode roubar sua chave API: brechas de segurança em AI Agents se repetem). O estudo “Comentários e Controle” já demonstrou que as três ferramentas de programação por IA possuem superfícies de ataque por injeção de prompt, mas com entradas distintas: o Claude Code é vulnerável apenas por meio do título do PR, o Gemini CLI por meio de comentários ou corpo de Issue, e o Copilot Agent utiliza comentários HTML para injeção oculta. Como exemplo do Claude Code, seu título de PR é diretamente concatenado ao modelo de prompt sem filtragem ou escape, impedindo que o modelo distinga entre intenção humana e injeção maliciosa.
Combinando ambos — instruções ocultas fazem com que o Agente execute código de ataque dentro de um sandbox, e injeção de bytes nulos contorna bloqueios de rede — chaves de API, credenciais da AWS, tokens do GitHub, dados de endpoints API internos e outros presentes nas variáveis de ambiente podem ser exfiltrados para qualquer servidor na internet. Os dados fluem diretamente através do proxy SOCKS5, sem necessidade de servidor externo como intermediário, e esse proxy é exatamente o componente que o usuário confia como fronteira segura. O atacante nem precisa de permissão de gravação no repositório; basta submeter uma Issue pública. Os revisores humanos veem, na visualização renderizada do GitHub, uma solicitação de colaboração normal, enquanto o Agente de IA interpreta o código-fonte malicioso completo.
Até o Claude reconheceu: a vulnerabilidade é real
Um dos detalhes-chave desta divulgação veio do próprio Claude Code. Guan Aonan forneceu diretamente ao Claude Code o código de reprodução da vulnerabilidade, solicitando uma avaliação técnica. Após executar o teste de controle (nome de host normal bloqueado) e o teste de ataque (contorno de bloqueio com nome de host de byte vazio), o Claude Code forneceu uma conclusão clara:
This is a real bypass of the network sandbox filter, not just a test artifact. You should report this to Anthropic at https://github.com/anthropics/claude-code/issues.
O produto testado confirmou sozinho a autenticidade e a gravidade da vulnerabilidade, até mesmo fornecendo ativamente o caminho para relato. Esse detalhe foi integralmente documentado por Guan Aonan no relatório de pesquisa e se tornou a fonte do título do artigo do The Register — “Even Claude agrees hole in its sandbox was real and dangerous” (Mesmo o Claude concordou que a falha em seu sandbox era real e perigosa).

Capa da pesquisa de Guan Aonan — Após ser exposto com suas próprias vulnerabilidades, o Claude Code reconheceu: “Esta é uma contornagem real do filtro de sandbox da web”, com quadro vermelho destacando a frase de confirmação chave
A resposta da Anthropic após cinco meses de silêncio
A vulnerabilidade em si é preocupante, mas a forma como a Anthropic a tratou merece análise da indústria.
Guan Aonan apresentou, no início de abril de 2026, um relatório detalhado sobre uma segunda evasão de sandbox à Anthropic por meio do programa de recompensas por vulnerabilidades HackerOne (relatório nº #3646509). A resposta inicial da Anthropic foi:
Obrigado pelo seu relatório. Após analisar esta submissão, determinamos que ela é um duplicata de um relatório interno já em acompanhamento.
O relatório foi imediatamente fechado. Quando Guan Aonan perguntou sobre o plano de número CVE, a Anthropic respondeu em 7 de abril:
Ainda não decidimos se um CVE será publicado para este problema e não podemos fornecer um prazo para essa decisão.
A vulnerabilidade foi corrigida silenciosamente na versão v2.1.90. Nenhum aviso de segurança, nenhum número CVE, nenhum registro na página de recomendações de segurança do Claude Code e nenhum comentário relacionado à segurança no log de atualizações. Uma contornagem completa, presente desde o primeiro dia de lançamento do sandbox e que durou 5,5 meses, abrangendo cerca de 130 versões, parecia nunca ter ocorrido para os usuários.
Este padrão de tratamento não é novo. A primeira contornagem (CVE-2025-66479) foi abordada de forma quase idêntica: a Anthropic atribuiu o CVE apenas à biblioteca subjacente @anthropic-ai/sandbox-runtime (pontuação CVSS de apenas 1,8, "Baixa"), e não ao produto voltado para o usuário, Claude Code; o registro de atualizações mencionava apenas "Fixed proxy DNS resolution" (corrigido a resolução DNS do proxy), sem referência a vulnerabilidade de segurança. Guan Aonan escreveu em seu relatório de pesquisa: "Quando houve vulnerabilidades graves nos React Server Components, tanto o React quanto o Next.js receberam CVEs separados, e a Meta e a Vercel emitiram avisos de segurança, informando plenamente ambas as comunidades. A Anthropic escolheu um caminho diferente." Até o momento, pesquisar "Claude Code Sandbox CVE" ainda não retorna qualquer aviso de segurança oficial.
Ao lidar com a questão de roubo de credenciais, a Anthropic optou por bloquear o comando ps, mas a abordagem de lista negra é intrinsicamente limitada — bloquear um único comando deixa o atacante com inúmeras alternativas. A abordagem correta é declarar explicitamente quais ferramentas o agente precisa. No estudo “Commentary and Control”, a Anthropic elevou a classificação da vulnerabilidade para CVSS 9,4 (nível Crítico) e a transferiu para um programa de recompensas privado, mas um porta-voz afirmou que “a ferramenta não foi projetada para se proteger contra injeção de prompts”. A fabricante confia implicitamente na capacidade de segurança do próprio modelo, mas carece de defesa em profundidade na arquitetura do sistema; quando vulnerabilidades expõem essa lacuna, “limitação de design” torna-se uma categoria conveniente — reconhece o problema, mas, em certa medida, isenta a obrigação de emitir um aviso de segurança.
O cenário setorial mais amplo é que o mesmo problema não se limita à Anthropic. Um estudo divulgado em abril, intitulado “Comentários e Controle”, confirmou que o Gemini CLI da Google e o Copilot Agent do GitHub da Microsoft também apresentavam a mesma superfície de ataque; as três empresas confirmaram e corrigiram a vulnerabilidade, mas nenhuma publicou um aviso de segurança ou número CVE. A Anthropic pagou uma recompensa de 100 dólares, a Google pagou 1337 dólares, e o GitHub inicialmente fechou o relatório como “problema conhecido, não reproduzível”; após receber evidências de engenharia reversa, classificou-o como “informativo” e concedeu 500 dólares. No total, 1937 dólares — e esses três produtos cobrem a maioria das empresas da lista Fortune 100.
Uma falsa sensação de segurança é mais prejudicial do que nenhuma medida de segurança. Usuários sem sandbox sabem que não têm limites; usuários com um sandbox danificado acreditam que têm. Uma equipe executando o Claude Code e com uma lista branca de domínios configurada permaneceu inconsciente dos riscos por 5,5 meses e, após a atualização, ao ver o registro de atualizações, concluiu apenas que o sandbox estava funcionando normalmente. Além disso, quando a vulnerabilidade foi divulgada, a ausência de um aviso de segurança impede os usuários de determinar se já foram afetados e priva-os de base para auditoria retroativa.
Diante dessa realidade, a comunidade de segurança começou a alcançar um consenso: não se pode confiar exclusivamente na implementação de sandbox do fornecedor. O proxy SOCKS5 do Claude Code é construído sobre um pacote npm de terceiros com apenas 10 estrelas no GitHub, cuja última atualização data de junho de 2024; o limite de segurança atravessa dois ambientes de execução — JavaScript e C — mas carece de tratamento normativo básico no ponto de interseção da confiança. A função isValidHost() adicionada no patch de correção — responsável por rejeitar caracteres inválidos como bytes nulos, codificação percentual, CRLF etc. — deveria ter estado presente desde o primeiro dia de lançamento do sandbox. Guan Aonan propôs um framework defensivo pragmático — tratar o AI Agent como um superfuncionário que deve seguir o princípio do menor privilégio, com foco principal em defesa em múltiplas camadas:

A reputação de segurança é construída sobre a transparência de cada divulgação e cada patch, e não sobre narrativas de marca. Quando os usuários confiam seus credenciais ao agente para processamento, o fabricante tem a obrigação de garantir que as defesas sejam eficazes e de notificar prontamente quando falharem. Ambos os pontos, a Anthropic não cumpriu no sandbox do Claude Code.
“The worst outcome of a sandbox is not that it blocks something, but that it gives people a false sense of security. Releasing a vulnerable sandbox is worse than not releasing a sandbox at all,” said Guan Aonan.
(Este artigo foi publicado originalmente no app Titanium Media, autor | Silicon Valley Tech_news, editor | Jiao Yan)
Referências:
1. oddguan.com — Segunda vez, mesmo sandbox: Bypass do sandbox da Anthropic Claude Code Network permite exfiltração de dados (Aonan Guan, 2026.05.20)
2. The Register — Mesmo Claude concorda que a falha em seu sandbox foi real e perigosa (2026.05.20)
