Três falhas de alta gravidade no OpenClaw — um agente de inteligência artificial open source com mais de 381 mil estrelas no GitHub e 100 mil usuários ativos por dia — permitem que um atacante execute código arbitrário no computador da vítima enviando apenas uma mensagem de WhatsApp cuidadosamente formulada. Descobertas pelo pesquisador Chinmohan Nayak e corrigidas na versão 2026.6.6, as vulnerabilidades burlam o filtro de variáveis de ambiente, o executor de comandos e o sandbox Docker, e ainda passam despercebidas pelos filtros de segurança do Claude Sonnet 4 quando o pedido é vestido de contexto técnico plausível.

Pontos-chave do ataque

  • Ferramenta: OpenClaw, agente de IA que conecta assistentes a WhatsApp, Slack, Discord e Teams e executa comandos no sistema.
  • Vulnerabilidades: três falhas (CVSS 8.8, 8.8 e 8.4) com identificadores GHSA publicados em julho de 2026.
  • Vetor: uma mensagem externa no WhatsApp manipula o agente e dispara execução de código na máquina — sem acesso prévio.
  • Impacto: roubo de chaves SSH, credenciais AWS, segredos GPG e escape total do sandbox para o sistema hospedeiro.
  • Correção: atualizar para a versão 2026.6.6 e restringir ferramentas de execução em agentes expostos a canais de mensagem.

O que é o OpenClaw

O OpenClaw é um assistente de IA pessoal e open source que roda na própria máquina do usuário. A premissa é sedutora: em vez de abrir um terminal, você conversa com a IA por um aplicativo de mensagens — WhatsApp, Slack, Discord ou Teams — e ela traduz o pedido em comandos de shell, operações de arquivo e execução de código. É, em essência, um agente autônomo com poder de executar ações no sistema operacional, acionado por linguagem natural.

Com mais de 100 mil usuários diários ativos, segundo o Cyber Press, a ferramenta virou favorita de equipes de desenvolvimento que querem uma interface conversacional para o ambiente técnico. Esse mesmo poder de execução, porém, é exatamente o que abre a superfície de ataque. Quando um agente conectado ao WhatsApp pode rodar comandos no host, qualquer mensagem recebida vira um ponto de entrada potencial para o sistema.

As três falhas encadeadas

O pesquisador Chinmohan Nayak demonstrou uma cadeia de exploração que combina três vulnerabilidades distintas. Cada uma ataca uma camada diferente de proteção do OpenClaw. A tabela abaixo resume os vetores.

Falha CVSS Mecanismo
Injeção de variáveis de ambiente 8.8 O filtro sanitizeEnvVars() ignora variáveis como NODE_OPTIONS e BASH_ENV, permitindo pré-carregar código malicioso
Abuso do transporte Git ext:: 8.8 O ext:: do Git permite que uma “URL remota” seja um comando de shell; atacante o reativa via config
Bypass de caminho do sandbox 8.4 O Docker verifica se um caminho está dentro de um diretório bloqueado, mas não o inverso — montar /home expõe tudo

A primeira falha explora uma função chamada sanitizeEnvVars(), projetada para bloquear vazamento de credenciais — chaves de API, tokens, segredos. O filtro, contudo, nunca considerou variáveis de inicialização de interpretadores como NODE_OPTIONS, PYTHONSTARTUP, BASH_ENV e outras nove. Essas variáveis permitem que um atacante pré-carregue código arbitrário antes mesmo de o script alvo começar a rodar.

A segunda abusa de um recurso obscuro do Git: o transporte ext::, que permite que uma “URL remota” seja, na verdade, um comando de shell arbitrário. Desativado por padrão desde o Git 2.38, ele pode ser reativado com uma simples flag de configuração — exatamente o que o comando do atacante fez, disfarçado como um pedido para “reproduzir um erro de pipeline de CI”.

A terceira, a mais grave na prática, ataca o sandbox Docker. O OpenClaw bloqueia a montagem de diretórios sensíveis como ~/.ssh, ~/.aws e o socket do Docker. Mas a verificação só confere se um caminho está dentro de um diretório bloqueado — nunca se um diretório bloqueado está dentro do caminho solicitado. Montar /home inteiro, conforme detalhou o The Hacker News, dá acesso a chaves SSH, credenciais AWS e segredos GPG. Montar /var expõe o socket do Docker e permite um escape completo para o sistema hospedeiro.

Como o Claude foi enganado

