O Contexto: O "Pesadelo de Segurança" Que Forçou Esta Release
A história é simples e preocupante: quando o projecto mudou de Clawd Bot para Molt Bot e depois para Open Claw em menos de uma semana, milhares de novos utilizadores — muitos sem experiência técnica — instalaram o agente seguindo tutoriais desactualizados. O resultado foi uma vaga de instâncias expostas à internet sem qualquer autenticação.
A CrowdStrike documentou inúmeras instalações públicas com gateways acessíveis via HTTP não encriptado, expondo API keys, tokens OAuth e históricos completos de conversas. A JFrog alertou que dar a um agente autónomo "god mode" numa máquina local cria uma superfície de ataque inaceitável. E análises da Hostinger confirmaram que credenciais em texto plano estavam acessíveis através de endpoints mal configurados.
O problema agravou-se com a vulnerabilidade CVE-2026-25253 (CVSS 8.8) — a falha de "1-Click RCE" que permitia execução remota de código com uma única visita a uma página maliciosa. E com a descoberta de 341 skills maliciosas no ClawHub, ficou evidente que a segurança do ecossistema precisava de uma revisão profunda.
A v2026.2.12 é essa revisão.
O Que Muda: Mais de 40 Correcções de Segurança
Segundo as release notes oficiais no GitHub e análises do CyberSecurity News, esta não é uma actualização incremental. É uma reformulação da postura de segurança do projecto, seguindo uma filosofia de defesa em profundidade ("defense-in-depth") que toca em hooks, controlo do browser, scheduling, canais de mensagens e — acima de tudo — o Gateway.
Eis as sete áreas críticas:
1. Autenticação Obrigatória no Gateway
Até à v2026.2.12, era possível correr o Gateway com auth: "none" — sem qualquer protecção. Essa opção foi permanentemente eliminada. Agora, se não configurares credenciais, o sistema gera automaticamente um token seguro (gateway.auth.token) durante o arranque. As rotas HTTP de controlo do browser em loopback passam a exigir autenticação, e uma nova verificação de auditoria ("security-audit check") alerta para qualquer controlo de browser sem autenticação. PR #13787.
2. Protecção SSRF no Gateway e OpenResponses
O Gateway e o módulo OpenResponses agora aplicam uma política de negação estrita contra SSRF (Server-Side Request Forgery) para pedidos input_file e input_image baseados em URL. Isto inclui allowlists de hostnames (files.urlAllowlist / images.urlAllowlist), limites de URLs por pedido (maxUrlParts) e logging de auditoria para tentativas bloqueadas. Na prática: um atacante já não pode usar o teu agente para sondar ou fazer scanning da tua rede interna.
3. Redacção de Credenciais nos Logs
Um bug crítico na v2026.2.6 fez com que o comando openclaw configure substituísse valores reais de API keys por __OPENCLAW_REDACTED__ no ficheiro de configuração em disco — destruindo credenciais do Discord, DeepSeek, Brave e outros serviços. A v2026.2.12 corrige a redacção para que funcione apenas nos logs e respostas de API (/config), nunca no ficheiro de configuração real. Campos como maxTokens também deixam de ser incorrectamente redactados (#14006).
4. Isolamento de Conteúdo Web (Anti-Prompt Injection)
Os outputs do browser e de ferramentas web são agora tratados como dados não-confiáveis por defeito. Snapshots do browser, dados de tabs e console são encapsulados em metadados estruturados e limpos antes de chegarem ao modelo. Além disso, o campo toolResult.details é removido dos transcripts visíveis ao modelo, mitigando ataques de prompt injection por replay.
5. Remoção do Hook "soul-evil"
Talvez a descoberta mais inquietante desta release: um hook bundled identificado como soul-evil foi encontrado e removido do código-fonte (PR #14757). Embora os detalhes sejam escassos, a sua eliminação sugere que um componente potencialmente malicioso — ou no mínimo perigoso — tinha permanecido inadvertidamente na base de código. A equipa não emitiu um advisory formal sobre a natureza exacta deste hook.
6. Segurança de Sessões e Paths
A resolução de caminhos nos transcripts foi endurecida: session IDs e file paths inseguros são agora rejeitados, garantindo que operações de sessão permanecem confinadas aos directórios de sessão do agente. Caminhos de ficheiros locais em linhas MEDIA: são removidos em vez de expostos como texto visível (#14399). Skills sincronizadas por mirror ficam confinadas ao directório raiz skills/ da sandbox.
7. Autenticação de Webhooks e Throttling
A verificação de segredos em webhooks e tokens de dispositivo passou a usar comparação em tempo constante ("constant-time comparison"), eliminando vulnerabilidades de timing attack. Adicionalmente, foi implementado throttling por cliente com respostas 429 e headers Retry-After para tentativas falhadas de autenticação. Uma vulnerabilidade de bypass de autenticação no BlueBubbles via loopback proxy trust também foi corrigida (#13787).
Breaking Change: Routing de Session Keys em Hooks
Esta actualização inclui uma breaking change importante que pode afectar a tua configuração se usas hooks personalizados:
O endpoint POST /hooks/agent deixa de aceitar overrides de sessionKey no payload por defeito. Se a tua integração depende deste comportamento, tens duas opções:
- Configurar
hooks.defaultSessionKeyehooks.allowedSessionKeyPrefixes(recomendado:["hook:"]) - Activar explicitamente o comportamento legacy com
hooks.allowRequestSessionKey: true(não recomendado para produção)
Esta alteração previne que payloads maliciosos em hooks possam sequestrar sessões de outros utilizadores ou agentes.
Guia Prático: Configurar o Gateway com Segurança
Com base na documentação oficial de segurança e nas novas protecções da v2026.2.12, aqui fica o guia para blindar o teu Gateway:
Passo 1: Actualizar para a v2026.2.12
# Via git
cd ~/openclaw
git pull origin main
git checkout v2026.2.12
# Via Docker
docker pull openclaw/openclaw:v2026.2.12
docker-compose up -d
Passo 2: Configurar Autenticação por Token
O modo recomendado é autenticação por token. Se já correste o onboarding wizard, o token foi gerado automaticamente. Se não, configura manualmente:
{
"gateway": {
"bind": "loopback",
"auth": {
"mode": "token",
"token": "um-token-longo-e-aleatorio-aqui"
}
}
}
openssl rand -hex 32
Passo 3: Manter o Bind em Loopback
O modo loopback (por defeito) significa que apenas clientes locais podem ligar-se ao Gateway. Os modos alternativos expandem a superfície de ataque:
"loopback"— Apenas localhost. A opção mais segura."tailnet"— Acesso via Tailscale. Aceitável se precisas de acesso remoto."lan"— Rede local. Maior risco. Usa apenas com firewall e token forte."custom"— Bind manual. Perigoso se mal configurado.
Se precisas de acesso remoto, a documentação oficial recomenda Tailscale Serve em vez de expor o gateway directamente na LAN.
Passo 4: Configurar Allowlists SSRF
As novas allowlists de URLs permitem controlar exactamente quais domínios o teu agente pode aceder para ficheiros e imagens:
{
"files": {
"urlAllowlist": ["github.com", "raw.githubusercontent.com"]
},
"images": {
"urlAllowlist": ["i.imgur.com", "pbs.twimg.com"]
}
}
Passo 5: Correr a Auditoria de Segurança
Após configurar, corre a auditoria integrada:
# Auditoria básica
openclaw security audit
# Auditoria profunda (recomendada)
openclaw security audit --deep
# Correcção automática de problemas encontrados
openclaw security audit --fix
A flag --fix endurece automaticamente permissões de ficheiros (~/.openclaw para 700, ficheiros de configuração para 600), converte políticas abertas em allowlists e activa a redacção de dados sensíveis se estiver desactivada.
A auditoria verifica:
- Políticas de acesso de DMs e grupos (allowlists)
- Raio de impacto de ferramentas com salas abertas
- Exposição de rede (bind, autenticação, força do token)
- Controlo remoto de browser exposto
- Permissões de ficheiros e higiene do disco local
- Allowlists de plugins e skills
- Desvio de configuração ("policy drift")
Passo 6: Proteger Credenciais
O OpenClaw armazena credenciais em vários locais no disco. Mantém a redacção de logs activa (é o defeito na v2026.2.12):
{
"logging": {
"redactSensitive": "tools",
"redactPatterns": ["sk-ant-.*", "sk-proj-.*"]
}
}
O campo redactPatterns aceita padrões regex adicionais para tokens específicos do teu ambiente — como chaves internas, hostnames ou URLs privados.
Para uma segurança robusta, a recomendação é armazenar API keys como variáveis de ambiente em vez de no ficheiro de configuração, evitando que sejam escritas em disco ou incluídas acidentalmente em backups ou sistemas de controlo de versão.
Outras Melhorias Relevantes
- WebSocket suporta imagens até 5 MB — o limite de payload foi aumentado para acomodar anexos de imagem maiores (#14486)
- Draining seguro no restart — o Gateway agora drena sessões activas antes de reiniciar, prevenindo perda de mensagens (#13931)
- Anti-loop no launchd — a geração automática de tokens de autenticação previne ciclos de restart em sistemas macOS
- 9 hooks de plugins ligados — hooks de ciclo de vida de plugins que estavam desligados foram finalmente conectados ao runtime (#14882)
- Scheduler de cron robusto — prevenção de execuções duplicadas, isolamento de erros e gestão correcta de sessões e modelos
- Nostr corrigido — vulnerabilidade de manipulação remota não-autenticada de perfil Nostr corrigida (#13719)
Resposta a Incidentes: O Que Fazer Se Suspeitares de Compromisso
Se correste o OpenClaw antes desta actualização com o Gateway exposto ou sem autenticação, segue estes passos pela ordem indicada:
1. Pára imediatamente o Gateway ou desactiva ferramentas com permissões elevadas
2. Bloqueia superfícies de entrada — configura políticas de DM para "pairing" e exige menções em grupos
3. Roda todos os segredos — token do gateway, API keys de providers (Anthropic, OpenAI, etc.), tokens de integração
4. Revê transcripts e logs à procura de actividade inesperada ou comandos não-reconhecidos
5. Corre openclaw security audit --deep e confirma que todos os testes passam
Perguntas Frequentes (FAQ)
Preciso de actualizar se só uso o OpenClaw em localhost?
Sim. Mesmo em localhost, a vulnerabilidade CVE-2026-25253 (corrigida na v2026.1.29) provou que um atacante pode explorar o Gateway através do browser da vítima via CSWSH. A v2026.2.12 adiciona camadas adicionais de protecção — incluindo autenticação nas rotas de controlo do browser em loopback — que não existiam antes.
O que é o hook "soul-evil" que foi removido?
Os detalhes são escassos. O PR #14757 removeu um hook bundled identificado como soul-evil sem que a equipa tenha emitido um advisory formal explicando a sua origem ou funcionalidade exacta. A comunidade especula que poderia ser um componente experimental que foi incluído por erro ou um vector de exploração que permaneceu despercebido. Independentemente da causa, a sua remoção é uma correcção de segurança por precaução.
O bug de redacção destruiu as minhas API keys?
Se correste openclaw configure na v2026.2.6-3, é possível que os valores reais das tuas API keys tenham sido substituídos por __OPENCLAW_REDACTED__ no ficheiro de configuração. Verifica o teu config.json manualmente. Se encontrares placeholders em vez de chaves reais, terás de reintroduzir as credenciais. A v2026.2.12 corrige este comportamento para que a redacção nunca altere o ficheiro em disco.
A v2026.2.12 protege contra prompt injection?
Parcialmente. Os outputs de ferramentas web e browser são agora tratados como dados não-confiáveis e encapsulados antes de chegar ao modelo. Isto mitiga ataques de replay e injecção via resultados de ferramentas. No entanto, a prompt injection continua a ser um problema fundamental de LLMs que nenhuma actualização resolve completamente. Consulta o nosso guia sobre prompt injection para defesas em profundidade.
Como sei se o meu Gateway estava exposto?
Corre openclaw security audit --deep. A auditoria verifica exposição de rede, estado de autenticação e força do token. Se o resultado indicar problemas, segue o procedimento de resposta a incidentes descrito neste artigo. Além disso, revê os logs do Gateway à procura de conexões WebSocket de IPs desconhecidos.
🔒 Resumo: Actualiza e Audita Agora
A v2026.2.12 elimina a possibilidade de gateways sem autenticação, endurece protecções contra SSRF e prompt injection, corrige a redacção de credenciais e remove componentes suspeitos. Não é opcional — é a linha de base para uma instalação segura.