Cadeia de exploração NemoClaw expõe Ollama a acesso não autenticado e altera modelos do chat

O que aconteceu (fatos confirmados) Pesquisadores do Oasis Security publicaram um relatório que descreve uma cadeia de exploração contra a configuração de NemoClaw que pode permitir a um site controlado por um atacante acessar sem autenticação a uma instância local de Ollama e modificar o "chat template" do modelo para inserir instruções ocultas que persistam em conversas posteriores. O Oasis Security afirma que notificou o problema da equipe PSIRT da NVIDIA antes da publicação; não há, segundo o relatório, um identificador CVE, nem um intervalo de versões afetadas nem uma versão modificada assinalada por Oasis. Até 25 de agosto de 2026 não foi relatada exploração em campo.

Como funciona tecnicamente a cadeia de ataque (explicação técnica): O vetor aproveita dois fatos concretos: primeiro, que NemoClaw pode iniciar Ollama com OLLAMA_HOST=0.0.0.0:11434, o que faz com que o serviço de inferência ouça em todas as interfaces em vez de apenas no loopback; segundo, que a API no porto 11434 não exige autenticação e sua proteção contra origens web depende de verificações de Host/Origin e de um proxy tokenizado que, em algumas configurações (especialmente rotas que usam o WSL/Docker Desktop no Windows), não está presente ou não aplica.

Com a API exposta desse modo, um atacante pode servir uma página web que primeiro responde desde seu domínio legítimo e depois, mediante uma técnica deDNS rebinding, faz com que esse domínio resolva 127.0.0.1. O navegador mantém a política de mesma origem (same-origin) e, se o servidor não valida corretamente o Host ou Origin, o navegador enviará pedidos que a API de Ollama aceitará como se fossem da mesma proveniência. Desde lá o pedido a/api/createPode escrever um template Go que modifica como as mensagens estruturados são representadas; o modelo maliciosa pode adicionar texto a cada system message em tempo de inferência, e esta mudança é armazenada a nível de modelo, invisível para clientes posteriores que usam a API.

O que foi confirmado no software: Revisões públicas do repositório de NemoClaw mostram que, na versão de agosto, foi adicionada uma verificação (v0.0.106) que impede de iniciar o proxy local se detectar que o backend Ollama está ligado a uma interface não loopback — mas essa prevenção não cobre todas as rotas de execução. Em particular, a rota Windows-host/Wsl/Docker Desktop usada para aceder ao daemon a partir de contêineres normalmente configurar OLLAMA_HOST=0.0.0.0 para permitir essa acessibilidade, e NemoClaw não arranca o proxy nesses caminhos. Além disso, não foi encontrada nenhuma validação de integridade do modelo de chat que impeça modificações remotas do template.

Consequências práticas: Se a cadeia for reproduzida em uma máquina alvo, um site malicioso simples aberto no navegador do usuário local pode tomar controle do agente Ollama que serve OpenClaw/OpenShell/NemoClaw. As consequências incluem: persistência de instruções maliciosas no comportamento do modelo (manipulação de respostas futuras), execução indireta de ferramentas que o agente tenha conectadas (por exemplo, chamadas a executáveis locais ou APIs de terceiros), exfiltração de dados locais e criação de agentes “sequestrados” que atuem como pivote dentro do ambiente do operador. A exploração não requer que a API seja acessível da rede externa: basta que o navegador do usuário local alcance o porto 11434 em localhost.

O que está confirmado e o que é incerto: Confirmado: a existência do método (binding a 0.0.0.0 + falta de autenticação + DNS rebinding) e que NemoClaw apresenta caminhos de arranque que deixam o daemon acessível em 0.0.0.0 em certas plataformas; confirmado também que uma modificação de modelo pode persistir a nível de modelo. Incerto/estimado: quais navegadores e versões concretas são susceptíveis na prática (o relatório não especifica contra quais navegadores/OS foi verificado a cadeia), e se existe exploração ativa em ambientes reais para além de testes laboratoriais. Também não há uma lista pública de versões afetadas ou um adesivo oficial apontado por Oasis em seu aviso inicial.

