Uma falha de segurança na integração entre o NVIDIA NemoClaw e o Ollama pode permitir que uma página web maliciosa alcance um servidor de IA executado localmente e altere o comportamento de modelos sem que o usuário perceba. O ataque combina DNS rebinding com uma configuração de rede que pode deixar a API do Ollama acessível além da interface local.
A descoberta, apresentada pela Oasis Security, mostra um cenário preocupante para quem utiliza LLMs locais e agentes de IA. Após obter acesso à API, um invasor pode explorar o endpoint /api/create para modificar o template associado ao modelo e inserir instruções ocultas que permanecem ativas nas interações seguintes.
O caso demonstra que executar inteligência artificial localmente não elimina os riscos de segurança. À medida que ferramentas como NemoClaw e Ollama passam a integrar agentes autônomos com acesso a arquivos, comandos e outros recursos do sistema, uma configuração de rede aparentemente simples pode se transformar em uma porta de entrada para ataques persistentes.
Como funciona a falha no NVIDIA NemoClaw e no Ollama
O NVIDIA NemoClaw utiliza o Ollama como uma das opções para executar modelos localmente. Em determinadas configurações, o ambiente define a variável OLLAMA_HOST=0.0.0.0:11434.
Essa configuração faz o daemon do Ollama escutar em todas as interfaces de rede, em vez de aceitar conexões somente pelo endereço de loopback, como 127.0.0.1.
Essa diferença é fundamental para entender o ataque.
Quando um serviço está restrito ao loopback, aplicações externas não conseguem alcançá-lo diretamente pela rede. Ao utilizar 0.0.0.0, entretanto, o serviço pode ficar acessível por outras interfaces, dependendo da configuração do sistema, firewall, Docker, WSL ou rede local.
O problema se torna ainda mais sério porque a API do Ollama não exige autenticação por padrão. Assim, uma aplicação capaz de alcançar o serviço pode potencialmente executar operações que deveriam estar disponíveis apenas para aplicações confiáveis.
O papel do DNS rebinding no ataque
O DNS rebinding é a técnica utilizada para transformar uma página web em uma ponte até um serviço local.
Normalmente, um navegador impede que uma página hospedada em determinado domínio interaja livremente com serviços pertencentes a outra origem. Essa proteção faz parte do modelo de segurança conhecido como Same-Origin Policy.
O DNS rebinding tenta contornar essa separação.
Um domínio controlado pelo atacante pode inicialmente resolver para um endereço externo e, posteriormente, passar a resolver para um endereço interno ou local. Com isso, o navegador continua acreditando estar falando com o mesmo domínio, enquanto a conexão acaba chegando a um serviço executado na máquina da vítima.
No caso analisado pela Oasis Security, a combinação entre o DNS rebinding e a exposição do Ollama cria uma situação em que uma página maliciosa pode alcançar a API local.
O ataque é especialmente preocupante porque não depende necessariamente da instalação de malware tradicional. A vítima pode simplesmente acessar uma página comprometida ou criada especificamente para executar a cadeia de ataque.
Como o modelo de IA pode ser envenenado
Depois de alcançar a API do Ollama, o atacante pode explorar uma característica muito mais perigosa do que simplesmente consultar um modelo.
O endpoint /api/create permite criar modelos e definir elementos como o template utilizado para processar as mensagens enviadas ao LLM.
Esse template determina como diferentes componentes da conversa são organizados antes de serem encaminhados ao modelo. Portanto, alterar esse componente pode mudar o comportamento do sistema de maneira persistente.
Em vez de enviar apenas um prompt malicioso durante uma única conversa, o atacante pode inserir instruções ocultas diretamente no template do modelo.
O resultado é uma forma de envenenamento persistente do modelo.
A instrução adicionada pode continuar sendo aplicada mesmo depois que a página maliciosa for fechada. O usuário pode iniciar uma nova conversa acreditando estar utilizando o modelo original, enquanto o template modificado continua introduzindo conteúdo controlado pelo invasor.
Esse detalhe diferencia o ataque de um simples prompt injection.
No prompt injection tradicional, a instrução maliciosa geralmente está associada a uma entrada específica. Nesse cenário, a alteração do template pode permanecer incorporada à configuração do modelo e afetar várias sessões.
Para agentes autônomos, o impacto potencial é ainda maior.
Um LLM que apenas responde perguntas pode apresentar resultados manipulados. Já um agente com acesso a arquivos, terminal, ferramentas externas ou dados corporativos pode interpretar essas instruções como parte de seu comportamento operacional.
Isso transforma uma alteração aparentemente invisível no modelo em um possível vetor para ações indesejadas.
Impacto da falha no Linux, macOS e Windows com WSL
O impacto não é exatamente igual em todas as plataformas. A forma como NemoClaw, Ollama, Docker e o sistema operacional se comunicam influencia diretamente a exposição.
Linux e macOS recebem uma abordagem mais segura
Nas versões mais recentes do NemoClaw, a NVIDIA modificou o caminho utilizado para inferência local em ambientes nativos.
A recomendação atual é manter o Ollama ligado ao 127.0.0.1:11434, evitando sua exposição direta. O NemoClaw pode então utilizar um proxy reverso protegido por token para intermediar a comunicação necessária com o sandbox.
Essa arquitetura reduz significativamente a superfície de ataque.
Em vez de disponibilizar diretamente uma API sem autenticação em todas as interfaces, o serviço de inferência permanece limitado à máquina local e o componente intermediário controla quem pode acessá-lo.
Por isso, usuários de Linux e macOS devem atualizar o NemoClaw e conferir se a instalação utiliza o mecanismo de acesso protegido disponibilizado nas versões recentes.
WSL e Windows exigem atenção adicional
O cenário é mais complexo no Windows utilizando WSL2.
Nesse ambiente, o Ollama pode estar instalado diretamente no Windows enquanto o NemoClaw é executado dentro do ambiente Linux fornecido pelo WSL. Para permitir essa comunicação, determinadas configurações podem exigir que o Ollama seja iniciado com OLLAMA_HOST=0.0.0.0:11434.
Isso mantém justamente o tipo de exposição que torna a cadeia de ataque possível.
Portanto, atualizar componentes individualmente não é suficiente. Usuários de Windows e WSL precisam verificar como o Ollama está sendo exposto e como o sandbox do NemoClaw consegue alcançar o serviço.
Esse é um dos pontos mais importantes da investigação: a mesma configuração pode ser necessária para a comunicação entre componentes em uma plataforma e, ao mesmo tempo, aumentar a superfície de ataque.
Como proteger seu ambiente com Ollama e NemoClaw
A primeira recomendação é atualizar o NemoClaw e utilizar as versões mais recentes disponibilizadas pela NVIDIA.
Também é fundamental verificar o endereço utilizado pelo Ollama. Sempre que não houver necessidade de acesso externo, o ideal é manter o serviço limitado ao loopback, em vez de utilizar 0.0.0.0.
Usuários Linux podem verificar as interfaces nas quais o serviço está escutando utilizando ferramentas como ss. No Windows e WSL, ferramentas de rede equivalentes podem revelar se a porta 11434 está exposta além do ambiente necessário.
Outra medida importante é revisar firewalls e regras de rede. A porta utilizada pelo Ollama não deve ficar acessível desnecessariamente por outras máquinas ou interfaces.
Também vale revisar os modelos instalados caso exista suspeita de comprometimento. Alterações inesperadas em templates, modelos ou configurações de inferência devem ser tratadas com cautela.
Em um ambiente potencialmente comprometido, recriar o modelo a partir de uma fonte confiável pode ser mais seguro do que simplesmente continuar utilizando uma instalação cuja integridade não pode ser confirmada.
A segurança de modelos locais também precisa evoluir
O caso envolvendo NVIDIA NemoClaw e Ollama mostra que a segurança da inteligência artificial local não termina no sandbox.
Um agente pode estar isolado do sistema operacional e ainda assim depender de um serviço de inferência que esteja excessivamente exposto. Da mesma forma, um modelo baixado de uma fonte confiável pode ter seu comportamento alterado posteriormente por meio de componentes da infraestrutura que o executa.
A principal lição é simples: serviço local não significa serviço automaticamente protegido.
Quem utiliza NemoClaw, Ollama ou outros servidores de LLM deve revisar regularmente bindings de rede, autenticação, permissões, firewall e integridade dos modelos.
Para usuários de Linux, desenvolvedores, administradores e profissionais de segurança, essa investigação também reforça uma tendência importante: conforme os agentes de IA ganham mais autonomia, a proteção do modelo precisa ser tratada como parte da segurança da própria infraestrutura.
