O modo automático do Claude Code executa um binário do atacante durante a análise de bibliotecas de terceiros. Um único payload derruba quatro modelos.

Imagine pedir para um agente revisar uma biblioteca de terceiros. Ele lê o repositório. Ele encontra um binário. Depois, ele roda esse binário no seu host. Foi exatamente isso que o AI Now Institute demonstrou com o Claude Code no modo automático. A prova de conceito recebeu o nome de Friendly Fire. Ela transforma uma revisão de código rotineira em execução remota de código, ou seja, RCE completo na máquina que hospeda o agente.

O detalhe que assusta é a simplicidade. Afinal, o ataque dispensa hooks, skills, plugins e servidores MCP. Ele também dispensa qualquer arquivo de configuração personalizado. Portanto, a superfície de exposição já vive na configuração padrão.

Quais versões e modelos entram na linha de fogo

O ataque atinge a CLI padrão do Claude Code nas versões 2.1.116 a 2.1.199. Além disso, ele funciona com Sonnet 4.6, Sonnet 5 e Opus 4.8 no modo automático. O mesmo vale para a CLI do Codex 0.142.4 com GPT-5.5 em revisão automática. Ou seja, dois fornecedores e quatro gerações de modelo caem com um único payload.

Como o Friendly Fire engana o agente passo a passo

O roteiro é direto. Primeiro, os pesquisadores colocaram uma cópia modificada da biblioteca geopy no disco. Depois, eles deram uma única instrução em linguagem natural: teste a segurança desse caminho. Então o agente começa a explorar o repositório. Em seguida, ele lê uma documentação que apresenta um script auxiliar como útil para checagens de segurança. Logo, ele inspeciona um binário que parece respaldado por um código correspondente. Por fim, ele executa o binário, porque a documentação conversa com a tarefa original de revisão. Com isso, o código do atacante roda no host.

Por que a análise estática continua em silêncio

Aqui mora o ponto cego. Nenhuma função legítima da biblioteca chama o script ou o binário. Portanto, as checagens estáticas tradicionais permanecem quietas. Inclusive, quando os pesquisadores perguntaram aos modelos se havia tentativa de injeção de prompt no fonte, Sonnet 4.6 e GPT-5.5 deixaram o material passar. Ou seja, o próprio modelo que executa também falha ao auditar.

Um único payload derruba quatro modelos diferentes

A técnica viaja entre os modelos testados sem modificação. Às vezes, Sonnet 5 ou Opus 4.8 até percebem que certos arquivos fogem do projeto original. Mesmo assim, eles seguem em frente e executam. Por isso, Roey Eliyahu, CEO da Salt Security, resume a questão de forma dura. Para ele, o problema é estrutural. Ele nasce do próprio jeito como esses agentes operam. Afinal, um texto não confiável chega a um agente que pode rodar comandos. E o agente mistura o código que revisa com as instruções que recebe.

CLAUDE.md e agent.md viram contexto persistente para o atacante

Existe ainda uma variação mais confortável para o invasor. Os pesquisadores colocaram as instruções dentro de arquivos CLAUDE.md ou agent.md. Assim, os agentes tratam esse conteúdo como contexto persistente do projeto. Dessa forma, a manipulação sobrevive entre execuções.

Dois cenários que já cabem no seu fluxo de trabalho Claude Code

Agora pense na sua rotina. No primeiro cenário, um mantenedor de biblioteca embute instruções ocultas que guiam o agente. Exemplos públicos anteriores já mostraram agentes orientados a apagar suítes de teste. No segundo cenário, um comprometimento de cadeia de suprimentos insere o mesmo material em um pacote popular. Depois, atualizações automáticas de dependência e jobs de CI acionam o agente para revisar a nova versão. Nesse fluxo, o próprio agente abre os arquivos envenenados. O desenvolvedor sequer toca neles.

Por que sandbox e aprovação manual falham sozinhos

Muita gente aposta no sandbox como rede de segurança. Contudo, o sandbox perde força depois que o agente já detém RCE. Nesse ponto, o atacante sonda o ambiente, grava configuração, rouba chaves e cria persistência. A aprovação manual também cobra um preço. Afinal, exigir confirmação humana a cada comando derruba justamente a automação que levou os times à ferramenta. Além disso, a fadiga de prompt e o viés de automação enfraquecem esse controle humano. Isso piora sob pressão de tempo.

O que fazer agora sem abrir mão do agente

A recomendação central é clara e incômoda. Primeiro, pare de entregar repositórios não confiáveis a qualquer agente com acesso a shell, chaves ou host. Depois, isole essas ferramentas em máquinas sem segredos de produção. Além disso, evite montagens amplas de filesystem e caminhos de rede para serviços internos. Em seguida, ative monitoramento em tempo de execução na camada de ação. Dessa forma, você enxerga um agente executando um binário que o código legítimo jamais invoca. Por fim, mantenha os controles clássicos: análise estática, pinning de dependência, verificação de checksum e revisão humana.

Acompanhe nosso perfil no Instagram!