Una pagina web ostile pu� prendere il controllo dell’istanza Ollama che alimenta un agente locale e riscrivere il modo in cui il modello riceve i messaggi, lasciando istruzioni nascoste che restano attive in tutte le conversazioni successive. Il problema riguarda NemoClaw, lo stack di riferimento open source con cui NVIDIA fa girare agenti come OpenClaw dentro le sandbox OpenShell. Oasis Security ha ricostruito la catena e non serve alcuna credenziale per percorrerla: l’API che governa i modelli locali risponde senza autenticazione a chiunque riesca a raggiungerla dal browser della vittima.
La ricerca non ha ricevuto un identificativo CVE ed � stata segnalata prima della pubblicazione al PSIRT di NVIDIA, la squadra che gestisce gli incidenti di sicurezza sui prodotti. Al 25 agosto 2026 non risultano casi di sfruttamento. Elad Luz, responsabile della ricerca di Oasis Security, indica la v0.0.35 come la versione che corregge il problema su macOS e Linux, mentre sul percorso Windows e WSL una correzione non c’�: la v0.0.34 aveva aggiunto un’installazione per Windows accompagnata da un avviso. “Il sandboxing protegge l’endpoint, ma prendere il controllo dell’agente significa prendere il controllo dei suoi accessi e dei suoi strumenti”, si legge nel report.
.@cyera_io and @oasissec research teams have found CVE-2026-65105 in @nvidia NemoClaw: one webpage visit gives an attacker full control of the model behind the OpenClaw agent, no credentials needed.
Using DNS rebinding, the attacker reaches the local Ollama API and poisons the� pic.twitter.com/AMmoMhahfw
� Cyera (@cyera_io) August 25, 2026
NemoClaw avvia Ollama con la variabile OLLAMA_HOST=0.0.0.0:11434, che mette il server dei modelli in ascolto su ogni interfaccia di rete. L’API sulla porta 11434 non chiede autenticazione e si difende dalle richieste in arrivo da un browser con due soli livelli di middleware, nessuno dei quali tiene in questa configurazione. Il primo controlla l’intestazione Host, e viene saltato per intero quando l’indirizzo di ascolto non � quello di loopback; il secondo, il livello CORS, tratta la richiesta come proveniente dalla stessa origine, perch� l’intestazione Origin e quella Host portano entrambe il dominio dell’attaccante. Vale per una pagina che l’attaccante serve sulla porta 11434, e il DNS rebinding chiude la distanza che resta: il dominio ostile risolve prima verso il server dell’attaccante e poi verso 127.0.0.1, mentre il browser continua a considerare le richieste di pari origine. Luz ha verificato la catena completa su macOS con Firefox, contro una versione vulnerabile di NemoClaw.
La verifica dell’Host esiste dal 2024, ma non su 0.0.0.0
Il DNS rebinding contro l’API di Ollama � documentato da tempo. Nel marzo 2024 NCC Group segnal� al progetto una vulnerabilit� che permetteva a un sito ostile di pilotare l’API ed esfiltrare file dal sistema, incatenando la creazione di un modello con l’istruzione ADAPTER puntata su un file locale e il successivo caricamento verso un registro controllato dall’attaccante. L’advisory, pubblicata l’8 aprile 2024 con l’identificativo CVE-2024-28224, indicava tre secondi come tempo sufficiente perch� il rebinding andasse a segno una volta stabilito il contatto con il server ostile. Ollama distribu� la correzione con la v0.1.29 il 14 marzo 2024, e la raccomandazione principale di NCC Group era proprio validare lato server l’intestazione Host, accettando solo un elenco chiuso di valori autorizzati.
Quella validazione � arrivata, e secondo Luz � arrivata proprio in risposta alla segnalazione del 2024, ma con un limite che il caso NemoClaw riporta a galla. “Ollama salta quella verifica ogni volta che � in ascolto su un indirizzo diverso da quello di loopback, e 0.0.0.0 � esattamente il modo in cui NemoClaw lo configura”, ha spiegato. Anche la pagina di integrazione fra Ollama e NemoClaw consiglia di impostare OLLAMA_HOST=0.0.0.0 quando si lavora dentro WSL2 o un container, e il passaggio a quell’indirizzo � gi� stato identificato in passato come la modifica che rende un’istanza raggiungibile oltre la macchina locale.
Ottenuto l’accesso all’API, il payload scrive tramite /api/create un template Go modificato. Il template governa il passaggio in cui l’array strutturato dei messaggi diventa testo grezzo, prima che il modello lo elabori, e la versione avvelenata aggiunge in coda a ogni messaggio di sistema un testo scelto dall’attaccante, al momento dell’inferenza. Le istruzioni piantate in questo modo restano valide nelle conversazioni successive e continuano a valere anche quando l’agente fornisce un proprio prompt di sistema. “Il client non pu� rilevarlo n� impedirlo: il template � una propriet� a livello di modello, invisibile a chi consuma l’API”, si legge nel report.
Le piattaforme corrette e quella che resta fuori
La gestione di Ollama dentro NemoClaw cambia da piattaforma a piattaforma. Sugli host che non usano WSL il demone resta su 127.0.0.1:11434 dietro un reverse proxy protetto da token in ascolto su 0.0.0.0:11435, e la procedura di avvio riporta su loopback un demone gi� in ascolto altrove. Con Docker Desktop su WSL il proxy non viene usato, perch� il container raggiunge l’indirizzo di loopback dell’host attraverso host.docker.internal. Il percorso che tiene Ollama sull’host Windows imposta invece OLLAMA_HOST=0.0.0.0:11434 perch� i container di Docker Desktop possano parlare con il demone, e sulla porta 11434 non richiede autenticazione. Va segnalato che il report descrive quel binding come comportamento di NemoClaw, mentre la documentazione di NVIDIA e il sorgente attuale lo collocano su questo solo percorso di piattaforma.
Una revisione del repository al commit 17f0ca3b, condotta il 25 agosto da The Hacker News, ha trovato che il proxy locale si rifiuta di partire contro un backend non in ascolto su loopback: � un default introdotto con la v0.0.106 il 10 agosto, che fa uscire il processo con un codice di stato dedicato e invita a riportare il demone su 127.0.0.1 nell’unit� systemd di Ollama. Il controllo si disattiva impostando a 1 la variabile NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE, e sugli host dove la verifica del binding non pu� essere eseguita non blocca comunque l’avvio. Soprattutto, il controllo vive dentro il proxy, e sui percorsi WSL il proxy non viene avviato: la protezione introdotta ad agosto non arriva quindi sulla piattaforma dove il binding a 0.0.0.0 viene impostato. La documentazione di NVIDIA raccomanda a chi lavora sull’host Windows di non esporre la porta 11434 alla rete locale o a internet, indicazione che riguarda gli accessi in arrivo dall’esterno e che la catena descritta non ha bisogno di aggirare, dato che il browser da cui partono le richieste gira gi� sulla macchina e raggiunge il demone su 127.0.0.1.
La stessa revisione non ha trovato alcun controllo di integrit� del template in nessun punto del repository: NemoClaw interroga /api/show soltanto per conoscere la lunghezza di contesto nativa di un modello e la capacit� dichiarata di invocare strumenti. Avvelenare il template della conversazione perch� le istruzioni agiscano durante l’inferenza non � una novit�: Oasis Security ha documentato la stessa tecnica contro Paperclip nelle scorse settimane, e a febbraio aveva usato un percorso browser-verso-localhost analogo per dirottare agenti OpenClaw in esecuzione locale. Su macOS e Linux la correzione esiste dalla v0.0.35; sul percorso Windows resta l’avviso aggiunto con la v0.0.34.
#Adessonews seleziona nella rete articoli di particolare interesse.
Se vuoi leggere l’articolo completo clicca sul seguente link
