O OpenClaw passou de "projeto interessante de agente de IA" para "alvo ativo de segurança" em tempo recorde. Relatórios recentes descrevem vários agentes de ameaças explorando implantações do OpenClaw para roubar chaves de API e fornecer cargas mal-intencionadas, enquanto pesquisas paralelas e avisos mostram um padrão mais amplo: não se trata de um bug, mas de um problema de segurança em nível de ecossistema que abrange planos de controle expostos, suposições de privilégios locais, confiança de extensão insegura e fluxos de trabalho de agentes que obscurecem o limite entre dados e instruções. (Notícias sobre segurança cibernética)
Se você é um engenheiro de segurança, o que mais importa não é apenas a manchete. É o modelo repetível por trás dos incidentes:
- Um agente local com privilégios elevados acumula segredos
- Ele expõe interfaces (Web, WebSocket, chat, habilidades, registros)
- Os usuários instalam recursos de terceiros
- Os atacantes usam engenharia social + falhas de design + padrões fracos
- Os defensores corrigem um problema, mas perdem a exposição operacional
Esse padrão é o motivo pelo qual o OpenClaw se tornou um estudo de caso tão útil para a segurança de agentes de IA em 2026. As páginas de consultoria do GitHub e as listagens de consultoria do repositório do OpenClaw também mostram um fluxo rápido de correções de segurança recém-publicadas, o que é exatamente o que se espera de um projeto que se expande mais rapidamente do que a maturidade de seu modelo de ameaças. (GitHub)
Este artigo detalha a recente onda de exploração, as vulnerabilidades e os alertas mais relevantes, o problema de malware do mercado de habilidades e os controles práticos que as equipes devem implementar imediatamente. Ele também inclui lógica de detecção defensiva, listas de verificação de validação e exemplos de padrões de automação que as equipes de segurança podem adaptar sem transformar nada em arma.
O que aconteceu na última onda de exploração do OpenClaw
Um relatório recente descreveu Exploração generalizada do OpenClaw (antigo MoltBot / Clawdbot) por vários grupos de hackers para implantar cargas maliciosas e roubar chaves de API de instâncias expostas ou fracamente protegidas. O relatório enquadra isso como uma tendência de campanha ativa em vez de um risco puramente teórico, o que corresponde à trajetória mais ampla observada na cobertura recente da OpenClaw. (Notícias sobre segurança cibernética)
Ao mesmo tempo, relatórios e análises separados foram documentados:
- Implantações do OpenClaw expostas à Internet em escalaincluindo milhares a dezenas de milhares de instâncias acessíveis, dependendo da metodologia de varredura/janela de tempo. Hunt.io, por exemplo, relatou mais de 17.500 instâncias expostas em uma análise focada na caça à exposição do CVE-2026-25253. (hunt.io)
- Habilidades mal-intencionadas no ClawHub / ecossistema de extensões do OpenClawA cobertura principal citou descobertas de muitos complementos/competências mal-intencionados que visavam credenciais e ativos de criptografia por meio de engenharia social e comportamento de extensão executável. (The Verge)
- Vários avisos de segurança e CVEs afetando os principais comportamentos, como vazamento de token, aplicativo de configuração inseguro e caminhos de registro que se tornam relevantes para a segurança quando alimentados em fluxos de trabalho assistidos por IA. (NVD)
Em outras palavras, o problema atual do OpenClaw é melhor compreendido como um superfície de ataque composta:
- Risco de exposição (planos de controle voltados para a Internet)
- Risco de vulnerabilidade (CVEs / alertas conhecidos)
- Risco da cadeia de suprimentos (habilidades/extensões)
- Risco de fluxo de trabalho (registros, avisos, depuração assistida por IA)
- Risco operacional (usuários que corrigem o código, mas não alternam segredos ou reduzem privilégios)
É por isso que apenas a aplicação de patches não é suficiente.
Por que o OpenClaw se tornou um alvo de alto valor tão rapidamente
O OpenClaw é atraente para os invasores pelo mesmo motivo que é atraente para os usuários: ele concentra a capacidade.
A cobertura convencional descreve o OpenClaw como um agente de IA local que pode executar tarefas em nome do usuário e pode receber amplo acesso a arquivos locais, scripts, comandos de shell e serviços conectados. Essa combinação transforma o comprometimento de um agente em um roubo de credenciais problema e, em muitos ambientes, um movimento lateral problema. (The Verge)
Isso muda o aspecto econômico do ataque:
- Um compromisso bem-sucedido pode resultar em várias chaves de API (provedores de LLM, ferramentas de nuvem, plataformas de mensagens).
- O agente pode atuar como um representante de confiança.
- Os ecossistemas de habilidades criam um canal de distribuição para lógica maliciosa.
- A população de usuários inclui desenvolvedores e usuários avançados com ambientes privilegiados.
Os invasores não precisam de uma exploração perfeita todas as vezes. Eles podem vencer por meio de uma combinação de implementação fraca, integrações com permissão excessiva e engenharia social.
A mudança no modelo de ameaças principais: De "vulnerabilidade de aplicativos" para "abuso do plano de controle do agente"
As categorias tradicionais de segurança de aplicativos Web ainda são importantes (RCE, desvio de autenticação, injeção de comando, passagem de caminho, SSRF etc.), mas o OpenClaw acrescenta um problema mais novo e mais sutil: o próprio agente é um orquestrador de execução.
Isso cria três limites de segurança que os defensores devem modelar explicitamente:
1) Limite de confiança entre humanos e agentes
Os usuários confiam no assistente para executar a intenção com segurança. Os invasores abusam disso por meio de links maliciosos, habilidades maliciosas, instruções de configuração falsas ou manipulação em nível de prompt.
2) Limite de confiança entre agente e sistema
O agente pode ter acesso à execução do shell, arquivos locais, tokens e recursos de rede. Quando o agente é manipulado, ele se torna uma superfície de execução privilegiada.
3) Limite de dados para instrução
Registros, markdown, comentários e "texto útil" podem ser consumidos posteriormente por fluxos de trabalho de LLM. O GHSA-g27f-9qjv-22pm do GitHub é um exemplo claro de como até mesmo um caminho de registro pode se tornar relevante para a segurança quando os registros são lidos por sistemas de depuração assistidos por IA. (GitHub)
É por isso que muitas equipes subestimam o risco do OpenClaw no início: elas defendem o caminho do código que reconhecem, mas não o caminho do fluxo de trabalho que criaram.
As vulnerabilidades e alertas mais relevantes do OpenClaw no momento
Abaixo estão os problemas mais importantes a serem compreendidos ao analisar o cenário atual de exploração do OpenClaw. Esses não são os únicos problemas, mas são altamente instrutivos porque mapeiam os modos de falha comuns do mundo real.
CVE-2026-25253: URL do gateway / cadeia de exposição de token
A NVD descreve o CVE-2026-25253 como um problema no OpenClaw (também conhecido como Clawdbot/Moltbot) antes da versão 2026.1.29, em que um gatewayUrl pode ser obtido por meio de uma string de consulta e o OpenClaw estabelece automaticamente uma conexão WebSocket sem solicitar, enviando um valor de token. O NVD lista o vetor CVSS v3.1 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H e CWE-669. (NVD)
Essa vulnerabilidade é notável porque demonstra um antipadrão recorrente de segurança de agentes:
- A entrada controlada pelo usuário influencia o roteamento do plano de controle
- O comportamento de conexão automática ocorre sem validação/pedido forte
- Os tokens confidenciais são transmitidos como parte do estado do fluxo de trabalho
Ele também se alinha aos relatórios públicos sobre cenários de ataque de "um clique" e riscos de roubo de tokens nos ecossistemas OpenClaw. (depthfirst.com)
CVE-2026-25593: Injeção de comando para gravação de configuração de WebSocket local
A NVD descreve o CVE-2026-25593 como uma vulnerabilidade em que, antes da versão 2026.1.20, um cliente local não autenticado poderia usar a API do Gateway WebSocket para gravar a configuração por meio de config.apply e definir inseguro cliPath usados posteriormente para a descoberta de comandos, permitindo a injeção de comandos como o usuário do gateway. A NVD registra a correção na versão 2026.1.20. (NVD)
Isso é importante do ponto de vista operacional porque muitas equipes tratam a exposição "somente local" como de baixo risco. Em ambientes de desenvolvedores, essa suposição geralmente está errada devido a:
- Padrões de acesso ao host local assistidos pelo navegador
- malware local já presente
- encaminhamento de portas / proxies reversos
- confiança insegura em "mesma máquina = = máquina segura"
GHSA-g27f-9qjv-22pm: envenenamento de registro por meio de cabeçalhos WebSocket (risco de injeção indireta de prompt)
O banco de dados consultivo do GitHub afirma que, em versões anteriores à 2026.2.13, o OpenClaw registrava determinados cabeçalhos de solicitação WebSocket (incluindo Origem e Agente do usuário) sem neutralização ou limites de comprimento em um caminho "fechado antes da conexão". O GitHub observa explicitamente que, se um cliente não autenticado puder acessar o gateway e enviar valores de cabeçalho criados, esses valores poderão ser gravados nos registros e, se os registros forem lidos/interpretados posteriormente por um LLM, isso poderá aumentar o risco de injeção indireta de prompt (envenenamento de registro). A versão corrigida está listada como 2026.2.13. (GitHub)
Esse é um dos exemplos mais claros de uma lição moderna de segurança de agente de IA:
Um problema de "baixa gravidade" em um modelo de aplicativo clássico pode se tornar materialmente importante em um fluxo de trabalho assistido por IA.
O GitHub classifica a consultoria como de baixa gravidade (CVSS 3.1) e observa que o impacto é limitado se você não alimentar os registros em um LLM ou em outra automação. Essa condicionalidade é exatamente o que os defensores maduros precisam preservar em seu modelo de ameaças, em vez de achatar tudo em "crítico" ou "nada". (GitHub)
O quadro consultivo mais amplo
A página de avisos de segurança do GitHub do OpenClaw mostra um fluxo substancial e ativo de problemas publicados, incluindo vários itens moderados/altos no final de fevereiro de 2026. A lista exata evolui rapidamente, mas a principal conclusão é que a superfície de ataque do OpenClaw é ampla e está sendo ativamente reforçada sob pressão real. (GitHub)
Para os defensores, isso significa que a cadência do patch deve ser combinada com priorização baseada em riscos e verificação do ambientee não apenas "atualizar quando for conveniente".
O problema do ecossistema de habilidades: quando "extensões" se transformam em fornecimento de malware
O ecossistema de habilidades do OpenClaw (incluindo referências ao ClawHub na cobertura) é onde muitas equipes são pegas de surpresa. Diversos meios de comunicação relataram habilidades mal-intencionadas disfarçadas de ferramentas úteis (especialmente temas de criptografia/negociação) e que fornecem malware para roubo de informações por meio de engenharia social e comportamentos executáveis. A cobertura também destaca que as habilidades não são metadados inofensivos - elas podem interagir com arquivos e redes locais depois de instaladas e ativadas. (The Verge)
O The Verge relatou descobertas do OpenSourceMalware e descreveu malware em centenas de habilidades enviadas por usuários, incluindo comportamento projetado para roubar ativos de criptografia, credenciais de API, credenciais SSH e senhas de navegador. Ele também observa o crescimento da popularidade do OpenClaw e os amplos poderes locais que alguns usuários concedem a ele. (The Verge)
A Tom's Hardware também relatou habilidades maliciosas carregadas no ClawHub, enfatizando que as habilidades são pastas de código executável (não scripts em sandbox) e padrões de engenharia social documentados que instruem os usuários a colar comandos de terminal ofuscados que buscam cargas remotas. (Hardware do Tom)
Essa não é apenas uma história de "malware em um mercado". É uma história de amplificação do privilégio do agente história:
- O código de extensão herda a confiança do usuário e, muitas vezes, os privilégios do agente
- Os fluxos de documentação/configuração podem ser transformados em armas
- As etapas de execução manual de comandos ignoram algumas varreduras convencionais
- Os usuários podem avaliar as habilidades pela utilidade, não pela qualidade da revisão de código
Por que isso parece diferente do risco tradicional do registro de pacotes
Os ecossistemas de pacotes (npm, PyPI, etc.) já apresentam riscos na cadeia de suprimentos, mas as habilidades no estilo do OpenClaw acrescentam um padrão distinto:
- O "instalador" pode ser efetivamente instruções em markdown/docs
- O agente foi projetado para executar ações
- Os usuários são condicionados a seguir as etapas de configuração orientadas para a automação
- A carga útil pode combinar prompts de IA + execução de script + buscas externas
Esse modelo híbrido significa que os defensores precisam inspecionar não apenas as assinaturas de código e os hashes, mas também intenção comportamentalinstruções de configuração e padrões de comunicação entre domínios.
A história recente de exploração é maior do que uma campanha
A manchete "vários grupos de hackers explorando instâncias do OpenClaw" é importante porque sinaliza uma transição do oportunismo isolado para exploração do ecossistema. Quando vários conjuntos de atores convergem para a mesma plataforma, geralmente ocorrem três desenvolvimentos paralelos:
- Campanhas de imitação usando relatórios públicos e PoCs
- Comoditização de ferramentas (scripts/scanners para instâncias expostas)
- Especialização pós-exploração (roubo de tokens, loaders, infostealers, persistência)
Isso é consistente com o padrão mais amplo das operações do crime cibernético: quando uma plataforma se torna comum, exposta e rica em credenciais, ela é absorvida pelos pipelines existentes de malware e roubo de credenciais.
Especificamente para o OpenClaw, a proposta de valor para os invasores é excepcionalmente forte porque uma única vítima pode expor:
- Chaves de API do provedor de LLM
- tokens de plataforma de mensagens
- credenciais de automação
- artefatos de navegador/sessão
- dados do sistema de arquivos
- caminhos de execução do shell
Como pensar no roubo de chaves de API em incidentes com o OpenClaw
A manchete enfatiza o roubo de chaves de API, e é exatamente nesse ponto que muitas organizações subestimam o impacto.
Por que as chaves de IA/API roubadas não são "apenas um risco de faturamento"
Às vezes, as equipes de segurança tratam o roubo de chaves de API como um problema financeiro ("alguém usou nossa cota"). Nos contextos da OpenClaw, as chaves roubadas podem oferecer suporte:
- Exfiltração de dados
- Abuso de serviços integrados
- Representação operacional
- Reconhecimento de fluxos de trabalho internos
- Persistência por meio da reautomação
Se o agente tiver acesso a vários provedores, os invasores poderão usar seletivamente a chave mais valiosa (por exemplo, cotas mais altas, direitos corporativos, menor maturidade de monitoramento).
O que os defensores devem fazer após o roubo de chaves (além do rodízio)
Uma resposta madura inclui:
- Girar teclas
- Auditar onde as chaves foram usadas
- Identificar quais dados/fluxos de trabalho estavam acessíveis
- Analise os prompts/tarefas/logs do agente quanto a execuções suspeitas
- Refaça a linha de base do host
- Reavaliar privilégios e estender a confiança
Simplesmente girar a chave, mas deixar o mesmo agente exposto/com privilégios excessivos no local, é uma falha recorrente.
Um modelo prático de cadeia de ataque que as equipes de segurança podem usar
Abaixo está uma abstração defensiva e não armada de como os recentes comprometimentos do OpenClaw tendem a encadear fatores de risco.
Tabela: Estágios representativos da cadeia de ataque do OpenClaw
| Estágio | Atacante Gol | Mecanismo comum | Ponto cego do Defender | Prioridade defensiva |
|---|---|---|---|---|
| Descoberta inicial | Encontrar alvos | Varredura na Internet, referências públicas | "Está em um porto estranho, ninguém vai encontrá-lo" | Remover a exposição, restringir a entrada |
| Acesso inicial | Alcance o gateway/plano de controle | UI/WebSocket exposta, suposições de confiança local, instalação de habilidades maliciosas | Suposições de "somente local"/autenticação fraca | Patch + autenticação + controles de rede |
| Acesso a credenciais | Roubo de chaves/tokens de API | Endpoints de exportação, roubo de configuração, cargas úteis de infostealer | Chaves armazenadas de forma ampla e reutilizadas | Rotação secreta + escopo |
| Execução | Executar malware/comandos | Ferramentas do agente, caminhos do shell, código de extensão, comandos de colar do usuário | Agente visto como "ajudante", não como executor | Privilégio mínimo + listas de permissão |
| Persistência / Reutilização | Manter o ponto de apoio ou monetizar | Novas habilidades, tokens roubados, tarefas programadas | Monitoramento fraco das ações do agente | Detecção comportamental + revisão |
| Evasão da defesa | Evitar aviso | Atividade combinada de agente legítimo | Registros não normalizados / sem linhas de base | Trilhas de auditoria + regras de anomalia |
Esta tabela é intencionalmente geral porque os mecanismos exatos variam de acordo com a versão, a implementação e o comportamento do usuário. O objetivo é garantir que seus controles cubram os cadeiae não apenas o primeiro bug da cadeia.
Ideias de detecção e caça para equipes de engenharia de segurança e SOC
A segurança do OpenClaw não é apenas um problema de gerenciamento de patches. É também um problema de telemetria.
O que coletar
No mínimo, colete e retenha:
- Registros de acesso de proxy reverso (se fronted)
- Registros do gateway OpenClaw
- Registros de criação de processos do host
- telemetria de rede de saída
- telemetria de criação/execução de arquivos nos diretórios de trabalho do agente
- eventos de instalação de extensões/habilidades (ou equivalentes)
- eventos de rotação de chaves/acesso a segredos em seu gerenciador de segredos (se integrado)
O que caçar
Concentre-se em grupos de comportamento em vez de indicadores individuais:
- Atividade inesperada do WebSocket para gateways de agente de fontes não confiáveis
- Anomalias de cabeçalho (valores longos/codificados) em caminhos voltados para o agente
- Processos infantis incomuns gerados por serviços relacionados a agentes
- Chamadas de saída para domínios recém-visitados logo após a instalação da habilidade
- Execução do comando do terminal após a configuração da extensão avisos
- Sequência rápida de uso de chaves de novos IPs após suspeita de comprometimento
Exemplo de conceito de detecção no estilo SIEM (Pseudo-KQL)
// Conceito de caça defensiva: atividade suspeita em torno dos processos do host OpenClaw
let OpenClawProcs = dynamic(["openclaw", "moltbot", "clawdbot"]);
DeviceProcessEvents
| where InitiatingProcessFileName has_any (OpenClawProcs)
| summarize ChildCount = count(), Children = make_set(FileName, 20) by DeviceName, bin(Timestamp, 15m)
| join kind=leftouter (
DeviceNetworkEvents
| where InitiatingProcessFileName has_any (OpenClawProcs)
| summarize RemoteIPs = make_set(RemoteIP, 50), Domains = make_set(RemoteUrl, 50) by DeviceName, bin(Timestamp, 15m)
) on DeviceName, Timestamp
| where ChildCount > 5 or array_length(Domains) > 10
| projeto Timestamp, DeviceName, ChildCount, Children, RemoteIPs, Domains
Essa não é uma assinatura para "a" campanha de malware do OpenClaw. É uma maneira de encontrar explosões de comportamento orientadas por agentes que merecem revisão.
Exemplo de heurística do tipo YARA para scripts de instalação de habilidades suspeitas (conceitual)
regra Suspicious_OpenClaw_Skill_Setup_Instruction_Pattern
{
meta:
description = "Sinaliza documentos/scripts suspeitos de habilidades do OpenClaw que enviam padrões de fetch-exec de terminal ofuscados"
autor = "Padrão de pesquisa defensiva"
caution = "Apenas heurístico; espere falsos positivos"
strings:
$a = /curl\\s+.*\\|\\s*(bash|sh)/ nocase
$b = /python\\s+-c\\s+["'].*base64/i
$c = /osascript.*do shell script/i
$d = /powershell(\\.exe)?\\s+-enc/i
$e = "copiar e colar este comando" nocase
$f = "desative seu antivírus" nocase
condição:
2 de ($a,$b,$c,$d,$e,$f)
}
Use-o como auxílio de triagem para revisões de habilidades, não como substituto para a análise real.
Fortalecimento das implementações do OpenClaw: O que de fato reduz o risco
As equipes de segurança geralmente solicitam uma "lista de verificação de práticas recomendadas". A resposta útil é uma ordem de prioridade, não uma lista gigante.
Prioridade 1: remover a exposição das interfaces de controle à Internet
Se a interface de controle ou o gateway do OpenClaw puder ser acessado pela Internet pública, corrija isso primeiro. Vários relatórios e estudos de exposição mostram que esse é um dos facilitadores mais consistentes de comprometimento e roubo de tokens. (hunt.io)
Controles de linha de base:
- vincular-se ao localhost sempre que possível
- Exigir acesso VPN/Zero Trust para administração remota
- impor a autenticação no proxy reverso
- Acesso de administrador à lista de permissões de IP
- Limite de taxa e limite de tamanho de cabeçalho para pontos de extremidade voltados para o agente
A consultoria do GitHub para o GHSA-g27f-9qjv-22pm menciona especificamente a restrição da exposição da rede do gateway e a aplicação de limites de proxy reverso no tamanho do cabeçalho como etapas de solução alternativa/fortalecimento. (GitHub)
Prioridade 2: corrigir rapidamente, mas verificar a versão e o comportamento
Para as vulnerabilidades discutidas acima, as versões dos patches são importantes:
- CVE-2026-25253afetados antes de 2026.1.29 (por NVD) (NVD)
- CVE-2026-25593: corrigido em 2026.1.20 (por NVD) (NVD)
- GHSA-g27f-9qjv-22pm: corrigido em 2026.2.13 (de acordo com a consultoria do GitHub) (GitHub)
Mas as verificações de versão não são suficientes. As equipes devem verificar:
- o serviço foi realmente reiniciado
- o ponto de extremidade exposto não pode mais ser acessado
- os tokens foram girados se houver a possibilidade de exposição
- Os fluxos de trabalho de logs/LLM não estão ingerindo conteúdo não confiável de forma insegura
Prioridade 3: reduzir o privilégio do agente e o escopo do token
O risco do OpenClaw aumenta com o privilégio. Se um agente tiver amplo acesso ao sistema de arquivos, execução de shell e tokens OAuth/API de alto valor, o impacto do comprometimento aumentará drasticamente.
Alterações recomendadas:
- identidades/contas separadas para uso do agente
- privilégio mínimo em escopos de API
- credenciais de curta duração sempre que possível
- sem tokens de nuvem em nível de administrador
- não manter segredos de produção em dispositivos pessoais
- isolar o tempo de execução do agente dos segredos da estação de trabalho do desenvolvedor
As recomendações da Eye Security sobre atualização, privilégio mínimo e evitar conexões de API altamente confidenciais, a menos que seja necessário, estão alinhadas com essa direção. (Pesquisa ocular)
Prioridade 4: Tratar as habilidades como dependências executáveis (porque elas são)
A cobertura principal enfatiza que as habilidades do OpenClaw podem agir com acesso significativo e não são metadados inofensivos. (The Verge)
Adotar um processo formal:
- habilidades aprovadas pela lista de permissões
- Exigir revisão de código para novas habilidades
- espelhar habilidades examinadas internamente
- bloquear instalações diretas de registros públicos em endpoints corporativos
- inspecionar instruções de configuração e documentos, não apenas arquivos de código
- monitorar o processo pós-instalação/comportamento da rede
Prioridade 5: tratar os registros como entrada não confiável em fluxos de trabalho de IA
O aviso do GitHub é explícito: se os registros forem lidos/interpretados posteriormente por um LLM, os valores criados nos registros podem aumentar o risco de injeção indireta de prompt. As soluções alternativas incluem sanitização/escapamento e não execução automática de instruções derivadas de registros. (GitHub)
Isso se aplica além do OpenClaw. Qualquer pipeline de depuração assistida por IA deve:
- higienizar o conteúdo do registro
- preservar rótulos de procedência (não confiáveis ou gerados pelo sistema)
- impedir a execução de ações diretas a partir de sugestões de modelos
- exigir aprovação humana para os comandos
- evitar alimentar logs brutos em automações privilegiadas
A verificação é mais importante do que as notas de atualização
Um dos maiores erros operacionais na atual onda do OpenClaw é tratar a correção como um exercício de documentação ("fizemos o upgrade") em vez de um exercício de verificação ("provamos que o comportamento arriscado parou").
As equipes de segurança devem validar a correção em quatro camadas:
1) Validação de versão
Confirme a versão em tempo de execução, não apenas a saída do gerenciador de pacotes.
2) Validação da rede
Verifique se o plano de controle não pode ser acessado externamente.
3) Validação do comportamento
Teste se os fluxos anteriormente arriscados (por exemplo, comportamento de registro de cabeçalho, gravações de configuração, capacidade de alcance do ponto de extremidade) são realmente atenuados.
4) Validação de higiene secreta
As chaves de confirmação foram giradas e as credenciais antigas não funcionam mais.
Exemplo de script de validação defensiva (sem exploração, somente verificações de sanidade)
#!/usr/bin/env python3
"""
Auxiliar de validação defensiva do OpenClaw (somente verificações seguras)
- Verifica as suposições de acessibilidade do gateway local
- Verifica os cabeçalhos de resposta e a exposição básica do endpoint
- NÃO explora vulnerabilidades
"""
importar soquete
importar solicitações
from urllib.parse import urljoin
TARGETS = [
("127.0.0.1", 18789),
("localhost", 18789),
]
def is_port_open(host, port, timeout=1.0):
s = socket.socket()
s.settimeout(timeout)
try:
s.connect((host, port))
return True
exceto Exception:
return False
finalmente:
s.close()
def check_http(base_url):
results = []
para path em ["/", "/health", "/api/version"]:
url = urljoin(base_url, path)
try:
r = requests.get(url, timeout=2)
results.append((path, r.status_code, dict(r.headers)))
except Exception as e:
results.append((path, "ERR", str(e)))
retornar resultados
def main():
print("=== Validação defensiva do OpenClaw (seguro) ===")
para host, porta em TARGETS:
open_ = is_port_open(host, port)
print(f"[+] {host}:{port} open={open_}")
if open_:
base = f "http://{host}:{port}"
for item in check_http(base):
print(" ", item)
se __name__ == "__main__":
main()
Esse tipo de script não lhe dirá tudo. No entanto, ele ajudará as equipes a evitar o erro comum de presumir que uma correção foi aplicada quando o serviço vulnerável ainda está em execução em um processo antigo, contêiner ou vinculação de porta alternativa.
O que as equipes de segurança corporativa devem fazer nesta semana
Se o OpenClaw estiver presente em seu ambiente (incluindo shadow IT/dispositivos pessoais conectados a serviços corporativos), a resposta certa não é entrar em pânico. É um sprint de contenção e fortalecimento com escopo e orientado por evidências.
Tabela: Plano de resposta de segurança do OpenClaw para 7 dias
| Dia | Meta | Ações | Evidências a serem coletadas |
|---|---|---|---|
| 1 | Descubra o uso | Levantamento de ativos, busca de EDRs, varreduras de rede para portas/nomes de processos comuns | Lista de hosts, lista de proprietários |
| 2 | Reduzir a exposição | Remova o acesso à Internet, o acesso de administrador somente à VPN, os controles de proxy | Testes de acessibilidade antes/depois |
| 3 | Patch | Atualizar para versões corrigidas, reiniciar serviços | Prova de versão de tempo de execução, registros de implantação |
| 4 | Segredos | Girar chaves/tokens de API, revogar credenciais antigas | Carimbos de data e hora de rotação, registros de uso |
| 5 | Habilidades | Faça um inventário das habilidades/extensões instaladas e remova as não confiáveis | Diferença de inventário de habilidades |
| 6 | Monitoramento | Adicionar detecções para processos filhos de agentes/explosões de saída | Alertas SIEM, linhas de base |
| 7 | Política | Definir o uso aprovado, o modelo de privilégios e o processo de revisão de habilidades | Documento de política + exceções |
Esse tipo de plano de resposta é melhor do que tentar perseguir cada manchete individualmente.
Como isso se conecta à segurança mais ampla de agentes de IA em 2026
O OpenClaw não é a última plataforma de agentes a enfrentar esse tipo de crise de segurança. Ela é simplesmente a primeira grande e rápida o suficiente para tornar o padrão visível.
A lição mais importante é que Os agentes de IA colapsam domínios de confiança anteriormente separados:
- intenção do usuário
- automação executável
- armazenamento secreto
- plug-ins/competências externos
- Registros e depuração de pipelines
- superfícies de controle acionadas por chat
Quando esses domínios convergem em um único processo, as antigas suposições fracassam:
- "É apenas um aplicativo local"
- "É apenas uma ferramenta de navegador"
- "É apenas uma mensagem de registro"
- "é apenas uma habilidade de remarcação"
- "É apenas uma chave de API"
Os recentes avisos e relatórios de incidentes da OpenClaw tornam isso visível de uma forma que os exemplos padrão de aplicativos da Web não fazem. (GitHub)
Se a sua equipe estiver avaliando como operacionalizar as defesas em torno de agentes de IA, o OpenClaw é um bom caso de uso para verificação contínua em vez de cheques únicos.
Uma plataforma como Penligente pode ser útil quando as equipes têm dificuldades:
- testar repetidamente a exposição do plano de controle do agente
- validação da eficácia do patch após os upgrades
- verificação de configurações de risco em vários hosts
- automatização da coleta de evidências para verificação da correção
- manter fluxos de trabalho de teste seguros e repetíveis sem scripts ad hoc
Isso é especialmente relevante quando o risco não é um único CVE, mas uma cadeia de condições (exposição + privilégio + extensão insegura + monitoramento fraco). O valor está menos em "encontrar um bug" e mais em provar se o ambiente ainda está vulnerável após as mudanças operacionais.
A Penligent também publicou várias análises relacionadas ao OpenClaw que podem ser usadas como contexto para que as equipes de segurança criem orientações e treinamentos internos sobre padrões de risco de agentes, incluindo envenenamento de logs/injeção imediata indireta e envenenamento do ecossistema de habilidades. (Penligente)
Conclusão
Os recentes relatos de vários grupos de hackers que exploram instâncias do OpenClaw para roubar chaves de API e implantar malware não são uma anomalia isolada. Eles são o resultado esperado de uma classe de plataforma que combina alto privilégio, adoção rápida, ecossistemas de extensão e limites de segurança em evolução. (Notícias sobre segurança cibernética)
A resposta certa não é declarar que os agentes de IA são "inerentemente inseguros", nem descartar os incidentes como erro do usuário. A resposta certa é amadurecer o modelo operacional:
- reduzir a exposição
- remendo rapidamente
- verificar o comportamento
- minimizar o privilégio
- tratar as habilidades como código executável
- tratar os registros como entrada não confiável
- monitorar as ações do agente como um sinal de segurança de primeira classe
O OpenClaw está forçando o setor a aprender essas lições com antecedência. As equipes que as aprenderem agora estarão muito mais bem preparadas para a próxima geração de ferramentas agênticas, seja ela chamada de OpenClaw ou outra.
Referências
- NVD: CVE-2026-25253 (problema de gateway relacionado a token do OpenClaw / Clawdbot / Moltbot) (NVD)
- NVD: CVE-2026-25593 (gravação de configuração local do WebSocket → injeção de comando como usuário do gateway) (NVD)
- Banco de dados consultivo do GitHub: GHSA-g27f-9qjv-22pm (envenenamento de registro OpenClaw / injeção indireta de prompt via cabeçalhos WebSocket) (GitHub)
- Avisos de segurança do GitHub OpenClaw (fluxo contínuo de avisos) (GitHub)
- Pesquisa da Eye Security sobre envenenamento de registros do OpenClaw e contexto de patches (Pesquisa ocular)
- Hunt.io análise de exposição para instâncias do OpenClaw voltadas para a Internet e contexto CVE-2026-25253 (hunt.io)
- Notícias sobre segurança cibernética: vários grupos de hackers estão explorando instâncias do OpenClaw para roubar chaves de API e implantar malware (Notícias sobre segurança cibernética)
- The Verge: Riscos de malware do ecossistema de habilidades do OpenClaw e implicações da superfície de ataque (The Verge)
- Tom's Hardware: habilidades maliciosas do ClawHub, comportamento de extensão executável e fluxos de configuração de engenharia social (Hardware do Tom)
- Artigo sobre envenenamento de registro OpenClaw / injeção indireta de prompt (corrigido na versão 2026.2.13) (Penligente)
- Envenenamento de habilidades do OpenClaw / "SKILL.md torna-se um instalador" (Penligente)
- Manifesto de segurança do OpenClaw / guia de fortalecimento arquitetônico (Penligente)
- OpenClaw zero-click RCE e passo a passo de injeção indireta (contexto histórico / treinamento interno) (Penligente)
Portuguese 
English 
German 
French 
Spanish 
Japanese 
Korean 
Hindi 
Arabic 
Turkish 
Hebrew