Oasis Security ha scoperto una falla in NVIDIA NemoClaw che consente a siti web malevoli di prendere il controllo non autenticato dell'agente AI Ollama locale e iniettare istruzioni occulte nel modello, mettendo a rischio l'inferenza AI.
Una nuova vulnerabilità individuata da Oasis Security in NVIDIA NemoClaw mette a rischio la sicurezza dei modelli AI locali: un sito web controllato da un attaccante può assumere il controllo non autenticato dell'istanza Ollama locale e inserire istruzioni nascoste direttamente nel modello. La segnalazione, anticipata a The Hacker News, è stata comunicata preventivamente anche al Product Security Incident Response Team (PSIRT) di NVIDIA. Al momento, la vulnerabilità non ha un identificativo CVE e non risultano casi di sfruttamento noti al 25 agosto 2026.
Secondo Elad Luz, responsabile della ricerca di Oasis Security, la versione NemoClaw v0.0.35 ha risolto il problema su macOS e Linux, mentre su Windows e WSL la falla persiste: la v0.0.34 introduce solo un avviso per l'installazione su Windows, senza una correzione effettiva.
Come funziona l'attacco e quali sono i rischi reali
NemoClaw è la reference stack open source di NVIDIA per l'esecuzione di agenti come OpenClaw all'interno dei sandbox OpenShell, con Ollama tra i backend di inferenza supportati. Il problema nasce dal fatto che NemoClaw avvia Ollama con la variabile OLLAMA_HOST=0.0.0.0:11434, esponendo l'API su tutte le interfacce di rete. Questo consente a un attaccante di modificare il template di chat del modello, facendo sì che istruzioni occulte vengano applicate a tutte le conversazioni successive.
La protezione tramite sandbox limita l'accesso all'endpoint, ma se l'agente viene compromesso, anche i suoi strumenti e permessi lo sono. La gestione di Ollama da parte di NemoClaw varia a seconda della piattaforma: su host non-WSL, Ollama resta su 127.0.0.1:11434 dietro un reverse proxy con autenticazione; su Docker Desktop in WSL il proxy viene saltato; su Windows, invece, Ollama viene esposto su 0.0.0.0:11434 senza autenticazione.
L'API di Ollama su questa porta non prevede autenticazione e si affida a due livelli di middleware per bloccare richieste dal browser. Tuttavia, se l'indirizzo di bind non è loopback, il controllo sull'header Host viene saltato e la CORS layer considera la richiesta come same-origin, permettendo l'accesso. Un attacco di DNS rebinding consente così a un sito malevolo di far puntare il proprio dominio prima a un server esterno e poi a 127.0.0.1, aggirando le protezioni del browser.
Correzioni, limiti e precedenti simili
La verifica degli header Host e Origin è la soluzione standard per questa tipologia di attacco. Ollama ha già affrontato un problema simile, risolto nella versione v0.1.29 del 14 marzo 2024 e documentato come CVE-2024-28224, con la raccomandazione di validare l'header Host lato server. Tuttavia, secondo Luz, Ollama salta questa validazione quando è bindato su un indirizzo non-loopback, come avviene proprio con la configurazione di NemoClaw.
Una volta raggiunta l'API, il payload dell'attaccante può scrivere un template Go modificato tramite /api/create, alterando la generazione dei messaggi e inserendo testo controllato in ogni system message durante l'inferenza. Queste istruzioni persistono anche nelle conversazioni future e non sono visibili ai client API.
Un'analisi del repository NemoClaw al commit 17f0ca3b mostra che dalla versione v0.0.106 il proxy locale di Ollama si rifiuta di avviarsi se il backend non è bindato su loopback, ma questa protezione non si applica ai percorsi WSL e Windows, dove la vulnerabilità resta attiva. Inoltre, non esiste alcun controllo di integrità sui template di chat.
La documentazione NVIDIA raccomanda di non esporre la porta 11434 su LAN o Internet, ma questa misura non protegge dal rebinding, dato che il browser opera già in locale. Tecniche simili di avvelenamento dei template sono già state documentate, come illustrato anche in un approfondimento su come i prompt infetti si diffondano tra agenti AI.
Implicazioni per utenti e operatori
La vulnerabilità evidenzia come la configurazione predefinita e la mancanza di controlli robusti sugli endpoint locali possano esporre anche sistemi AI privati a rischi di compromissione. Gli operatori che utilizzano NemoClaw su Windows o WSL dovrebbero prestare particolare attenzione e valutare misure di mitigazione aggiuntive, in attesa di una correzione ufficiale.
