Een onverwachte aanvalsketen kan het risico op lokaal AI-model vergiftigen vergroten wanneer je NVIDIA NemoClaw gebruikt in combinatie met Ollama. Onderzoekers van Oasis Security beschrijven hoe een pagina die een aanvaller controleert, mogelijk een niet-geauthenticeerde API sessie in de lokale AI-omgeving misbruikt. Het doel: verborgen instructies in de modelcontext laten landen, zodat ze bij latere gesprekken blijven terugkomen.
In de gepubliceerde bevindingen staat ook een belangrijke beperking: er is (nog) geen CVE en er wordt geen exacte versiebereik of patch genoemd. Bovendien is er volgens de rapportage op 25 augustus 2026 geen exploit gemeld. Dat neemt niet weg dat de aanval vooral draait om een kwetsbare configuratie en om hoe browserverzoeken lokaal kunnen worden doorgezet.
Wat er volgens Oasis Security gebeurt
De kern van het probleem zit in de interactie tussen NemoClaw en Ollama. NemoClaw start Ollama met een hostinstelling die het modelserverproces kan binden aan alle netwerkinterfaces. In het rapport wordt genoemd dat NemoClaw in bepaalde configuraties Ollama laat luisteren via 0.0.0.0:11434. Daardoor wordt de Ollama-API niet alleen vanaf het lokale systeem bruikbaar, maar in de praktijk ook misbruikbaar via omwegen die lijken op “browser-to-localhost” aanvallen.
Volgens het rapport krijgt een aanvaller zo de mogelijkheid om de chat template aan te passen. Dat is relevant, omdat templates bepalen hoe gestructureerde berichten uiteindelijk als tekst naar het model worden doorgegeven. Wanneer de template eenmaal is vergiftigd, worden de door de aanvaller geplaatste instructies volgens de onderzoekers toegepast bij elke volgende inferentie, ook als het agent-systeem later zijn eigen systeemprompt probeert te gebruiken.
Oasis Security vat het risico samen met een duidelijke gedachte: sandboxing beschermt het “endpoint”, maar zodra de agent wordt overgenomen, krijgt de aanvaller toegang tot de context en hulpmiddelen die de agent lokaal mag gebruiken.
Waarom authenticatie niet helpt in dit scenario
De Ollama-API op poort 11434 zou geen authenticatie vereisen. Het rapport stelt dat er in plaats daarvan twee middlewarelagen worden gebruikt om verzoeken vanaf webpagina’s tegen te houden. De aanval speelt in op de details van host- en origin-afhandeling: zodra het bindadres niet op loopback draait, zou er een host header check worden overgeslagen.
Vervolgens zou CORS (Cross-Origin Resource Sharing) het verzoek als “same-origin” behandelen. Dat gebeurt doordat zowel Origin als Host dezelfde domeinwaarden bevatten als die van de aanvaller. Met andere woorden: de browser wordt in de keten als “transport” ingezet, niet als inhoudelijke verdediger.
Om de keten rond te krijgen wordt gebruikgemaakt van DNS rebinding. Daarbij wijst de aanvallershost eerst naar een server onder controle van de aanvaller en daarna naar 127.0.0.1, terwijl de browser het verzoek in de ogen van zijn origin-policy als dezelfde herkomst blijft behandelen.
Het rapport merkt op dat de standaardaanpak bestaat uit het strikt valideren van Host en Origin op de serverzijde. Die combinatie is ook beschreven als effectieve fix voor dit type aanvalsklasse.
Geen CVE, wel context: eerder bekende fixes voor Ollama
Omdat er voor NemoClaw/Oasis Security geen CVE-id is vastgesteld, kunnen beheerders nu vooral niet “op nummer” patchen. Tegelijkertijd verwijst het rapport naar een eerdere oplossing voor het bredere Ollama-probleem.
Er wordt genoemd dat Ollama eerder een fix heeft uitgebracht in versie v0.1.29 (op 14 maart 2024). Daarnaast publiceerde NCC Group een advisory met CVE-2024-28224, waarin werd aanbevolen om server-side de Host header te valideren tegen een lijst van toegestane waarden. Dat is precies het soort correctie dat in dit scenario de aanvalsketen zou moeten afbreken.
Voor operators betekent dit: check niet alleen de NemoClaw-laag, maar kijk ook kritisch naar je Ollama-versie en naar de manier waarop de API wordt blootgesteld.
Platformverschillen: waarom 0.0.0.0 op sommige plekken extra risico geeft
Een opvallend deel van het rapport gaat over verschillen tussen platformpaden en de manier waarop proxy’s en netwerkbindingen werken. In sommige niet-WSL omgevingen zou Ollama bijvoorbeeld achter een token-gated reverse proxy luisteren op 0.0.0.0:11435, terwijl het modelserveronderdeel zelf op 127.0.0.1:11434 blijft. Bij Docker Desktop op WSL wordt bovendien verwezen naar een andere route via host-naar-container connectiviteit.
De Windows-host route is daarentegen specifiek relevant: daar zou de Ollama-configuratie OLLAMA_HOST=0.0.0.0:11434 gebruiken, zodat containers van Docker Desktop het lokale model kunnen bereiken. Daarbij wordt niet om authenticatie gevraagd op poort 11434. En volgens de onderzoekers speelt dit precies in op de aanvalsketen, omdat het bindadres en de bijbehorende checks in die route anders uitpakken dan in loopback-configuraties.
Daar komt nog een praktische waarschuwing bovenop: NemoClaw adviseert (in integratiedocumentatie voor WSL2 of containers) juist om OLLAMA_HOST op 0.0.0.0 te zetten. Tegelijkertijd is in het rapport eerder benoemd dat het binden aan 0.0.0.0 Ollama bloot kan stellen buiten de lokale machine.
Een extra guardrail in de repository-check (en waarom die niet overal landt)
Bij een review van de NemoClaw code op commitdatum 25 augustus 2026 werd volgens het rapport ook een beschermingslogica aangetroffen. Een lokale Ollama proxy zou weigeren te starten wanneer de Ollama daemon bereikbaar is op een niet-loopback interface, omdat dat de tokencheck zou omzeilen. De proxy schrijft daarbij een specifieke foutmelding weg en sluit dan af.
Er is bovendien een override-variabele genoemd waarmee die guardrail kan worden uitgeschakeld (NEMOCLAW_OLLAMA_PROXY_SKIP_BIND_PROBE=1), maar die optie wordt expliciet als niet aanbevolen gekenschetst.
Toch blijft er een probleem: de check zou niet op alle platformpaden beschikbaar zijn. Het rapport stelt dat de proxy niet draait in bepaalde WSL-paden en dat de Windows-host configuratie een route is waar de guardrail niet wordt afgedekt door dezelfde binding-probe. Daardoor kan de kwetsbare OLLAMA_HOST-instelling alsnog in de aanvalsketen terechtkomen.
Wat je als beheerder nu kunt doen
Zolang er geen CVE of versiebereik is, draait “mitigatie” voor lokaal AI-model vergiftigen vooral om je configuratie en je exposure. Hieronder staan maatregelen die logisch volgen uit de beschreven keten.
- Beperk het bindadres: vermijd waar mogelijk dat de Ollama-API luistert op 0.0.0.0 zonder noodzaak. Geef de voorkeur aan loopback-bindings voor lokale toegang.
- Controleer je Ollama versie: kijk of je binnen het tempo van de genoemde fix (rond v0.1.29) zit en verifieer dat server-side host-validatie klopt.
- Voorkom blootstelling van poort 11434 aan netwerken of publiek verkeer. NVIDIA’s eigen documentatie waarschuwt al om port 11434 niet open te zetten voor LAN of internet; in dit scenario is dat niet eens strikt nodig, maar het verkleint je aanvalsoppervlak wel.
- Let op DNS-rebinding risico’s: behandel “localhost via een domeinnaam” niet als vanzelfsprekend veilig. De verdediging zit in headervalidatie; zorg dat die op jouw servercomponenten daadwerkelijk actief en correct is.
- Monitor integriteitsafwijkingen: hoewel het rapport stelt dat clients template-wijzigingen niet direct kunnen detecteren, kun je wel kijken naar ongebruikelijke wijzigingen in je configuratiebestand(en) of naar vreemde wijzigingen in agentgedrag.
Wil je breder leren hoe onveilige blootstelling van lokale services tot misbruik kan leiden via browserketens en omwegen? Lees dan ook eens hoe FTP-banners als dead drops voor malwarecommando’s kunnen werken. Het is een ander kanaal, maar de insteek—“lokale componenten die als misbruikroute dienen”—komt overeen.
Vergiftiging van templates: waarom het lastig te herkennen is
In veel AI-beveiligingsdiscussies gaat de aandacht uit naar prompt injection of naar het wijzigen van gedrag tijdens één run. Dit rapport benadrukt iets anders: een wijziging aan de chat template kan volgens de onderzoekers persistent zijn. Daardoor blijft de “aanvaller-instructie” aanwezig in toekomstige gesprekken, zelfs wanneer de agent later een systeemprompt op zijn eigen manier zou willen aansturen.
Daarbij komt dat het rapport aangeeft dat een client mogelijk niet kan controleren of de template intact is. Het is dan niet alleen een kwestie van “waarom gedraagt het model zich raar?”, maar ook van “welke interne weergavelogica is veranderd?”
Dat maakt het risico met name relevant voor organisaties die lokale agents gebruiken voor taken waar vertrouwen belangrijk is, zoals assistentie bij documentopbouw, selectie van tools of het verwerken van gevoelige context. Een kleine misconfiguratie kan dan uitgroeien tot een structurele verstoring.
Toekomst: wat ontbreekt er nog in het publieke beeld
Het rapport is helder over de aanvalspijplijn, maar laat ook open vragen. Zo vraagt men in het vervolg om de NemoClaw versie en het specifieke platformpad waarop het bewijs van concept is geverifieerd. Ook ontbreken er op dit moment de scope-informatie (versie-afbakening), en dus weten operators niet precies of hun installatie “automatisch” valt binnen de genoemde omstandigheden.
Dat betekent dat je niet blind kunt varen op één getal of één patch. Je moet je in plaats daarvan richten op de uitgangspunten van de keten: exposure (bindadres), header-afhandeling, en de manier waarop de lokale API requests interpreteert.
Conclusie
Volgens Oasis Security kan een kwaadaardige webpagina mogelijk het lokaal AI-model vergiftigen wanneer NVIDIA NemoClaw met Ollama draait en de Ollama-API op een manier bereikbaar is die host- en origin-controles ondermijnt. De aanval richt zich niet op het “kraken” van het sandboxmodel, maar op het manipuleren van de chat template zodat verborgen instructies bij latere gesprekken blijven doorwerken.
Omdat er (nog) geen CVE en geen patchadvies met versiebereik is gepubliceerd, ligt de praktische waarde nu vooral in configuratiechecks: beperk je bindadres, controleer je Ollama-versie en zorg dat lokale API’s correct header-gebaseerd worden beschermd. Zo verklein je het risico dat een lokale agent verandert in een onbeheerde uitvoerder van instructies die niet van jou afkomstig zijn.
Bron: https://thehackernews.com/2026/08/a-malicious-webpage-could-poison-your.html
