noticias
Claude Code pode executar código malicioso após resumir uma página, mostra pesquisador

Uma demonstração de segurança conseguiu transformar uma tarefa aparentemente banal pedir ao Claude Code que resumisse um site em uma cadeia capaz de executar código no computador do usuário.
O experimento atinge o Claude Opus 5 usando o Auto Mode e expõe um problema importante dos agentes de inteligência artificial: proteger cada decisão individual não significa necessariamente proteger a sequência formada por dezenas delas.
O pesquisador de segurança Johann Rehberger, conhecido por trabalhos envolvendo prompt injection e agentes de IA, obteve sucesso em três variações do ataque testadas em pequena escala. Dependendo da versão utilizada, a cadeia funcionou em 60% a 80% das cinco tentativas realizadas para cada cenário.
O resultado não significa que oito em cada dez usuários do Claude Code estejam vulneráveis. Trata-se de um experimento adversarial cuidadosamente construído para induzir o agente a uma sequência específica de decisões. Ainda assim, o estudo é relevante porque mostra como mecanismos aparentemente seguros podem falhar quando um agente possui acesso ao navegador, terminal, arquivos e rede ao mesmo tempo.
O ataque começa com algo tão simples quanto resumir um site
O cenário criado por Rehberger começa sem comandos suspeitos enviados pelo usuário. A solicitação é apenas para que o Claude Code leia e resuma uma página na internet.
A página, porém, foi preparada especificamente para manipular o comportamento do agente.
Normalmente, o Claude tenta acessar o conteúdo utilizando sua ferramenta destinada à leitura de páginas. O servidor malicioso responde de maneira que essa tentativa falhe. Diante do erro, o próprio agente procura uma alternativa e decide usar ferramentas de linha de comando para buscar o conteúdo diretamente.
Essa diferença é fundamental.
O atacante não precisa dizer explicitamente algo como "execute este comando". Ele cria um ambiente no qual determinada decisão parece ser apenas a próxima etapa lógica para completar a tarefa original.
É justamente aí que ataques contra agentes modernos ficam mais difíceis de detectar.
Uma prompt injection tradicional costuma depender de instruções escondidas em uma página, documento ou mensagem. Sistemas mais recentes conseguem reconhecer muitas dessas tentativas. No experimento de Rehberger, porém, a página maliciosa funciona mais como uma trilha de obstáculos: cada dificuldade empurra o agente em direção à próxima decisão.
Individualmente, várias dessas decisões parecem perfeitamente razoáveis.
O problema aparece quando elas são combinadas.
O Claude rejeita o arquivo suspeito — e mesmo assim entra na armadilha
Depois de acessar o servidor pelo caminho alternativo, o agente recebe um arquivo compactado contendo documentos aparentemente legítimos e um programa destinado a decodificá-los.
O Claude identifica corretamente que executar um binário desconhecido seria arriscado e se recusa a utilizá-lo.
Até aqui, o sistema de segurança parece funcionar exatamente como deveria.
Mas essa recusa fazia parte do ataque.
Para continuar a tarefa, o Claude decide escrever seu próprio pequeno programa de decodificação. Como o código foi produzido pelo próprio modelo, a ação parece muito mais confiável do que simplesmente executar o binário entregue pelo site.
O problema está no diretório onde esse código é executado.
Entre os arquivos fornecidos pelo atacante existe um módulo Python com o mesmo nome de um componente utilizado pela biblioteca padrão da linguagem. Quando o programa criado pelo Claude importa determinadas bibliotecas, o Python encontra primeiro o arquivo presente no diretório local.
Esse comportamento é conhecido como module shadowing.
Não é uma vulnerabilidade nova do Python nem uma técnica criada para inteligência artificial. É uma característica conhecida há décadas: dependendo da configuração e do diretório de execução, um módulo local pode receber prioridade sobre outro de mesmo nome.
A diferença é que, desta vez, quem caiu na armadilha não foi um programador distraído.
Foi o agente.
O código criado pelo próprio Claude terminou carregando indiretamente o arquivo preparado pelo pesquisador.
A segurança do modelo virou parte da cadeia do ataque
Esse é provavelmente o aspecto mais interessante do experimento.
O Claude não ignorou seus mecanismos de segurança para executar um programa suspeito.
Ele fez justamente o contrário.
Primeiro recusou o binário desconhecido. Depois tentou resolver o problema de maneira aparentemente mais segura, escrevendo seu próprio código.
Essa decisão reduziu a percepção de risco, mas não eliminou o ambiente hostil no qual o programa seria executado.
Em outras palavras, o agente avaliou corretamente uma parte do problema e ainda assim perdeu a visão da cadeia completa.
Essa distinção é importante para entender a segurança de sistemas agênticos.
Modelos como Claude Code, Codex e outros agentes de programação não funcionam apenas produzindo texto. Eles observam arquivos, executam comandos, instalam dependências, consultam páginas, modificam projetos e interagem com sistemas externos.
Quanto maior essa autonomia, maior também o chamado blast radius: a quantidade de recursos que pode ser afetada quando algo dá errado.
Do arquivo local para execução remota
No laboratório preparado pelo pesquisador, o módulo malicioso carregado pelo Python conseguia iniciar outro processo e buscar um segundo estágio do teste pela internet.
A demonstração utilizava comportamentos visíveis e controlados para provar que código arbitrário havia sido executado.
Em uma das variações, a cadeia também conseguiu estabelecer comunicação com um servidor de comando e controle usado pelo próprio pesquisador.
Isso transforma o problema em algo mais sério do que uma simples prompt injection que faz o modelo produzir uma resposta errada.
O agente efetivamente passa a ser um intermediário para execução de código no sistema onde está trabalhando.
Rehberger também criou uma variante particularmente interessante: em vez de simplesmente iniciar outro programa, o código comprometido abria uma segunda instância do próprio Claude Code em modo não interativo.
Nesse cenário, um agente comprometido cria outro agente.
Essa segunda instância passa a ter contexto e ferramentas próprias e, durante os testes, executou ações de reconhecimento do sistema e escreveu arquivos fora da área inicial de trabalho.
A ideia parece saída de um exercício acadêmico sobre agentes autônomos, mas evidencia um problema muito concreto: processos filhos e subagentes podem ampliar drasticamente a superfície de ataque.
O Auto Mode é justamente o que torna o caso importante
O experimento foi realizado com o Claude Opus 5 utilizando o Auto Mode.
A Anthropic criou esse modo para diminuir a quantidade de autorizações manuais exigidas pelo Claude Code. A justificativa é compreensível: quando desenvolvedores precisam aprovar dezenas ou centenas de comandos, começam a clicar automaticamente em "permitir".
A própria empresa encontrou esse comportamento em seus dados.
Em agosto, a Anthropic informou que usuários aprovavam aproximadamente 97% dos pedidos individuais de permissão. Em um estudo controlado com 1.053 participantes, humanos identificaram apenas 13,6% dos comandos perigosos apresentados durante as sessões, enquanto o Auto Mode bloqueou 89%.
Por isso, desde 14 de agosto de 2026, novas sessões dos planos Pro, Max e Team passaram a iniciar no Auto Mode quando o usuário não definiu outra preferência.
O mecanismo utiliza classificadores para avaliar chamadas de ferramentas e verificar se determinada ação corresponde à intenção original do usuário.
Também existe uma camada destinada a identificar possíveis prompt injections no conteúdo obtido de páginas, arquivos e ferramentas externas.
A arquitetura é significativamente mais sofisticada do que simplesmente perguntar ao usuário se determinada operação pode ser executada.
Mas continua sendo probabilística.
E esse detalhe muda tudo.
Um benchmark perfeito não significa segurança perfeita
A Anthropic divulgou recentemente resultados bastante fortes para o Auto Mode.
Em uma avaliação independente realizada pela Trajectory Labs, foram utilizadas 72 situações de prompt injection indireta, cada uma executada dez vezes. Segundo os dados divulgados pela empresa, nenhum dos 720 ataques teve sucesso contra Claude Fable 5, Opus 5 ou Sonnet 5 usando Auto Mode.
É um resultado expressivo.
Mas não significa que a taxa real de ataques possíveis seja zero.
O experimento de Rehberger mostra exatamente a diferença entre uma avaliação controlada e um adversário construindo uma cadeia especificamente contra a arquitetura disponível.
Os três testes publicados pelo pesquisador tiveram resultados de 3 sucessos em 5 tentativas, 3 em 5 e 4 em 5.
A amostra é pequena demais para concluir que existe uma taxa de comprometimento de 60% ou 80% em situações reais.
O próprio pesquisador faz essa ressalva.
O valor do trabalho está em outro ponto: demonstrar a existência de uma cadeia que não estava representada no conjunto de testes utilizado anteriormente.
Um benchmark pode obter 0% de ataques bem-sucedidos e ainda assim existir um ataque fora daquele benchmark.
As duas afirmações não são contraditórias.
Anthropic considera Auto Mode uma camada de conveniência, não uma sandbox
Segundo o relato de Rehberger, o caso foi comunicado à Anthropic e encerrado como informativo, com a posição de que o comportamento estaria dentro do funcionamento esperado do sistema.
O pesquisador afirma que a interpretação da empresa é que o Auto Mode utiliza classificadores de melhor esforço e não deve ser considerado uma garantia de segurança.
Essa distinção também aparece, em essência, na documentação pública da própria Anthropic.
A empresa reconhece que sistemas de classificação não eliminam completamente o risco e continua recomendando supervisão em operações de alta criticidade.
Mais importante ainda, a Anthropic há meses defende sandboxing como uma camada adicional de proteção para agentes de programação.
Uma sandbox tenta resolver o problema de maneira diferente.
Em vez de perguntar se o agente deveria executar determinado comando, ela limita fisicamente o que esse comando consegue alcançar.
Arquivos podem ficar inacessíveis.
Credenciais podem permanecer fora do ambiente.
A conexão com a internet pode ser bloqueada ou restrita a determinados destinos.
Mesmo que a inteligência artificial seja completamente enganada, o dano potencial continua limitado pela infraestrutura.
Essa é uma diferença importante entre segurança baseada em intenção e segurança baseada em capacidade.
O problema não é apenas do Claude
Seria confortável interpretar o episódio como simplesmente mais uma vulnerabilidade de um produto específico.
O problema é mais amplo.
Agentes de IA estão deixando de ser ferramentas que sugerem comandos para se tornar sistemas que executam fluxos inteiros de trabalho.
Eles recebem um objetivo e começam a decidir como alcançá-lo.
Esse modelo melhora drasticamente a produtividade, mas transfere parte da tomada de decisão do usuário para uma inteligência artificial que interpreta continuamente ambientes potencialmente hostis.
Arquivos podem conter instruções maliciosas.
Sites podem manipular agentes.
Pacotes podem ter dependências comprometidas.
Repositórios podem carregar conteúdo preparado especificamente para influenciar modelos.
Um desenvolvedor humano normalmente reconhece essas superfícies como zonas distintas de confiança. Para um agente, tudo pode chegar ao mesmo contexto como informações necessárias para resolver uma tarefa.
A indústria está tentando resolver esse problema com classificadores, políticas, filtros de entrada, modelos supervisores e treinamento adversarial.
Todas essas camadas são importantes.
Nenhuma substitui completamente isolamento técnico.
Análise da equipe
O experimento de Johann Rehberger não demonstra que o Claude Code esteja inevitavelmente inseguro nem invalida os avanços feitos pela Anthropic no Auto Mode.
Ele demonstra algo mais incômodo.
Estamos tentando usar inteligência probabilística como componente de uma fronteira de segurança que, historicamente, funciona melhor quando construída sobre regras determinísticas.
Um classificador pode concluir que determinada chamada de ferramenta parece segura.
Uma sandbox pode simplesmente impedir que aquela ferramenta alcance determinado arquivo.
São filosofias diferentes.
A primeira tenta entender intenção.
A segunda limita capacidade.
O futuro provavelmente dependerá das duas.
Também existe um problema de comunicação que empresas de IA precisarão administrar com cuidado. Resultados como "0% de ataques bem-sucedidos" são tecnicamente legítimos quando descrevem um benchmark específico, mas facilmente passam a impressão de que determinada classe de vulnerabilidade foi resolvida.
Em segurança, isso raramente acontece.
O adversário não precisa derrotar todos os mecanismos de proteção.
Ele precisa encontrar uma sequência que ninguém testou.
Para desenvolvedores, a regra começa a mudar
Há alguns anos, a principal recomendação de segurança ao usar ferramentas de IA era simples: não copie código sem entender o que ele faz.
Agentes autônomos tornam essa regra insuficiente.
O código pode ser escrito pelo próprio modelo.
O risco pode estar no diretório de execução.
Na dependência carregada.
No arquivo que aparentemente contém apenas dados.
Na página consultada durante uma investigação.
Ou em uma ferramenta chamada automaticamente dezenas de decisões depois do comando original.
O caso do Claude Code mostra que a pergunta já não deve ser apenas "posso confiar na resposta da IA?".
A pergunta mais importante passa a ser:
**o que essa IA consegue alcançar se estiver completamente enganada?**
Essa provavelmente será uma das questões centrais da próxima geração de desenvolvimento assistido por inteligência artificial.
Agentes vão ganhar memória maior, acesso a mais ferramentas e capacidade para trabalhar durante horas sem supervisão.
A produtividade será enorme.
A superfície de ataque também.
O teste de Rehberger não encerra a discussão sobre a segurança do Auto Mode.
Ele faz exatamente o contrário: mostra por que essa discussão está apenas começando.
👉 Dúvida? Então veja mais em: https://pixbugtech.com/linksuteis