Mais de 135.000 instâncias de OpenClaw estão expostas na Internet. Uma vulnerabilidade crítica permite a execução remota de código com um único clique a partir de qualquer navegador. Investigadores encontraram mais de 1.100 skills maliciosos a distribuir Atomic Stealer no ClawHub. A Microsoft publicou um artigo intitulado “Running OpenClaw Safely” que começa por notar que “para a maioria dos ambientes, a decisão apropriada pode ser não o implementar.” O centro nacional de cibersegurança da Bélgica emitiu um aviso governamental. A Cisco classificou os agentes de IA pessoais como o OpenClaw como “um pesadelo de segurança.”

Isto não é alarmismo. São factos de investigadores de segurança independentes, fornecedores empresariais e agências governamentais. Se gere uma instância de OpenClaw, isto diz-lhe respeito.

O que correu mal

O OpenClaw foi concebido para localhost. Instala-se na máquina, comunica-se através de uma interface web local e ele executa tarefas em seu nome. O modelo de segurança pressupunha que a pessoa a aceder à interface era a pessoa sentada ao teclado.

Depois, o OpenClaw passou de 9.000 para mais de 200.000 estrelas no GitHub em questão de semanas. As pessoas implementaram-no em servidores VPS, expuseram-no à Internet e ligaram-no aos seus canais de mensagens. O pressuposto do localhost falhou em larga escala. (Cobrimos o espectro completo de opções de implementação e os seus compromissos de segurança num guia separado.)

CVE-2026-25253: execução remota de código com um clique

A vulnerabilidade mais grave é a CVE-2026-25253, com pontuação CVSS 8.8. O OpenClaw não validava os cabeçalhos de origem do WebSocket. Eis como o ataque funciona:

  1. A vítima visita uma página web maliciosa (ou uma página com um anúncio malicioso).
  2. O JavaScript nessa página abre uma ligação WebSocket para localhost:18789, a porta predefinida do OpenClaw.
  3. Como o navegador está na mesma máquina, a ligação contorna quaisquer regras de firewall.
  4. O atacante exfiltra o token de autenticação do gateway através do WebSocket.
  5. Com o token, o atacante tem controlo total: acesso à shell, leitura/escrita de ficheiros e execução de comandos.

Vincular a localhost não ajuda. O ataque utiliza o próprio navegador da vítima como ponto de passagem. A análise da SOCRadar percorre toda a cadeia.

Skills maliciosos e ataques à cadeia de fornecimento

Investigadores encontraram 341 skills maliciosos no ClawHub no início de fevereiro. Esse número cresceu desde então para mais de 1.100. A campanha ClawHavoc distribui Atomic Stealer através de skills que parecem legítimos mas contêm passos ocultos de execução de comandos. Os skills são ficheiros Markdown. Uma instrução oculta que diz “executa este comando shell” é fácil de incorporar e difícil de detetar.

A 17 de fevereiro, o ataque à cadeia de fornecimento do Cline foi mais longe. Um token npm comprometido foi usado para publicar uma versão do CLI do Cline que instalava silenciosamente o OpenClaw nas máquinas dos programadores. O ataque visou diretamente o pipeline de build.

Os investigadores divulgaram agora mais seis vulnerabilidades no núcleo do OpenClaw, incluindo a CVE-2026-27001. O OWASP Top 10 para Aplicações Agênticas lista agora muitos destes padrões como riscos principais. Como a análise da Conscia refere, trata-se de uma crise de segurança em plena regra.

Porque é que um token de gateway não é suficiente

A autenticação integrada do OpenClaw é um token estático. Define-se uma vez, e cada pedido deve incluí-lo. É melhor do que nada. Mas tem limitações fundamentais.

Os tokens estáticos não expiram. Se um token é divulgado (através da CVE-2026-25253, através de logs, através de um skill malicioso que lê variáveis de ambiente), o atacante tem acesso permanente até que detete a fuga e faça a rotação manualmente.

Os tokens estáticos não podem ter âmbito limitado. O token do gateway concede acesso total. Não há forma de dar acesso apenas de leitura ou limitar o que uma sessão autenticada pode fazer.

Os tokens estáticos não podem ser associados a um utilizador. Se três pessoas partilham um token, não há registo de auditoria sobre quem fez o quê.

A maioria dos guias de implementação em VPS aconselha colocar o OpenClaw atrás de nginx com autenticação básica. É melhor, mas continua a ser uma credencial estática. Se alguém a captura (sniffing de rede numa ligação não encriptada, uma configuração de reverse proxy comprometida, um ficheiro .htpasswd divulgado), tem acesso.

