Um pedido tão simples quanto “resuma este site” pode ser suficiente para iniciar uma cadeia capaz de terminar na execução de código malicioso em um computador usando o Claude Code.
A técnica foi demonstrada pelo pesquisador de segurança Johann Rehberger, conhecido como wunderwuzzi, que colocou à prova o Claude Code executando o modelo Opus 5 em Auto Mode. O ataque combina prompt injection indireto, decisões autônomas tomadas pelo agente e uma técnica conhecida como Python module shadowing.
O resultado chama atenção porque o usuário não precisa baixar conscientemente um programa suspeito nem pedir para a inteligência artificial executar um arquivo. A interação inicial pode ser simplesmente solicitar que o agente analise uma página controlada pelo atacante.
Nos experimentos de Rehberger, três variações foram testadas cinco vezes cada e apresentaram taxas de sucesso entre 60% e 80%. O próprio pesquisador ressalta que a amostra é pequena e não deve ser interpretada como uma medição abrangente da segurança do produto.
O episódio expõe um dos problemas mais importantes da nova geração de agentes de IA: quando um modelo deixa de apenas responder perguntas e ganha permissão para acessar a internet, executar comandos e manipular arquivos, uma falha de interpretação pode produzir consequências diretamente no sistema operacional.
Tudo começa com um pedido aparentemente inofensivo
O cenário criado pelo pesquisador é propositalmente simples.
O usuário pede ao Claude Code para resumir um site. A página maliciosa se apresenta como um arquivo contendo registros de notebooks.
Normalmente, o agente tenta acessar a página utilizando sua ferramenta própria de busca de conteúdo, chamada WebFetch.
O servidor controlado pelo pesquisador, entretanto, responde com um erro HTTP 415 — Unsupported Media Type.
Nesse momento acontece a primeira decisão importante.
Em vez de simplesmente desistir, o Claude tenta encontrar outra maneira de completar a tarefa.
O agente decide utilizar uma chamada Bash com curl para acessar diretamente o endereço.
Para um assistente de programação, essa é uma decisão perfeitamente compreensível.
Se uma ferramenta não consegue acessar determinado recurso, tentar outra é justamente o comportamento esperado de um agente autônomo.
E é exatamente essa autonomia que o ataque explora.
Site direciona Claude para um arquivo ZIP
Quando o curl acessa o servidor, o site responde com um redirecionamento HTTP 303.
O destino é um arquivo ZIP preparado pelo invasor.
O Claude Code então baixa esse pacote para conseguir analisar o conteúdo e continuar realizando a tarefa solicitada pelo usuário.
Dentro do arquivo existem elementos aparentemente legítimos: metadados, um README, registros JSON codificados com Base85/zlib e um programa destinado à decodificação das informações.
Mas existe também um arquivo cuidadosamente preparado:
struct.py
É esse arquivo que se torna uma das peças centrais do ataque.
Claude percebe um risco e se recusa a executar o programa
Nesse ponto, as proteções do Claude Code funcionam.
O arquivo ZIP contém um binário chamado decoder-darwin, destinado aparentemente a decodificar os registros existentes no pacote.
Executar um programa desconhecido baixado da internet representa um risco evidente.
O Claude reconhece isso e se recusa a executar diretamente o binário.
À primeira vista, o ataque deveria terminar ali.
Mas acontece exatamente o contrário.
A decisão tomada pelo modelo para permanecer seguro cria o caminho utilizado pelo pesquisador para alcançar a execução do código.
IA decide escrever seu próprio decoder
Como precisa continuar realizando a tarefa, o Claude encontra outra solução.
Em vez de utilizar o programa fornecido pelo site, decide criar seu próprio código Python para decodificar os arquivos.
Essa atitude parece ainda mais segura.
O modelo não confia no executável desconhecido e prefere escrever uma pequena ferramenta utilizando bibliotecas conhecidas do Python.
O problema é o local onde esse programa será executado.
Os arquivos extraídos do ZIP continuam presentes no mesmo diretório.
Entre eles está justamente o struct.py preparado pelo invasor.
A partir daí entra em cena uma característica do funcionamento do Python.
Ataque explora Python module shadowing
Python procura módulos em determinados locais quando um programa executa um comando de importação.
Dependendo do ambiente e do diretório atual, um arquivo local pode ser carregado antes do módulo legítimo esperado pelo desenvolvedor.
Essa situação pode permitir uma técnica conhecida como module shadowing.
Imagine que um programa espera carregar um módulo legítimo chamado exemplo.
Se existir no diretório atual outro arquivo chamado exemplo.py, o interpretador pode acabar utilizando aquele arquivo local.
No ataque demonstrado contra o Claude Code, o arquivo malicioso possui o nome:
struct.py
O decoder criado pelo Claude utiliza o módulo base64.
E o base64, por sua vez, depende do módulo struct.
O problema é que o Python encontra o struct.py malicioso existente no diretório controlado pelo atacante.
A sequência fica aproximadamente assim:
Usuário pede resumo → Claude acessa página → WebFetch falha → Claude usa curl → ZIP é baixado → Claude recusa binário → escreve decoder próprio → Python importa dependência → arquivo malicioso é carregado → código do atacante é executado.
Nenhuma dessas etapas isoladamente parece necessariamente absurda.
É a combinação delas que produz o comprometimento.
Decisão de segurança virou parte do ataque
Esse é provavelmente o aspecto mais interessante da demonstração.
O Claude fez algo correto ao se recusar a executar um binário desconhecido.
O problema apareceu na alternativa escolhida.
Escrever um decoder próprio parecia mais seguro, mas o ambiente no qual aquele código seria executado já estava parcialmente controlado pelo atacante.
Rehberger descreveu justamente essa ironia: a recusa em executar o binário fazia parte do caminho esperado pelo ataque.
Isso demonstra uma limitação importante dos mecanismos de segurança baseados apenas na avaliação individual de ações.
Um classificador pode analisar:
“Executar este binário é perigoso?”
E bloquear corretamente.
Depois pode analisar:
“Escrever um script Python para decodificar arquivos é perigoso?”
Isoladamente, provavelmente não.
Depois:
“Executar meu próprio script Python é perigoso?”
Novamente, pode parecer uma operação comum.
O problema aparece quando essas ações são analisadas como uma sequência.
Código conseguiu baixar outro payload
Segundo Rehberger, o struct.py utilizado na demonstração continha código preparado para contornar os controles do sistema.
Depois de ser carregado pelo Python, ele iniciava outro processo responsável por baixar e executar um payload remoto.
Na prova de conceito, o pesquisador não realizou uma ação destrutiva.
O código estabeleceu comunicação de comando e controle e abriu a calculadora do sistema.
Abrir a calculadora é uma técnica clássica utilizada por pesquisadores para demonstrar execução arbitrária de código sem causar danos.
O importante não é a calculadora.
O importante é demonstrar que o atacante conseguiu sair do conteúdo da página web e alcançar o sistema operacional da máquina onde o agente estava funcionando.
Em um ataque real, o payload poderia tentar realizar outras ações dentro das permissões disponíveis ao processo comprometido.
Ataque chegou a criar outro Claude
Rehberger também demonstrou uma variação particularmente interessante.
Em vez de simplesmente iniciar um processo tradicional, o código malicioso poderia executar:
claude -p
Isso inicia uma nova instância do Claude Code em modo headless.
Nesse cenário, o resultado da prompt injection é ainda mais incomum.
Um agente de IA comprometido cria outro agente.
Essa segunda instância recebe seu próprio contexto e acesso às ferramentas disponíveis naquele ambiente.
Durante os experimentos, o Claude secundário realizou comandos básicos de reconhecimento do sistema, incluindo operações equivalentes a descobrir o usuário atual, informações do sistema e identificadores da conta. Também escreveu arquivos no diretório pessoal e abriu a calculadora.
Essa demonstração aponta para um cenário de segurança que praticamente não existia antes da popularização dos agentes autônomos.
Um código malicioso pode não apenas iniciar processos tradicionais, mas potencialmente recrutar outro agente inteligente capaz de interpretar o ambiente e utilizar ferramentas por conta própria.
Auto Mode aumenta autonomia do Claude Code
A demonstração foi realizada com o Claude Code utilizando o Auto Mode, que passou a ser o modo padrão em meados de agosto, segundo as fontes consultadas.
A ideia do recurso é reduzir uma das principais limitações dos agentes de programação: pedidos constantes de autorização.
Quando um agente precisa confirmar cada comando, sua autonomia diminui significativamente.
O Auto Mode tenta resolver isso utilizando mecanismos de segurança para avaliar quais operações podem prosseguir automaticamente.
Para tarefas legítimas, isso torna a experiência muito mais fluida.
O Claude pode investigar arquivos, utilizar ferramentas e executar determinados comandos sem interromper o usuário a cada etapa.
Mas autonomia e segurança possuem uma relação delicada.
Quanto mais decisões o agente consegue tomar sozinho, maior é o impacto potencial quando uma dessas decisões é manipulada.
Prompt injection continua sendo grande desafio para agentes
A técnica utilizada na demonstração pertence à categoria de prompt injection indireto.
Em uma prompt injection tradicional, alguém envia instruções maliciosas diretamente ao modelo.
Na versão indireta, as instruções estão escondidas dentro de algum conteúdo que o agente precisa processar.
Pode ser uma página web.
Um documento.
Um arquivo de código.
Um README.
Uma mensagem.
Ou praticamente qualquer outra fonte de informação acessível ao modelo.
O usuário pode nem saber que existe uma instrução maliciosa naquele conteúdo.
Ele simplesmente pede:
“Resuma esta página.”
O agente lê o material e pode interpretar partes dele como instruções relevantes para realizar a tarefa.
Esse problema fica muito mais sério quando a IA possui ferramentas.
Um chatbot comum comprometido por prompt injection pode produzir uma resposta incorreta.
Um agente com acesso ao terminal pode executar ações.
O problema não é apenas o modelo
Uma das principais conclusões da pesquisa é que segurança de agentes não pode depender exclusivamente da capacidade do modelo de reconhecer conteúdo malicioso.
Mesmo modelos avançados podem ser induzidos a tomar decisões inesperadas.
Por isso, sistemas agentivos precisam utilizar barreiras externas.
O próprio Rehberger argumenta que classificadores de segurança devem ser entendidos como mecanismos de melhor esforço, e não como uma fronteira absoluta de segurança.
Isso muda a arquitetura recomendada.
A pergunta deixa de ser apenas:
“Como impedir que o modelo seja enganado?”
E passa também a ser:
“Se o modelo for enganado, até onde ele consegue chegar?”
Essa segunda pergunta é fundamental.
Sandbox pode limitar consequências
Uma das principais recomendações é executar agentes de programação dentro de ambientes isolados.
Um sandbox restringe aquilo que determinado processo consegue acessar.
Em vez de permitir que o Claude Code tenha acesso irrestrito à máquina do desenvolvedor, a organização pode executá-lo dentro de um container, máquina virtual ou outro ambiente controlado.
Assim, mesmo que uma prompt injection consiga provocar execução de código, o impacto potencial fica limitado.
O invasor poderia comprometer o ambiente isolado, mas encontraria barreiras adicionais para alcançar arquivos pessoais, credenciais ou sistemas internos.
Essa estratégia segue um princípio antigo da cibersegurança:
assuma que uma camada eventualmente poderá falhar.
A defesa precisa continuar funcionando mesmo depois disso.
Acesso à internet também precisa ser controlado
Outro ponto crítico é o chamado network egress — o tráfego que sai do ambiente.
Na demonstração, a execução do código malicioso consegue buscar um payload remoto.
Se o agente estiver em um ambiente no qual qualquer processo pode se conectar livremente a qualquer servidor na internet, essa etapa fica muito mais fácil.
Empresas podem restringir conexões externas permitidas para ambientes onde agentes de IA são executados.
Isso dificulta ações como:
- baixar payloads adicionais;
- enviar informações roubadas;
- estabelecer canais de comando e controle;
- conectar-se a infraestrutura desconhecida.
O controle de saída de rede é particularmente importante porque agentes de programação frequentemente trabalham em ambientes que também possuem credenciais valiosas.
Credenciais de desenvolvedores tornam o risco maior
Uma estação de desenvolvimento pode conter acesso a alguns dos ativos mais importantes de uma empresa.
GitHub.
AWS.
Azure.
Google Cloud.
Registries de pacotes.
Bancos de dados.
Ambientes de CI/CD.
Tokens de API.
Chaves SSH.
Segredos de produção.
Se um agente comprometido herda acesso a essas credenciais, uma prompt injection pode potencialmente deixar de ser um problema local e se transformar em um incidente corporativo.
É por isso que isolamento de credenciais precisa acompanhar a adoção de agentes de programação.
O agente deveria receber apenas os acessos necessários para aquela tarefa.
Esse conceito segue o princípio de menor privilégio, um dos fundamentos históricos da segurança.
Claude Code já esteve no centro de outras pesquisas
A segurança do Claude Code vem recebendo atenção crescente justamente por sua capacidade de interagir profundamente com ambientes de desenvolvimento.
No início de 2026, pesquisadores da Check Point divulgaram vulnerabilidades relacionadas a arquivos de configuração de projetos que poderiam permitir execução de código e exposição de tokens de API em determinadas condições. Essas falhas receberam identificadores como CVE-2025-59536 e CVE-2026-21852 e foram posteriormente tratadas com correções e mitigações.
O novo trabalho de Rehberger é diferente.
Ele não depende necessariamente do mesmo tipo de vulnerabilidade tradicional.
A demonstração explora o comportamento emergente de um agente realizando uma sequência de ações legítimas.
Isso torna o problema particularmente difícil.
Nem toda falha de agente se encaixa no modelo tradicional de vulnerabilidade
Durante décadas, cibersegurança trabalhou principalmente com vulnerabilidades relativamente determinísticas.
Existe um erro em um programa.
O atacante envia determinada entrada.
O erro permite uma ação não autorizada.
O fornecedor corrige o código.
Com agentes de IA, aparece outra categoria.
O software pode estar funcionando exatamente como foi projetado, mas o modelo toma uma sequência de decisões que produz um resultado inseguro.
Não existe necessariamente uma única linha de código que possa ser corrigida.
O problema emerge da combinação entre:
modelo + ferramentas + permissões + conteúdo externo + contexto + decisões autônomas.
Essa característica deve exigir novas formas de testar segurança.
Taxa de 80% precisa ser interpretada com cautela
Os números da pesquisa são impressionantes, mas precisam ser contextualizados.
Rehberger testou três variantes cinco vezes cada.
Dependendo da variação, o ataque funcionou entre 60% e 80% das tentativas.
Isso significa que o estudo não demonstra que “80% dos usuários do Claude Code podem ser hackeados”.
Também não significa que qualquer página web consegue executar código.
O experimento foi cuidadosamente preparado por um pesquisador especializado em prompt injection para explorar uma sequência específica de comportamentos.
Ainda assim, o resultado é importante justamente porque demonstra viabilidade.
Uma cadeia aparentemente improvável conseguiu funcionar repetidamente em um ambiente de testes.
Anthropic teria classificado comportamento como esperado
Segundo o relato de Rehberger reproduzido pelo The Register, a Anthropic indicou que o comportamento estava funcionando conforme projetado e destacou que o Auto Mode utiliza um classificador de melhor esforço, não uma garantia absoluta de segurança. A empresa não respondeu ao pedido de comentário feito pela publicação antes da reportagem.
Essa distinção é fundamental.
Uma aprovação do Auto Mode significa essencialmente que determinada operação não foi classificada como perigosa o suficiente para exigir intervenção.
Não significa que o código executado tenha sido formalmente verificado como seguro.
As duas ideias parecem semelhantes, mas são muito diferentes.
É justamente nesse espaço que ataques compostos por várias ações aparentemente benignas podem surgir.
Segurança precisa analisar cadeias, não apenas comandos
Imagine um sistema que analise individualmente estas ações:
“Baixar um arquivo.”
Pode ser legítimo.
“Descompactar um ZIP.”
Também.
“Criar um script Python.”
Normal.
“Executar um script criado pelo próprio agente.”
Pode ser esperado para um assistente de programação.
“Fazer uma conexão externa.”
Também pode ser necessária.
O problema aparece quando todas essas etapas fazem parte de uma única cadeia controlada indiretamente por um invasor.
Esse é um dos grandes desafios para a próxima geração de ferramentas de segurança para IA.
Não basta avaliar ações.
É necessário compreender intenção, proveniência dos dados e relacionamento entre diferentes etapas.
Conteúdo externo precisa ser tratado como não confiável
Uma possível evolução arquitetural será marcar explicitamente a origem das informações processadas pelos agentes.
Se determinada instrução veio de uma página web não confiável, o sistema deveria tratá-la de maneira diferente de uma ordem enviada diretamente pelo usuário.
O mesmo vale para conteúdo proveniente de:
- repositórios desconhecidos;
- issues do GitHub;
- e-mails;
- documentos;
- arquivos baixados;
- comentários em código;
- páginas da internet.
A dificuldade está no fato de que agentes precisam justamente interpretar essas informações para serem úteis.
Bloquear completamente conteúdo externo destruiria grande parte de sua funcionalidade.
O desafio será permitir que a IA leia informações não confiáveis sem automaticamente conceder a essas informações autoridade sobre suas ações.
Agentes de IA ampliam a superfície de ataque
A pesquisa também demonstra uma mudança maior na segurança de computadores.
Durante décadas, atacantes procuravam principalmente vulnerabilidades em softwares.
Agora existe uma nova superfície:
o raciocínio operacional do agente.
Um invasor pode tentar prever como o modelo reagirá a determinado cenário.
Se o WebFetch falhar, ele tentará curl?
Se encontrar um executável desconhecido, escreverá sua própria ferramenta?
Se um formato estiver codificado, tentará decodificá-lo?
Se receber um erro, procurará automaticamente outra solução?
Esses comportamentos são exatamente o que torna agentes úteis.
Mas também podem ser manipulados.
O atacante não precisa necessariamente ordenar diretamente:
“Execute este malware.”
Pode construir um ambiente em que a sequência mais natural de decisões do modelo termine justamente nesse resultado.
O grande desafio é a autonomia segura
Esse episódio resume uma das questões centrais da inteligência artificial agentiva.
Para serem realmente úteis, agentes precisam possuir autonomia.
Precisam conseguir investigar problemas, utilizar ferramentas, corrigir erros e encontrar caminhos alternativos quando alguma tentativa falha.
Um agente que pergunta ao usuário o que fazer a cada cinco segundos possui pouco valor.
Por outro lado, cada permissão adicional aumenta o impacto potencial de uma decisão errada.
O futuro desses sistemas dependerá, portanto, de encontrar um equilíbrio entre autonomia e contenção.
A solução provavelmente não virá de uma única tecnologia.
Será uma combinação de modelos melhores, classificadores, sandboxes, isolamento de credenciais, restrições de rede, monitoramento e políticas de acesso.
O novo princípio pode ser: não confie no agente
Durante anos, a indústria adotou conceitos como Zero Trust, partindo da ideia de que nenhum usuário ou dispositivo deveria receber confiança automática.
Agentes de inteligência artificial podem exigir uma adaptação desse princípio.
Mesmo quando o modelo pertence a uma empresa confiável e está realizando uma tarefa legítima, suas ações precisam permanecer limitadas por controles externos.
O agente pode ser enganado.
O conteúdo que ele lê pode ser malicioso.
Uma ferramenta utilizada pelo modelo pode produzir um resultado inesperado.
E uma sequência de decisões individualmente razoáveis pode terminar em comprometimento.
A demonstração contra o Claude Code mostra exatamente esse cenário.
O usuário pede apenas um resumo.
A IA tenta ajudar.
Quando uma ferramenta falha, encontra outra.
Quando um executável parece perigoso, evita executá-lo.
Quando precisa processar dados, escreve seu próprio código.
Cada decisão parece racional.
Mas o ambiente foi construído para transformar justamente essas decisões em uma cadeia de ataque.
É isso que torna o experimento relevante para além do Claude Code.
A segurança da próxima geração de agentes não poderá depender apenas de ensinar a IA a reconhecer o perigo. Será necessário construir sistemas nos quais, mesmo quando a IA for enganada, ela simplesmente não tenha poder suficiente para transformar esse erro em uma invasão completa.
