Falha no NVIDIA NemoClaw pode permitir que páginas maliciosas alterem modelos locais de IA
Pesquisadores da Oasis Security identificaram uma vulnerabilidade no NVIDIA NemoClaw capaz de permitir que uma página controlada por um invasor assuma o controle, sem autenticação, de uma instância local do Ollama. A partir desse acesso, seria possível modificar componentes internos do modelo e inserir instruções ocultas em agentes de inteligência artificial.
O problema foi comunicado ao Product Security Incident Response Team (PSIRT) da NVIDIA, mas ainda não havia recebido um identificador CVE até 25 de agosto de 2026. Também não existem registros públicos de exploração ativa da falha.
De acordo com Elad Luz, chefe de pesquisa da Oasis Security, o NemoClaw v0.0.35 corrigiu o problema nos sistemas macOS e Linux. No entanto, o cenário envolvendo Windows e Windows Subsystem for Linux (WSL) ainda não conta com uma correção equivalente. A versão 0.0.34 havia introduzido o suporte à instalação no Windows, acompanhada de um alerta sobre possíveis limitações de segurança.
Como o NemoClaw expõe o Ollama
O NemoClaw é uma stack de referência aberta desenvolvida pela NVIDIA para executar agentes, incluindo o OpenClaw, dentro de sandboxes OpenShell. A plataforma oferece suporte a mecanismos locais de inferência, entre eles o Ollama, ferramenta amplamente utilizada para rodar modelos de linguagem no próprio computador.
A vulnerabilidade surge em uma configuração que inicia o Ollama com a variável `OLLAMA_HOST=0.0.0.0:11434`. Esse parâmetro faz o serviço escutar em todas as interfaces de rede, em vez de aceitar conexões apenas do próprio dispositivo por meio do endereço de loopback.
Em ambientes macOS e Linux sem WSL, o serviço normalmente permanece vinculado a `127.0.0.1:11434` e é colocado atrás de um proxy reverso protegido por token, disponível na porta 11435. Já no Windows com Docker Desktop e WSL, a arquitetura muda.
Para permitir que contêineres acessem serviços executados no sistema hospedeiro por meio de `host.docker.internal`, o proxy pode ser contornado. Quando o Ollama é executado diretamente no Windows, ele pode ficar disponível em `0.0.0.0:11434`, sem autenticação na API dessa porta.
Essa exposição não significa apenas que outro dispositivo conectado à mesma rede poderia tentar acessar o serviço. A cadeia de ataque descrita pela Oasis Security também pode ser iniciada por uma página maliciosa aberta no navegador da própria vítima.
DNS rebinding facilita o acesso ao serviço local
A API do Ollama, por padrão, não exige autenticação na porta 11434. Para restringir chamadas originadas em navegadores, ela depende de verificações nos cabeçalhos HTTP `Host` e `Origin`, além de mecanismos relacionados ao CORS.
Segundo a análise, quando o servidor está vinculado a um endereço externo, e não exclusivamente ao loopback, a validação do cabeçalho `Host` pode ser ignorada. O controle de origem cruzada também pode aceitar uma solicitação quando os valores de `Origin` e `Host` correspondem ao domínio utilizado pelo invasor.
O ataque pode então recorrer ao DNS rebinding. Primeiro, o domínio controlado pelo invasor aponta para um servidor externo. Depois de algum tempo, a resolução DNS é alterada para `127.0.0.1`, fazendo com que o mesmo domínio passe a direcionar chamadas para serviços locais da máquina da vítima.
Como o navegador mantém a mesma origem durante o processo, uma página maliciosa pode tentar enviar requisições ao Ollama sem que o usuário perceba. A técnica foi testada pela Oasis Security no macOS, usando o Firefox e uma versão vulnerável do NemoClaw.
Ataques semelhantes contra a API do Ollama já haviam sido documentados. Em março de 2024, o Ollama lançou a versão 0.1.29 para corrigir a vulnerabilidade CVE-2024-28224, associada à validação inadequada do cabeçalho `Host`. Luz explica que o risco volta a aparecer nesse contexto porque a validação deixa de ser aplicada da mesma forma quando o serviço está associado a um endereço que não é de loopback.
Modelo pode receber instruções ocultas e persistentes
Depois de alcançar a API, o método demonstrado pelos pesquisadores utiliza o endpoint `/api/create` para criar ou modificar um template de conversa.
Esse template define como mensagens estruturadas são transformadas em texto antes de serem encaminhadas ao modelo. Ao adulterá-lo, o invasor pode inserir instruções adicionais nas mensagens de sistema usadas em cada inferência.
O efeito é especialmente perigoso porque as instruções podem continuar presentes em conversas futuras, mesmo quando o agente envia seu próprio system prompt. Para a aplicação que consome o modelo, a manipulação pode permanecer invisível: o template é armazenado como uma propriedade do modelo e não necessariamente aparece nas mensagens recebidas pelo cliente.
Na prática, o atacante não precisa alterar todos os prompts enviados pelo usuário. Basta modificar a camada responsável por formatar as solicitações para que determinada orientação seja incorporada automaticamente durante o processamento.
Impacto para agentes executados em sandbox
O uso de sandboxes reduz parte do risco, mas não elimina a possibilidade de abuso. O ambiente continua limitando o acesso a determinados recursos, porém um agente comprometido ainda pode utilizar ferramentas, arquivos, comandos ou integrações que já estejam autorizados dentro daquele espaço.
O impacto depende diretamente das permissões concedidas ao agente. Se ele tiver acesso a sistemas internos, arquivos de projeto, credenciais temporárias ou ferramentas de automação, as instruções inseridas no template poderão orientá-lo a realizar ações indevidas.
Esse tipo de comprometimento também pode ser difícil de identificar por meio de logs convencionais. As requisições do usuário podem parecer normais, enquanto o comportamento alterado ocorre dentro do próprio modelo ou durante a preparação do prompt.
Proteções adicionadas nas versões mais recentes
Uma análise do repositório do NemoClaw realizada em 25 de agosto identificou uma proteção adicional incorporada por padrão na versão 0.0.106, disponibilizada em 10 de agosto. O proxy local do Ollama passou a impedir a inicialização quando detecta que o serviço está configurado de maneira potencialmente exposta.
Apesar disso, a existência dessa barreira não deve ser interpretada como substituta para atualizações e configurações seguras. Ambientes que utilizam versões antigas, instalações personalizadas ou o caminho específico do Windows podem continuar vulneráveis.
A recomendação mais importante é atualizar o NemoClaw para uma versão corrigida e verificar se o componente utilizado no Windows ou no WSL recebeu um ajuste equivalente. Também é necessário atualizar o Ollama e evitar configurações que façam o serviço escutar em todas as interfaces.
Medidas para reduzir o risco
Administradores devem restringir o Ollama ao endereço `127.0.0.1` sempre que não houver necessidade real de acesso externo. A porta 11434 não deve ser exposta diretamente à rede local ou à internet, e regras de firewall podem impedir conexões não autorizadas.
Também é recomendável evitar a execução de páginas desconhecidas enquanto ferramentas de IA locais estiverem ativas. Embora essa medida não resolva a falha de configuração, ela reduz a possibilidade de uma página maliciosa explorar serviços acessíveis pelo navegador.
Templates de modelos devem ser tratados como componentes sensíveis. Alterações inesperadas nos templates, nos metadados dos modelos e nas configurações do Ollama precisam ser auditadas. Modelos usados em ambientes produtivos devem ser recriados a partir de fontes confiáveis sempre que houver suspeita de adulteração.
Por fim, equipes que utilizam agentes autônomos devem aplicar o princípio do menor privilégio. Limitar o acesso a arquivos, comandos, rede e credenciais reduz o impacto caso o modelo receba instruções maliciosas. A segurança do agente depende não apenas do modelo, mas também da forma como a infraestrutura local está exposta e das permissões concedidas ao sistema.