Falha no NVIDIA NemoClaw pode permitir que site malicioso envenene modelo de IA local

Pesquisadores da Oasis Security divulgaram uma vulnerabilidade no NVIDIA NemoClaw que pode permitir que uma página controlada por um invasor assuma, sem autenticação, o controle de uma instância local do Ollama usada por um agente de inteligência artificial e insira instruções ocultas diretamente no modelo.

A falha foi reportada previamente ao Product Security Incident Response Team (PSIRT) da NVIDIA e, até 25 de agosto de 2026, não recebeu um identificador CVE. Também não há relatos de exploração ativa.

Segundo Elad Luz, chefe de pesquisa da Oasis Security, o NemoClaw v0.0.35 corrigiu o problema no macOS e Linux. O caminho utilizado no Windows e Windows Subsystem for Linux (WSL), porém, permanece sem uma correção equivalente. A versão 0.0.34 adicionou suporte à instalação no Windows acompanhado de um aviso sobre a configuração.

O NemoClaw é uma stack de referência de código aberto da NVIDIA para executar agentes, como o OpenClaw, dentro de sandboxes OpenShell. Entre os mecanismos suportados para execução local dos modelos está o Ollama.

Ollama exposto abre caminho para o ataque

A pesquisa descreve uma configuração na qual o NemoClaw inicia o Ollama com OLLAMA_HOST=0.0.0.0:11434. Em vez de restringir o serviço ao próprio computador, essa configuração faz com que o servidor do modelo escute em todas as interfaces de rede.

O comportamento varia de acordo com a plataforma. Em sistemas que não utilizam WSL, o Ollama permanece em 127.0.0.1:11434 e é colocado atrás de um proxy reverso protegido por token na porta 11435.

No Windows com Docker Desktop e WSL, a arquitetura é diferente. O proxy pode ser ignorado para permitir que containers alcancem o serviço do host por meio de host.docker.internal. No caminho em que o Ollama é executado diretamente no Windows, a configuração utiliza 0.0.0.0:11434, sem exigir autenticação na API exposta nessa porta.

O risco não está limitado a um invasor tentando acessar diretamente o serviço pela rede. A cadeia descrita pelos pesquisadores utiliza uma página maliciosa aberta no navegador da própria vítima.

DNS rebinding permite alcançar o serviço local

A API do Ollama na porta 11434 não utiliza autenticação e depende de verificações relacionadas aos cabeçalhos Host e Origin para limitar requisições provenientes de navegadores.

Segundo a análise, quando o serviço não está restrito ao endereço de loopback, a validação do cabeçalho Host pode ser ignorada. O controle de Cross-Origin Resource Sharing (CORS) também pode aceitar a requisição quando Origin e Host correspondem ao domínio controlado pelo atacante.

A etapa seguinte utiliza uma técnica conhecida como DNS rebinding. Nela, o domínio do invasor inicialmente aponta para o servidor malicioso e depois passa a resolver para 127.0.0.1, endereço que representa o próprio computador da vítima. O navegador, entretanto, continua tratando as requisições como pertencentes à mesma origem.

Luz afirmou que a cadeia completa foi testada no macOS com Firefox contra uma versão vulnerável do NemoClaw.

Ataques de DNS rebinding contra a API do Ollama já haviam sido documentados anteriormente. O Ollama lançou uma correção na versão 0.1.29, em março de 2024, para a vulnerabilidade CVE-2024-28224, relacionada à validação inadequada do cabeçalho Host.

De acordo com Luz, o problema reaparece neste cenário porque o Ollama deixa de aplicar essa validação quando está associado a um endereço que não seja loopback — justamente o comportamento provocado pela configuração com 0.0.0.0.

Invasor pode inserir instruções persistentes no modelo

Após alcançar a API, a cadeia apresentada pela Oasis Security utiliza o endpoint /api/create para gravar um template de chat modificado.

O template determina como mensagens estruturadas são convertidas em texto antes de serem processadas pelo modelo. Ao alterar esse componente, um atacante pode acrescentar instruções próprias às mensagens de sistema durante cada inferência.

Segundo os pesquisadores, essas instruções permanecem nas conversas posteriores e continuam sendo aplicadas mesmo quando o agente fornece seu próprio system prompt.

Isso torna o comprometimento particularmente relevante para agentes de IA. O usuário ou aplicação que consome o modelo pela API pode não perceber a alteração porque o template é uma propriedade do próprio modelo e não fica diretamente visível para o cliente.

Na prática, o sandbox continua protegendo determinados recursos do endpoint, mas um agente comprometido pode utilizar as ferramentas e permissões que já possui dentro dos limites concedidos ao ambiente.

Proteções atuais não cobrem todos os cenários

Uma análise do repositório do NemoClaw realizada pelo The Hacker News em 25 de agosto encontrou uma proteção adicional introduzida como padrão na versão 0.0.106, em 10 de agosto.

O proxy local do Ollama passou a se recusar a iniciar quando detecta que o backend está associado a uma interface que não seja loopback. O objetivo é impedir que uma instância acessível externamente contorne a autenticação por token fornecida pelo proxy.

Essa proteção, entretanto, pode ser desativada por meio da variável NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1. Além disso, o mecanismo está dentro do próprio proxy, que não é iniciado em determinados caminhos envolvendo WSL e Windows.

A análise também não encontrou no repositório um mecanismo destinado especificamente a verificar a integridade dos templates de chat dos modelos.

A documentação da NVIDIA recomenda que usuários da configuração para Windows não exponham a porta 11434 à rede local ou à internet. Essa medida reduz o acesso direto pela rede, mas não necessariamente impede o cenário de DNS rebinding descrito pelos pesquisadores, pois as requisições são realizadas pelo navegador executado no próprio computador.

A técnica de modificar templates para inserir instruções persistentes em modelos já foi descrita em pesquisas anteriores como "poisoned chat templates". A Oasis Security também documentou abordagens semelhantes envolvendo o Paperclip e agentes locais OpenClaw.