O problema fundamental é mais profundo: a autenticação acontece dentro da aplicação. Se a aplicação tem uma vulnerabilidade, a autenticação pode ser contornada. A CVE-2026-25253 demonstrou-o exatamente. O token do gateway existia. A vulnerabilidade extraiu-o antes de a aplicação ter sequer a oportunidade de o verificar.

É por isso que construímos o OpenClaw.rocks com autenticação ao nível do proxy. As secções seguintes explicam a arquitetura em detalhe. Se simplesmente quer uma instância segura sem construir tudo isto, veja os nossos planos.

Como protegemos o gateway

No OpenClaw.rocks, a autenticação acontece ao nível do proxy, antes de o pedido sequer chegar ao pod do OpenClaw. Esta é uma diferença estrutural, não apenas uma diferença de configuração.

Eis a arquitetura de três camadas.

Camada 1: Cookies de gateway assinados (HMAC-SHA256)

Quando acede à sua instância de OpenClaw através do painel do OpenClaw.rocks, o servidor gera um cookie assinado. O formato é:

{expiry}.{userId}.{instanceId}.{hmac_base64url}

O cookie tem um TTL de 4 horas e renova-se automaticamente a cada 45 minutos. Está limitado ao caminho /gw/{instanceId}, pelo que um cookie não pode ser usado para aceder a uma instância diferente. É HttpOnly (o JavaScript não o pode ler), Secure (enviado apenas por HTTPS) e SameSite=Lax (não enviado em pedidos cross-origin). O HMAC é verificado usando comparação de tempo constante para prevenir ataques de temporização.

Mesmo que alguém intercete o valor do cookie, não consegue forjar um novo sem o segredo de assinatura. E o cookie em si não contém credenciais que concedam acesso direto ao OpenClaw.

Camada 2: Traefik ForwardAuth

Cada pedido a uma instância de OpenClaw passa pelo Traefik, o nosso reverse proxy. Antes de encaminhar o pedido, o Traefik chama um endpoint auth-gate que verifica o cookie assinado.

Trata-se de verificação HMAC pura. Zero chamadas à base de dados. Zero pedidos de rede ao Supabase ou a qualquer outro serviço. A decisão é tomada em microssegundos.

Se o cookie é inválido, expirou ou está ausente, o pedido é rejeitado ao nível do proxy. O pedido nunca chega ao OpenClaw. Esta é a diferença fundamental. Numa configuração típica, é o próprio OpenClaw que tem de decidir se permite ou rejeita um pedido. Se o OpenClaw tem uma vulnerabilidade na sua lógica de autenticação, um atacante pode passar. Na nossa configuração, o OpenClaw nunca vê tráfego não autenticado.

Camada 3: Injeção do token do gateway

Cada instância de OpenClaw tem um token de gateway integrado. É o mesmo token que configuraria se fizesse self-hosting. A diferença está na forma como chega ao pod.

Numa configuração típica de self-hosting, cola-se o token num ficheiro de configuração, talvez armazena-se numa variável de ambiente, e espera-se que nunca seja divulgado. O navegador precisa de o enviar em cada pedido, que é exatamente o mecanismo que a CVE-2026-25253 explorou para o exfiltrar.

Na nossa configuração, um token criptograficamente aleatório de 32 bytes é gerado na criação da instância e armazenado como Kubernetes Secret. O Traefik injeta-o como cabeçalho Authorization em cada pedido encaminhado. O navegador nunca o vê. Nunca aparece num ficheiro de configuração que possa acidentalmente fazer commit. Nunca viaja por um WebSocket que uma página maliciosa possa sequestrar. O token existe, mas vive inteiramente dentro do cluster, movendo-se apenas entre o Traefik e o pod.

Porque é que esta arquitetura bloqueia a CVE-2026-25253

A cadeia de ataque da CVE-2026-25253 exfiltra o token do gateway via WebSocket. Vejamos o que acontece quando este ataque visa uma instância do OpenClaw.rocks:

  1. O JavaScript do atacante tenta abrir um WebSocket para o pod do OpenClaw.
  2. A ligação chega primeiro ao Traefik. O Traefik verifica o cookie assinado.
  3. A página maliciosa está numa origem diferente. O cookie SameSite=Lax não é enviado em ligações WebSocket cross-origin. O pedido é rejeitado.
  4. Mesmo que o cookie fosse de alguma forma anexado, a página do atacante não o pode ler (HttpOnly). Não há nada para exfiltrar.
  5. Mesmo que o cookie fosse divulgado, não contém o token bearer. O token bearer é injetado pelo Traefik, nunca exposto ao navegador. O atacante não o pode reconstruir.

Não há nada para roubar porque o navegador nunca detém as credenciais reais. A superfície de ataque que a CVE-2026-25253 explora simplesmente não existe.

Checklist de segurança do OpenClaw para quem faz self-hosting

Nem toda a gente quer hosting gerido, e está tudo bem. Se gere a sua própria instância de OpenClaw, eis uma checklist prática para 2026.

