Angreifer versuchen zunehmend, nicht nur Daten zu stehlen, sondern auch KI-Systeme auf lokalen Rechnern umzubauen. Ein aktueller Bericht von Oasis Security macht deutlich, wie ein kompromittierter Zugriff auf die lokale Ollama-Instanz in der NVIDIA-Referenzumgebung NemoClaw dazu genutzt werden kann, späteren Gesprächen heimlich Anweisungen hinzuzufügen. Ziel ist damit nicht primär der Diebstahl von Chat-Verläufen, sondern das Lokales KI-Modell kompromittieren – indem Manipulationen im Modell selbst persistieren.
Wichtig: Zum Zeitpunkt des Berichts gab es keine gemeldete Ausnutzung in freier Wildbahn (Stand 25. August 2026) und auch keine eindeutige CVE-Nummer. Für Betreiber ist die Lage daher vor allem eins: prüfen, wie ihre Umgebung Ollama und NemoClaw konfiguriert.
Worum geht es bei NemoClaw und Ollama?
NVIDIA NemoClaw ist eine Open-Source-Referenz-Stack-Lösung, um Agenten in OpenShell-Sandbox-Umgebungen auszuführen. Als Bestandteil dieses Setups dient Ollama als unterstützter lokaler Inferenz-Back-End. Damit laufen die Modelle und die Logik, auf die Agenten später zugreifen, auf dem System des Betreibers.
Genau dort setzt der Bericht an: Wenn eine Angreiferin oder ein Angreifer eine unauthetisierte Kontrolle über die lokale Ollama-Instanz erhält, kann die Chat-Vorlage so verändert werden, dass jede spätere Interaktion beeinflusst wird.
Wie eine Webseite lokale Kontrolle übernehmen könnte
Die Forschenden beschreiben einen Angriffspfad, bei dem eine vom Angreifer gesteuerte Webseite die Ollama-API anspricht. Im Ergebnis kann der Angreifer über eine API-Funktion eine Go-Template-Vorlage verändern. Diese Vorlage bestimmt, wie eine strukturierte Nachrichtenliste vor der eigentlichen Modellverarbeitung in Rohtext umgewandelt wird.
Die Manipulation besteht darin, dass der geänderte Template-Code während der Inferenz zusätzliche, attacker-controlled Texte an Systemnachrichten anhängt. Das kann dann die Antworten des Modells in zukünftigen Gesprächen beeinflussen.
Ein besonders kritischer Punkt: Die eingebrachten Anweisungen sollen über spätere Sessions hinweg erhalten bleiben. Laut Oasis Security kann ein Client das nicht zuverlässig erkennen oder verhindern, weil die Template-Eigenschaft auf Modellebene liegt und damit für API-Nutzer nicht sichtbar ist.
Warum die Sandbox nicht automatisch schützt
Auf den ersten Blick wirkt das Setup durch Sandboxing zunächst sicher. Der Bericht hält jedoch dagegen: Selbst wenn der Endpunkt im Sandbox-Kontext geschützt wird, bedeutet eine Übernahme des Agents automatisch auch eine Übernahme seiner Zugriffsrechte auf die relevanten Tools und Funktionen. Mit anderen Worten: Sandboxing kann die Ausführung isolieren, aber es verhindert nicht, dass ein Angreifer die Agent-Umgebung durch Manipulation der KI-Logik in eine unerwünschte Richtung lenkt.
Der Kern: Ollama bindet an zu viele Adressen
Zentral ist die Frage, wie Ollama im NemoClaw-Setup erreichbar gemacht wird. Der Bericht beschreibt, dass NemoClaw Ollama in einer Konfiguration startet, bei der OLLAMA_HOST=0.0.0.0:11434 gesetzt wird. Das bindet den Modellserver an alle Netzwerk-Schnittstellen – theoretisch also auch außerhalb des lokalen Rechners.
Allerdings ist nicht nur die reine Netzwerk-Erreichbarkeit relevant, sondern auch, wie Schutzschichten im Zusammenspiel wirken. Die analysierte API auf Port 11434 sei dabei ohne Authentifizierung implementiert. Stattdessen werden Zugriffe durch zwei Middleware-Schichten blockiert, die browsergetriebene Requests verhindern sollen.
Für Angreifer wird diese Schutzlogik offenbar lückenhaft, wenn Ollama nicht an Loopback gebunden ist: Dann wird laut Bericht die Host-Header-Prüfung übersprungen. Im Anschluss behandelt die CORS-Logik den Request als same-origin, weil sowohl Origin als auch Host die Domain des Angreifers enthalten.
DNS Rebinding als entscheidender Hebel
Damit eine Webseite erfolgreich gegen eine lokale API vorgehen kann, muss der Browser Requests als „gleich“ behandeln. Genau dafür wird im Bericht DNS rebinding verwendet: Die Angreifer-Domain wird zunächst auf den Server des Angreifers aufgelöst. Danach ändert sich die Auflösung während der bestehenden Browser-Session so, dass derselbe Host plötzlich auf 127.0.0.1 zeigt – während der Browser weiterhin same-origin annimmt.
Das schafft den Raum für API-Aufrufe gegen den lokalen Dienst, obwohl es aus Sicht klassischer Same-Origin-Politik eigentlich blockiert werden sollte. Der Bericht weist darauf hin, dass die Kette nicht gegen eine bestimmte Browser- oder Betriebssystem-Realität verifiziert wurde. Dennoch wird ein Standard-Fix genannt: Host- und Origin-Header serverseitig korrekt prüfen.
Warum Betreiber das aktuell nicht sauber prüfen können
Für viele Sicherheitsmeldungen gilt: Mit einer CVE und einem betroffenen Versionsbereich kann man schnell entscheiden, ob man gefährdet ist. In diesem Fall fehlt laut Bericht jedoch ein CVE-Identifier, ebenso fehlen ein konkreter betroffener Versionsbereich und eine gesicherte gepatchte Version. Dadurch kann ein Betreiber derzeit nicht eindeutig selbst verifizieren, ob seine NemoClaw-Installation in den Scope fällt.
Was allerdings hilft: Der Bericht beschreibt, warum die konkrete Plattformkonfiguration eine große Rolle spielt – und welche Unterschiede es zwischen Umgebungen geben kann.
Unterschiede je nach Plattform und Setup
Der Angriff hängt dem Bericht zufolge stark davon ab, wie Ollama in der jeweiligen Umgebung erreichbar gemacht wird. Beispielhaft werden im Bericht mehrere Pfade beschrieben:
- Non-WSL Hosts: Ollama läuft typischerweise auf 127.0.0.1:11434 hinter einem token-gesteuerten Reverse-Proxy, der auf 0.0.0.0:11435 gebunden ist. Zudem kommt es zu einem Neustart während des Onboardings, wobei ein bereits gebundener Daemon auf Loopback zurückgesetzt wird.
- Docker Desktop auf WSL: Der Proxy wird übersprungen, weil der Container über host.docker.internal auf die Loopback-Adresse des Hosts zugreifen kann.
- Windows-host Pfad: Hier wird OLLAMA_HOST=0.0.0.0:11434 gesetzt, damit Docker-Desktop-Container den Daemon erreichen. Außerdem sei für Port 11434 keine Authentifizierung nötig.
Auch eine NemoClaw-Integration zu Ollama wird im Bericht in Zusammenhang mit der Empfehlung genannt, in WSL2 oder Container-Setups OLLAMA_HOST=0.0.0.0 zu verwenden. Gleichzeitig wird im Bericht betont, dass genau dieses Binden an 0.0.0.0 eine Änderung sein kann, die Ollama-Instanzen über den lokalen Rechner hinaus zugänglich macht.
Host-Header-Checks, Bind-Probes und ein Proxy-Refuse
Der Bericht enthält zudem Details, die erklären, warum nicht jede Konfiguration gleich riskant ist. In einer Repository-Überprüfung (am 25. August 2026) wurde festgestellt, dass ein lokaler Ollama-Proxy nicht startet, wenn der Backend-Dienst nicht auf Loopback gebunden ist. Diese Default-Regel wurde offenbar mit einem späteren Stand eingeführt und kann durch eine Umgebungsvariable übersteuert werden.
Erwähnt wird außerdem: NemoClaw starte den Proxy in bestimmten WSL-Pfaden nicht. Der relevante Windows-host Pfad sei deshalb einer der Orte, an denen die Proxy-Bind-Checks nicht greifen wie in anderen Setups.
Zusätzlich hätten die Forschenden keine Chat-Template-Integritätsprüfung im Projekt gefunden. Ollama werde über einen /api/show-Endpoint nur für Parameter wie Kontextlänge und Tool-Fähigkeiten befragt.
Zusammenhang zu bekannten DNS-Rebinding-Angriffen
Die Idee, DNS rebinding gegen lokale Dienste einzusetzen, ist nicht neu. Der Bericht ordnet das Risiko in die Geschichte ein: Ollama habe bereits im Jahr 2024 eine Korrektur ausgeliefert. Außerdem gebe es eine Advisory (mit CVE-Nummer), die einen serverseitigen Host-Header-Check als Empfehlung nennt.
Für Betreiber heißt das: Auch wenn bereits Fixes existierten, können neue Konstellationen entstehen, etwa durch Integrationsdetails, unterschiedliche Plattformpfade oder abweichende Proxy- und Bind-Verhalten.
Was jetzt wichtig ist: Umgebung prüfen und Exposition reduzieren
Da zum Meldungszeitpunkt keine klare „betroffene Version“ benannt wird, sollten Betreiber weniger nach Versionen suchen und stärker nach Konfigurationen handeln. Der Bericht macht dabei vor allem zwei Dinge deutlich:
- Bindet euer Setup Ollama an nicht-loopback Adressen? Insbesondere Konfigurationen mit 0.0.0.0 sind im Bericht mit einer erhöhten Angriffsfläche verknüpft.
- Verlasst euch nicht ausschließlich auf Ingress-Guidelines. NVIDIA-dokumentierte Empfehlungen adressieren vor allem Netzwerk-Zugriffe von außen. Der berichtete Angriff kann jedoch auch ohne solche Exposition funktionieren, weil der Browser bereits auf dem betroffenen Host ausgeführt wird.
Bis eine eindeutige Scope-Angabe oder ein Patch-Ziel vorliegt, ist die praktische Maßnahme: Konfigurationen von OLLAMA_HOST, Proxy-Modi und Reverse-Proxy-Logik genau prüfen und sicherstellen, dass der API-Zugriff nur für autorisierte Pfade möglich ist.
Fazit: Lokale KI ist nicht automatisch „offline-sicher“
Der Bericht zeigt eindrücklich, wie eine bösartige Webseite dazu führen kann, dass ein lokales KI-Modell dauerhaft beeinflusst wird – über eine Manipulation der Chat-Template-Vorlage in Ollama, die späteren Gesprächen weiterhin „unsichtbare“ Zusatzanweisungen gibt. Damit rückt das Lokales KI-Modell kompromittieren in den Fokus: Nicht nur Daten, sondern auch System- und Inferenzlogik können Ziel sein.
Für Betreiber bleibt deshalb die zentrale Botschaft: Prüft eure NemoClaw- und Ollama-Konfiguration, reduziert unnötige Bindings, achtet auf korrekte Header-Validierung und verfolgt Updates von NVIDIA sowie Sicherheitsmeldungen zu eurem konkreten Plattformpfad.
Quelle: https://thehackernews.com/2026/08/a-malicious-webpage-could-poison-your.html
