Pesquisadores da BishopFox exploram o sandbox do Claude Code e expõem detalhes do funcionamento interno

A pesquisa da BishopFox começou com uma pergunta simples ao Claude (em conta Enterprise) sobre o próprio sandbox. A resposta foi detalhada: caminhos de arquivos, o runtime gVisor, endereços IP internos, o método de comunicação entre o host orquestrador e o container e ferramentas como o web_fetch. Claude também apontou o caminho /process_api como o processo de ID 1, descrito como um binário Rust, estático, que cuida de ciclo de vida de processos, montagens FUSE, cgroups e comunicação por WebSocket. O pesquisador repetiu os testes em sessões não relacionadas para separar fatos de alucinação, e as respostas foram consistentes.

Dali, o encadeamento: o endpoint de download aceitou o caminho absoluto /process_api e devolveu o binário, que foi submetido a engenharia reversa. O Claude também retornou memória do processo 1. Nos dumps havia fragmentos de JWTs, e um script em Python usou as chaves públicas OAuth do Google para recuperar bytes ausentes. O token de service account do GCP reconstruído foi aceito pela API de token-info do Google. Cerca de uma em cada três requisições de memória trazia material de JWT válido. Depois, o pesquisador contornou o bloqueio --block-local-connections criando uma interface virtual com outro IP de origem (o container tinha CAP_NET_ADMIN e CAP_NET_RAW) e obteve um 101 Switching Protocols no endpoint /mount_root. As tentativas de montar filesystems falharam, e ele não explorou o serviço além disso.

Há ainda dois achados nos controles do Claude Enterprise. Um deles: a interface web impedia editar o nome completo, mas a API de conta aceitava a alteração direta. A Anthropic respondeu que o campo não é usado em auditoria, então classificou como informativo. O segundo foi marcado como duplicado, e a BishopFox omitiu os detalhes porque o problema parece persistir.

A Anthropic não considerou as observações do sandbox como problemas de segurança, já que, no seu modelo de ameaça, as fronteiras de segurança ficam fora do contexto do sandbox não confiável. A BishopFox apresenta o texto como um olhar técnico, não como divulgação de vulnerabilidade, e sugere mudanças de defesa em profundidade: restringir o download a diretórios como /mnt/user-data, remover as capabilities de rede desnecessárias, limpar credenciais da memória e validar permissões de perfil no servidor.

A cobertura anterior do CEVIU sobre o Claude Code tratava de outra superfície. Em 26 de fevereiro de 2026, o CEVIU noticiou "Falhas no Claude Code Permitem Execução Remota de Código e Exfiltração de Chaves API", com vulnerabilidades ligadas a hooks e configurações MCP em repositórios maliciosos (CVE-2025-59536 e CVE-2026-21852, já corrigidas). Em 4 de abril de 2026, veio "Vulnerabilidade no Claude Code permite ignorar regra de segurança", sobre o limite de 50 subcomandos. Agora o foco é o ambiente de execução do Claude, e não o cliente local. Outra diferença: aquelas falhas tinham correção, enquanto aqui a Anthropic disse que o sandbox não violou seu modelo de ameaça.

Para quem opera ou audita ferramentas de IA em empresas, o caso mostra que a premissa de segurança do fornecedor (o sandbox é não confiável e nada sensível deve depender dele) precisa ser entendida e verificada. Na leitura editorial, o risco prático parece depender do que o sandbox consegue alcançar, e a própria pesquisa não conseguiu usar os tokens para montar filesystems. Vale revisar quais dados e credenciais entram nesses ambientes e tratar controles só de interface, como o do nome completo, como insuficientes.