Medidas concretas e verificáveis a aplicar pelos operadores(ordenadas por facilidade e impacto):

1) Verificar se a sua instância local de Ollama está a ouvir em 0.0.0.0 e, se for assim, a mudar para o loopback. Em sistemas Linux use, por exemplo:ss - ltnp | grep 11434ounetstat -plnte verifique a coluna “Local Address”. Se ocorrer 0.0.0.0:11434, reconfigure a unidade de serviço para exportarOLLAMA_HOST=127.0.0.1:11434e reinicie o serviço.

2) Bloquear o acesso a 11434 a partir de interfaces de rede não loopback com regras de firewall (por exemplo: iptables/nftáveis ou regras do Windows Firewall) para impedir conexões de LAN ou internet. Isto atenua exposições acidentais mesmo que a variável de ambiente não seja corrigida imediatamente.

3) Rever a configuração do Docker Desktop / WSL2 no Windows: não permita que contentores ou WSL acessem o daemon no host através de host.docker.internal ou por binding público se não for estritamente necessário. Em ambientes onde essa conectividade seja imprescindível, aplique controles adicionais (firewall local, revogar acesso a ferramentas críticas, executar o agente em VM isoladas).

4) Limitar as capacidades do agente: reduz ou desactive as ferramentas e capacidades de chamada a APIs/executáveis que o agente possa invocar. Tente modelos e ambientes como componentes que podem ser comprometidos; não confie no isolamento do sandbox para proteger segredos ou acesso a infra-estruturas críticas.

5) Verificar modelos e modelos após suspeita: consulte a API administrativa (/api/showou outras rotas administrativas documentadas) para detectar alterações em modelos e contexto do modelo. Se detectar modelos inesperados, restaure desde cópia segura ou reentrene/reimplante o modelo e rote credenciais/keys que o agente pudesse usar.

6) Actualizar e seguir publicações do fornecedor: embora o Oasis Security notificou a NVIDIA, a ausência de um CVE ou um sistema claro obriga operadores a seguir tanto o repositório de NemoClaw como as notas de Ollama e a aplicar adesivos ou alterações de configuração recomendadas pelos equipamentos responsáveis. Consulte a documentação oficial do Ollama sobre configuração segura e proteções contra DNS rebinding: https://ollama.com/docs. Para entender a ameaça técnica do DNS rebinding e como mitigar em aplicativos web, ver a documentação do OWASP: https://owasp.org/www-community/attacks/DNS_Rebinding.

Recomendações para usuários finais e desenvolvedores: Usuários: não abrir páginas desconhecidas ou não confiáveis em máquinas onde se desenvolvam ou executem agentes locais; feche páginas desnecessárias e evite executar navegadores com privilégios elevados. Desenvolvedores/operadores: exigir autenticação na API de inferência, validar o header Host no servidor (permitir apenas valores autorizados) e adicionar controlos de integridade sobre modelos de chat e metadados do modelo para que modificações administrativas sejam registadas e revistas. As validações do Host/Origin e a implementação de tokenização/proxy devem funcionar em todas as rotas de implantação, incluindo WSL e ambientes com Docker Desktop.

Contexto adicional e leituras: A técnica de “plantar” instruções manipulando modelos da renderização do prompt foi documentada antes em outros projetos de agentes. Além disso, a mitigação clássica para ataques por DNS rebinding é verificar o Host no servidor e restringir bindings ao loopback, medidas que já foram recomendadas em avisos prévios relacionados com Ollama.

Em resumo: existe uma cadeia plausível e documentada para que um navegador local, por DNS rebinding e uma API de Ollama ligada a 0.0.0.0 sem autenticação, altere modelos de chat e altere o comportamento persistente de um agente. Atuar na configuração de binding, aplicar regras de firewall e limitar capacidades do agente reduz o risco de exploração até que haja um adesivo e indicações oficiais que cubram todas as rotas de implantação.