Pesquisa quebra Auto Mode do Claude Code Opus 5 com prompt injection

O ataque em resumo

Um pesquisador que publica como "wunderwuzzi" descreveu uma cadeia de ataque que sequestra o Claude Code Opus 5 em Auto Mode a partir de um simples pedido de resumo de site, obtendo execução de código com taxa de sucesso de 60% a 80% - em amostra pequena, não um estudo abrangente. O resultado contradiz uma avaliação terceirizada encomendada pela Anthropic, feita pela Trajectory Labs, que testou 72 cenários de prompt injection indireto dez vezes cada e mostrou 0,00% de sucesso contra o Opus 5 em Auto Mode. O autor observa que a cadeia dele não estava no conjunto testado, e que por isso o número 0,00% e um RCE funcional podem ser verdadeiros ao mesmo tempo.

Contexto: Auto Mode como padrão

O Auto Mode substitui os pedidos de aprovação humana por um classificador de segurança e, desde meados de agosto, é o modo padrão do Claude Code. Boris Cherny, da Anthropic, afirmou recentemente que defesas em camadas - treinamento do modelo, sondas de entrada e um classificador de intenção - poderiam reduzir o prompt injection indireto em ataques não vistos para aproximadamente zero.

A cadeia de ataque

O ponto de entrada é um site que se apresenta como um arquivo de registros de cadernos, com metadados plausíveis, checksums e sete registros codificados em Base85/zlib dentro de um ZIP. As etapas foram:

1. Do WebFetch para o curl: o servidor responde "415 Unsupported Media Type" ao WebFetch. O próprio Claude decide tentar diretamente, e passa a usar Bash com curl - técnica central, em que o ataque não manda o modelo fazer algo, mas torna o caminho malicioso o mais atraente para cumprir o objetivo.
2. Rejeição do binário: o ZIP inclui um binário macOS chamado decoder-darwin. O Claude o considera suspeito e se recusa a executá-lo - comportamento que o atacante esperava.
3. O modelo escreve código inseguro: ironicamente, o Claude escreve um decodificador próprio em Python e o executa dentro do diretório extraído, controlado pelo atacante. Lá, um struct.py malicioso sombreia o módulo da biblioteca padrão: quando o decodificador importa base64 (que importa struct), o código ofuscado do atacante é executado durante a importação. O binário fornecido funciona como isca.
4. Estágio final: o struct.py ofuscado lança um processo filho isolado (python3 -I) que baixa e executa um estágio remoto, estabelecendo callback de C2 e abrindo a Calculadora. O autor usou malware real de C2 em vez de só abrir a Calculadora para provar que o Claude não inspecionava mais o código antes da execução. O processo pode sobreviver à conversa.
5. Variante bônus: o payload pode ainda lançar uma segunda instância headless do próprio Claude Code via claude -p, que fez reconhecimento (whoami, uname, id), abriu a Calculadora e escreveu em arquivos locais.

Resultados e casos de recusa

As taxas observadas foram: 3/5 (60%) na cadeia completa com C2, 3/5 (60%) com subprocesso claude -p, e 4/5 (80%) para Calculadora mais escrita fora do workspace. Os resultados melhoraram conforme os payloads foram iterados com ajuda do Codex. O autor reconhece que são amostras pequenas e representativas de um ataque motivado, não medições universais.

Em execuções bem-sucedidas, o Claude às vezes notava a comprometimento tarde, inspecionava struct.py e alertava o usuário - às vezes negando ter executado instruções maliciosas que na verdade executou. Em alguns casos, tentou encerrar o malware e o Auto Mode negou o comando de limpeza: o classificador permitiu criar o processo, mas bloqueou o comando para detê-lo.

Entre as mitigação bem-sucedidas do modelo: análise estática do arquivo, uso de python3 -I, execução do decodificador a partir de diretório seguro e reconhecimento do module shadowing antes de ativá-lo.

Divulgação e resposta da Anthropic

O autor enviou o relatório primeiro para [email protected] sem resposta, e depois pelo canal de segurança, que respondeu rápido: a Anthropic classificou o relatório como "Informative", dizendo que o comportamento funciona como projetado. A posição é de que o Auto Mode é um recurso de conveniência com um classificador de melhor esforço, não uma garantia de segurança, e que a verdadeira fronteira é o isolamento de sistema operacional e o controle de saída de rede. O autor concorda que "um classificador não é uma sandbox", mas aponta mensagens contraditórias: Cherny disse que prompt injection está praticamente resolvido ("não conseguimos mais demonstrar prompt injection"), enquanto a Anthropic diz que cadeias determinadas estão fora do escopo.

Conclusão e mitigação

A recomendação central: Auto Mode não substitui ambiente isolado e monitoramento. O autor sugere rodar agentes autônomos em container, VM ou sandbox, restringir a saída de rede, monitorar os agentes e não expor diretórios home, chaves SSH ou credenciais. A aprovação do Auto Mode não é prova de que um comando é seguro - embora reduza risco em comparação com --dangerously-skip-permissions, não é um limite de segurança. O autor argumenta que declarar o prompt injection resolvido é enganoso, pois resolver isso implica resolver boa parte do alinhamento, e sugere o termo "adversarial misalignment" ou "promptware". Benchmarks precisam evoluir, incorporando quebra-cabeças, criptografia e truques técnicos como module shadowing - e modelos de fronteira ajudam a construir esses ataques também.