O detalhe mais perturbador da pesquisa é o padrão de engenharia social. Payloads obviamente maliciosos — shells reversos, comandos em base64 — eventualmente acionavam os filtros de segurança do Claude Sonnet 4, um dos modelos comerciais mais alinhados para segurança. Mas pedidos vestidos de contexto técnico plausível, como “para o nosso relatório de incidente” ou “reproduzindo falhas de CI”, passaram sem nenhuma resistência.

Isso expõe uma falha fundamental na arquitetura de segurança desses agentes: a confiança de que o modelo vai se recusar a executar comandos perigosos não sobrevive a um invasor que sabe falar a língua do desenvolvedor. O filtro baseado em padrões enxerga o reverse shell; não enxerga o pedido educado para configurar uma flag de Git. É a diferença entre reconhecer uma ameaça pela forma e compreendê-la pela intenção — e os modelos atuais fazem só o primeiro.

Conforme análise da Giskard, o problema não veio de alucinação do modelo nem de classificação errada de dados, mas da forma como o gateway do OpenClaw gerencia sessões, ferramentas e permissões entre mensagens diretas, grupos e a interface de controle. A lição é direta: saneamento projetado para um modelo de ameaça (exfiltração de dados) não protege automaticamente contra outro (injeção de código).

Do WhatsApp ao controle total

Diferente de vulnerabilidades anteriores do próprio OpenClaw — a chamada cadeia “Claw Chain”, em que o atacante precisava de um acesso inicial —, essas três falhas oferecem um caminho direto. O fluxo é assustadoramente simples:

  1. O atacante envia uma mensagem de WhatsApp para o número conectado ao agente OpenClaw da vítima.
  2. A mensagem, com contexto técnico plausível, pede ao agente que configure uma variável de ambiente ou execute um “ajuste de CI”.
  3. O modelo interpreta o pedido como legítimo e gera o comando correspondente, já que os filtros de segurança não flagram a formulação.
  4. O comando reativa o transporte ext:: do Git ou injeta uma variável de inicialização, executando código malicioso no host.
  5. Com execução conquistada, o atacante monta diretórios sensíveis via bypass do sandbox e rouba chaves, credenciais e segredos — ou instala um backdoor persistente.

Tudo começa com uma mensagem que parece pedido de colega de equipe e termina com controle total da máquina. Não há clique em link malicioso, não há anexo infectado — apenas texto.

O risco real para o Brasil

O Brasil é um dos países mais dependentes do WhatsApp do mundo: mais de 170 milhões de usuários usam o aplicativo diariamente para comunicação pessoal, comercial e, crescentemente, para automações. A ideia de conectar um agente de IA ao WhatsApp para automatizar tarefas técnicas está ganhando tração entre desenvolvedores e equipes de TI brasileiras que adotam IA generativa com velocidade, mas nem sempre com maturidade de segurança.

O risco é amplificado por um padrão cultural: a naturalização do WhatsApp como canal universal de trabalho. Quando o mesmo número que recebe mensagens de clientes, colegas e familiares também controla um agente com poder de execução no sistema, a fronteira entre confiança e exposição desaparece. Qualquer mensagem que chegue — de qualquer remetente, em qualquer grupo — veta potencialmente o gatilho de um ataque. Esse tema se conecta a outros alertas recentes sobre a segurança de agentes de IA, como o ataque ao Claude Desktop que rouba o PC sem phishing e as 10 ferramentas de agentes de IA que executam código sem proteção.

Como se proteger agora

Se você ou sua equipe usa OpenClaw, as ações abaixo são urgentes.

  1. Atualize imediatamente para a versão 2026.6.6, que corrige as três vulnerabilidades.
  2. Ative o modo sandbox para todas as sessões que não sejam a principal, de forma que o agente fique contido mesmo se for manipulado.
  3. Remova “exec” da lista de ferramentas permitidas para agentes expostos a canais de mensagem como WhatsApp e Discord.
  4. Monitore comandos Git clone que incluam o protocolo ext:: — é o indicador mais confiável de tentativa de exploração do transporte abusivo.
  5. Restrinja o recurso afetado a operadores confiáveis ou desative-o por completo se não estiver em uso.
  6. Nunca compartilhe Gateways entre usuários com níveis de confiança diferentes, e mantenha listas de canais e ferramentas sempre restritivas.

A pesquisa do OpenClaw reforça uma lição que custa caro ignorar: delegar poder de execução a um agente de IA controlado por mensagens é, por design, delegar o teclado da sua máquina a quem souber conversar. Confiar que o modelo vai se proteger sozinho não é estratégia de segurança — é aposta. E, como demonstrado, é uma aposta que perde para qualquer atacante que saiba pedir educação.

Referências