TL, DR
SilverfortA equipe de pesquisa de segurança da OpenClaw identificou uma vulnerabilidade crítica no ClawHub que permite que qualquer invasor posicione sua skill como a número 1 no ClawHub. Ao fazer isso, um invasor pode injetar código malicioso no que parece ser uma skill legítima e confiável, criando a base para um ataque em larga escala à cadeia de suprimentos. Como resultado, um grande número de usuários e agentes da OpenClaw poderia baixar a skill comprometida e executar código malicioso em suas máquinas, potencialmente com privilégios elevados. Em nossa prova de conceito (POC), nossa skill saltou para a posição de download número 1 em sua categoria, resultando em 3,900 execuções de habilidades dentro 6 dias em mais de 50 cidades diferentes ao redor do mundo, incluindo diversas empresas de capital aberto.
Este problema foi comunicado de forma responsável à equipe do ClawHub em 16 de março de 2026 e, desde então, foi solucionado com sucesso.
Para reduzir o risco de tais cadeias de ataques, nossa equipe desenvolveu ClawNet: Um plugin de segurança para OpenClaw que verifica se há padrões maliciosos nas skills durante a instalação, usando o LLM do agente, e em seguida informa o usuário e bloqueia instalações suspeitas.
O que é ClawHub?
O ClawHub é o registro público de habilidades do OpenClaw, onde qualquer pessoa pode publicar um pacote de habilidades para que outros o instalem. Uma habilidade pode, por exemplo, permitir que seu agente OpenClaw se integre ao Google Agenda ou realize buscas otimizadas na web em seu nome. É o equivalente ao npm no ecossistema de agentes OpenClaw. A plataforma ClawHub tem crescido rapidamente, com muitas habilidades já alcançando números massivos de downloads (Quer uma introdução ao OpenClaw?). Você pode ler mais aqui.).
À medida que a popularidade do ClawHub cresce, também cresce seu apelo para os atacantes. A capacidade de publicar habilidades em um mercado que os usuários navegam e instalam ativamente cria uma grande oportunidade na cadeia de suprimentos.
Uma estratégia de ataque clássica envolveria liberar uma skill maliciosa e esperar que os usuários a instalassem. Mas injetar código malicioso em uma skill aparentemente inofensiva não é suficiente — a instalação em larga escala exige que a skill pareça confiável. No ClawHub, assim como em muitos registros públicos como o npm ou o Marketplace do VS Code, a confiança é frequentemente inferida a partir de sua popularidade.
O código do ClawHub é quase inteiramente codificado por vibraçãoEmbora essa abordagem tenha suas vantagens, ela também pode introduzir problemas críticos de segurança. Ao analisar a implementação da ação de download do ClawHub, identificamos uma vulnerabilidade que permite que sinais de confiança baseados em downloads sejam transformados em uma cadeia de ataque escalável.
Encontrando uma habilidade no ClawHub
Suponha que você queira instalar uma skill que permita ao seu agente OpenClaw auxiliar no agendamento de reuniões no Google Agenda. Para isso, você acessaria o ClawHub — seja pela interface web ou pela linha de comando — e procuraria o pacote da skill desejada. Assim que os resultados da busca forem exibidos, a primeira coisa que você notará é a quantidade de downloads da skill. Quanto mais downloads uma skill tiver, mais acima ela aparecerá nos resultados da busca.
Cada pacote de habilidades inclui um SKILL.MD Este arquivo informa ao agente a finalidade da habilidade, quais dependências ela requer e quando e como deve ser usada. Algumas habilidades podem incluir scripts que o agente pode executar sob certas circunstâncias.
Aprofundando-se na pesquisa
Analisando a API de download.
O código do ClawHub é aberto ao público (felizmente para nós). Durante nossa pesquisa, descobrimos que ele expõe uma API para download de skills por meio de um downloadZip função. Em resumo, antes que um download seja contabilizado, a solicitação deve passar por diversas verificações de validação:
- Limitação de taxaMuitas solicitações do mesmo endereço IP ou usuário resultam em bloqueio.
- DeduplicaçãoMesmo que você ultrapasse o limite de requisições, o mesmo IP ou usuário que acessar a mesma skill na mesma hora não será contabilizado novamente.
À primeira vista, parece um projeto defensivo sólido, até que se analise um pouco mais a fundo a sua implementação.
Ignorando o endpoint da API do frontend
ClawHub usa convexo como sua estrutura de backend. Analisando o código-fonte do ClawHub, dois endpoints interessantes estavam publicamente acessíveis:
- URL do site Convex: serve a API HTTP do frontend. Ações como download de habilidades, listagem de usuários e busca de habilidades funcionam por trás dela.
- URL de implantação do Convex É um pouco diferente. Este fala diretamente com o Camada RPC de backend convexa—Sem middleware de ação HTTP, sem tratamento personalizado de requisições. Apenas chamadas de função diretas ao backend.
Uma análise mais detalhada da biblioteca Convex.
Convex é um framework de backend construído em torno de um modelo RPC (Remote Procedure Call) tipado. Em um modelo RPC, em vez de enviar requisições HTTP para endpoints REST ou GraphQL, você chama funções de backend diretamente do cliente. Cada função que você define é automaticamente registrada e pode ser chamada — pense em cada função como seu próprio endpoint.
Convex traça uma linha divisória clara entre funções invocáveis públicas e privadas:
- Funções internas:
internalQuery / internalMutation / internalAction
Privado por definição. Só pode ser invocado por outras funções Convex do lado do servidor, sendo completamente invisível para o mundo exterior. - Funções públicas:
query / mutation / action
Exposta através da URL de implantação do Convex e acessível a qualquer pessoa que conheça ou deduza o nome da função. De acordo com a documentação do Convex, se uma função for definida como pública, qualquer pessoa poderá chamá-la via requisição HTTP da seguinte forma:
É claro que essas funções devem ser usadas. muito Com cuidado. Eles devem validar a entrada do cliente e verificar as permissões para usar a função antes de fazer qualquer alteração no banco de dados do backend.
Descobrindo a função vulnerável
Dentro do arquivo downloads.ts existe uma função chamada increment. Enquanto o fluxo de download legítimo passa por um ambiente altamente protegido mutação interna que impõe limitação de taxa, desduplicação e verificações de permissão, essa função ignora completamente tudo isso.:
Sem autenticação. Sem limite de requisições. Sem desduplicação. Sem qualquer tipo de verificação de permissões.
Ficou claro que era para ser um função interna mas foi definido como um público mutation em vez de internalMutationEsse único erro expõe a vulnerabilidade como um endpoint RPC acessível na URL de implantação, tornando-a pública para todos.
Um atacante pode chamar downloads:increment com uma única requisição curl com qualquer skillId válido, contornando todas as proteções no fluxo de download e Aumentar o contador de downloads de qualquer habilidade sem limite!
Eis como fica:
Obter o ID de implantação e o ID de habilidade é trivial, pois ambos são expostos no tráfego de rede do cliente e podem ser observados inspecionando as respostas do servidor ClawHub.
Formando a cadeia de ataque
Passo 1: Criando a habilidade maliciosa
O ataque começa com a criação e publicação de uma habilidade que parece totalmente legítima. Para esta demonstração, criamos uma Integração do Outlook Graph skill—um utilitário que permite a um agente OpenClaw agendar reuniões, gerenciar os e-mails de um usuário e muito mais.
Oculto no script da habilidade, encontra-se um payload simples de exfiltração de dados. Quando a habilidade é invocada pelo OpenClaw, ela coleta o nome de usuário e o FQDN do cliente e os envia para um servidor que controlamos. Para fins desta pesquisa, o payload é intencionalmente de baixo impacto e não destrutivo.
A carga útil estava embutida em uma função aparentemente legítima chamada “send_telemetry” e, como resultado, a skill não foi identificada como maliciosa.
Claro que, um verdadeiro agressor Isso tornaria essa carga útil muito mais sofisticada; ela pode coletar variáveis de ambiente, caminhos de arquivos locais, tokens armazenados na memória ou qualquer outra coisa acessível dentro do contexto de execução da habilidade.
Etapa 2: Aumentar o contador de downloads
É aqui que o ataque se torna particularmente interessante do ponto de vista da cadeia de suprimentos. Já temos uma skill maliciosa no ClawHub, mas uma skill com zero downloads não vai alcançar ninguém. Quem iria querer instalar uma skill que ninguém nunca experimentou? Precisávamos que ela parecesse confiável.
Então, criamos uma ferramenta simples para fazer exatamente isso. Ao explorar a função vulnerável que encontramos no código-fonte, conseguimos inundar o banco de dados de estatísticas com solicitações para inserir um evento de estatística, incrementando o contador de downloads da nossa skill maliciosa. Quantos downloads? Quantos quisermos! Sem limite de taxa, sem validação, nada nos impedindo.
Em poucos minutos, o contador de downloads da nossa skill subiu significativamente—o suficiente para impulsionar a habilidade ao topo dos resultados de busca em sua categoria..
Passo 3: Observando-o pousar
Após o aumento no número de downloads, os usuários começaram a descobrir e instalar a skill. Resultado: Cerca de 3,900 execuções de habilidades dentro 6 dias Em mais de 50 cidades diferentes ao redor do mundo, incluindo diversas empresas de capital aberto.
Todas essas execuções acionaram uma solicitação HTTP para o nosso servidor, que incluía o nome de domínio e o nome de usuário como parte da execução legítima da habilidade.
Isso demonstra o quão poderosas podem ser essas cadeias de ataque. A skill é executada em nome do usuário com altos privilégios que opera o agente OpenClaw. Neste caso, coletamos apenas o nome de usuário e o domínio, mas um atacante real poderia explorar essas informações para realizar ações muito mais prejudiciais.
OpenClaw cai na mesma armadilha.
Se os usuários humanos podem cair na armadilha dos downloads, o que acontece quando delegamos a decisão ao nosso agente OpenClaw?
Quando solicitado a encontrar a melhor habilidade para um determinado requisito, o agente realiza uma busca no ClawHub por meio da CLI do ClawHub e seleciona uma habilidade dos resultados com base no nome, slug, resumo e pontuação da habilidade. Embora a decisão final sobre qual habilidade instalar seja tomada pelo LLM, a pontuação da habilidade — que influencia essa decisão de acordo com a base de código — é impactada pela semântica do conteúdo e, bem... pela quantidade de downloads.
Então, pedimos ao nosso agente OpenClaw para escolher uma habilidade para gerenciar tarefas de e-mail e calendário e, sem surpresa, ele selecionou a habilidade maliciosa que publicamos. Em sua explicação, afirmou que escolheu essa habilidade por ter a pontuação mais alta (resultado do grande número de downloads).
Protegendo seu agente OpenClaw de habilidades maliciosas
Como o OpenClaw permite a instalação e execução autônoma de habilidades, é essencial garantir que as habilidades instaladas sejam seguras e confiáveis – como já vimos.
Para ajudar a reduzir o risco, recomendamos a instalação do nosso Plugin de segurança ClawNet para OpenClawO ClawNet utiliza o loop do agente OpenClaw para interceptar as chamadas de ferramentas envolvidas na instalação de skills. Antes da instalação de uma skill, o ClawNet solicita ao LLM (Loop de Gerenciamento de Nível de Serviço) do agente que revise o conteúdo da skill e sinalize padrões potencialmente maliciosos. Em seguida, ele entrega os resultados ao usuário e decide se a instalação deve ser bloqueada ou permitida.
Nossa escolha de implementar isso como um plug-in em vez de um habilidade é uma decisão de segurança. Uma habilidade pode ser ignorada ou descartada pelo LLM — seja devido a inferência incorreta ou porque o modelo não é confiável em seguir consistentemente o fluxo de tratamento de habilidades pretendido. Um plugin, por outro lado, integra-se diretamente ao loop do agente OpenClaw e intercepta as tentativas de instalação de habilidades em tempo de execução, garantindo que a verificação seja executada independentemente do comportamento do LLM.
O que podemos aprender com isso?
A codificação baseada em vibrações não é uma estratégia de segurança.
A codificação intuitiva permite um desenvolvimento rápido, mas não substitui práticas de segurança estruturadas. Embora a IA possa criar sistemas notáveis, ela continua sujeita a erros. A supervisão humana ainda é essencial durante o desenvolvimento, pois pequenos detalhes de implementação podem ter implicações significativas para a segurança.
O número de downloads não pode ser seu único sinal de confiança.
Embora possa ser tentador confiar em algo simplesmente porque outros confiam, popularidade não é garantia de segurança. O número de downloads não diz nada sobre a integridade do código, os processos de revisão ou o comportamento seguro. Quando esses sinais são usados como insumos para tomada de decisão — especialmente por sistemas automatizados — eles podem se tornar um vetor de manipulação. Em vez disso, usuários/agentes devem verificar a origem de qualquer skill e usar um verificador de skills dedicado, como o nosso. Plugin ClawNet para OpenClaw, para garantir que os arquivos não contenham padrões suspeitos antes da instalação.
O desenvolvimento de RPC requer limites de segurança explícitos.
Ao contrário das APIs REST (onde rotas, middleware e camadas de validação são normalmente separadas por projeto), frameworks baseados em RPC, como convexo Permitir que os desenvolvedores exponham funções chamáveis diretamente do código de backend pode aumentar o risco de verificações de autorização insuficientes ou validação de entrada inadequada. Melhores Práticas da Convex enfatizar explicitamente este ponto, recomendando a “Utilize algum tipo de controle de acesso para todas as funções públicas”Embora as arquiteturas RPC não sejam inseguras por padrão, elas exigem controle de acesso rigoroso, validação cuidadosa e adesão às melhores práticas documentadas.
Seu agente OpenClaw pode se tornar um risco de segurança.
O poder do OpenClaw reside em sua autonomia — sua capacidade de buscar, avaliar e instalar habilidades sem intervenção humana. No entanto, essa mesma autonomia introduz riscos. Sem mecanismos de verificação e inspeção obrigatórios, a tomada de decisão autônoma do nosso agente pode, involuntariamente, expandir a superfície de ataque.
Os agentes de IA constituem uma classe de identidade própria.
Os agentes de IA constituem uma classe de identidade própria, exigindo o mesmo nível de descoberta, controle em tempo real e endurecimento postural como usuários humanos tradicionais e identidades não humanas. Cada agente deve ser associado a um proprietário humano, e as políticas de acesso devem ser definidas e mapeadas. O resultado é que os agentes só podem fazer o que lhes é explicitamente permitido. Sem privilégios permanentes. Sem exceções.
Divulgação e correção
A vulnerabilidade foi reportada à equipe de segurança da OpenClaw, incluindo seu impacto e detalhes técnicos. A equipe respondeu rapidamente e demonstrou grande colaboração durante todo o processo, resolvendo o problema em [inserir tempo aqui]. menos de 24 horas e implementando a correção em produção (veja o commit de Peter Steinberger, o desenvolvedor principal do OpenClaw, aqui.).