O seu token de autenticação do gateway está ativado? Execute openclaw doctor para verificar. Se a autenticação do gateway está desativada, qualquer pessoa que consiga alcançar a porta 18789 controla o seu agente e tudo a que ele tem acesso.

A sua instância está atrás de um reverse proxy com TLS? HTTP sem encriptação significa que qualquer pessoa no caminho de rede pode ler o seu token do gateway em trânsito. Use nginx, Caddy ou Traefik com um certificado TLS válido. O Let’s Encrypt é gratuito.

Está na versão mais recente? A CVE-2026-25253 foi corrigida na v2026.1.29. A CVE-2026-27001 foi corrigida na v2026.2.15. Se está a executar uma versão mais antiga, atualize agora. O guia de hardening da Adversa AI cobre passos adicionais.

Auditou os seus skills instalados? A campanha ClawHavoc visou especificamente o ClawHub. Verifique cada skill que instalou. Se não o instalou pessoalmente, remova-o e verifique a fonte.

O seu reverse proxy valida as origens WebSocket? Este é o vetor específico que a CVE-2026-25253 explorou. O seu reverse proxy deve rejeitar pedidos de upgrade WebSocket de origens inesperadas. A documentação de segurança do OpenClaw contém exemplos de configuração.

A sua autenticação acontece antes ou depois de o pedido chegar ao OpenClaw? Esta é a pergunta mais importante. Se o OpenClaw trata da sua própria autenticação, uma vulnerabilidade no OpenClaw pode contorná-la. Se o seu reverse proxy trata da autenticação, o pedido nunca chega ao OpenClaw a menos que já esteja verificado.

O que não resolvemos

A honestidade importa aqui. A autenticação ao nível do proxy resolve a segurança do gateway. Não resolve tudo.

A injeção de prompt é um problema ao nível da aplicação. Uma mensagem habilmente elaborada pode potencialmente levar o agente a realizar ações não pretendidas. Esta é uma área ativa de investigação em toda a indústria de IA, e nenhum fornecedor de hosting pode preveni-la totalmente hoje.

O comportamento malicioso dos skills executa-se dentro do contexto do agente. Se instala um skill que exfiltra dados através de tráfego HTTPS de saída permitido, a autenticação proxy não o pode impedir. O que a nossa infraestrutura faz é conter o raio de explosão: cada instância corre no seu próprio pod Kubernetes com isolamento de rede, capabilities reduzidas, seccomp e um sistema de ficheiros raiz apenas de leitura. Um agente comprometido não consegue alcançar outros agentes ou o sistema anfitrião. O operador Kubernetes aplica estas predefinições para cada instância.

A confiança no fornecedor LLM depende do seu plano. Se usa as suas próprias chaves API (plano Light), as suas conversas passam pelo fornecedor que configurar, e aplica-se a respetiva política de privacidade. No plano Pro, encaminhamos o tráfego através do nosso próprio gateway de IA com fornecedores pré-configurados. Não precisa de entregar as suas chaves API a uma instância de OpenClaw nem confiar que uma chave de terceiros é armazenada de forma segura. O gateway gere as credenciais dos fornecedores em seu nome, e nunca as vê nem manuseia diretamente.

A segurança funciona por camadas. Nós tratamos das camadas de infraestrutura. Os desafios ao nível da aplicação são reais e merecem ser compreendidos.

A segurança é uma decisão de arquitetura

A crise de segurança do OpenClaw não se resume a um CVE ou a um lote de skills maliciosos. Trata-se de uma ferramenta concebida para localhost a ser implementada na Internet por centenas de milhares de pessoas, com autenticação que acontece dentro da aplicação que deveria proteger.

Mover a autenticação para o nível do proxy não é uma funcionalidade. É uma decisão de arquitetura. Significa que quando o próximo CVE do OpenClaw for publicado (e será), os pedidos autenticados continuarão a ser verificados antes de tocarem na aplicação. A superfície de ataque é estruturalmente mais pequena.

Tomámos essa decisão desde o primeiro dia. Cada instância do OpenClaw.rocks corre atrás de cookies assinados, verificação ForwardAuth e tokens bearer por instância. Sem tokens de gateway no navegador. Sem credenciais estáticas para exfiltrar. Sem lógica de autenticação dentro da aplicação vulnerável.

Se quiser saber mais sobre como implementamos o OpenClaw em Kubernetes com hardening de segurança completo, o guia de implementação cobre o tema em detalhe.

Se simplesmente quer um agente a funcionar que se mantenha seguro sem pensar em nada disto, foi exatamente isso que construímos.

Comece no OpenClaw.rocks ou explore o operador Kubernetes open-source se preferir gerir a sua própria infraestrutura.