Ein lokaler KI-Agent fühlt sich zunächst wie die sichere Variante an: Quellcode, Prompts und Zwischenergebnisse verlassen nicht den eigenen Rechner, das Modell läuft auf der Entwickler-Workstation oder im Labor, und eine Sandbox soll den Agenten vom Host trennen. Genau diese Annahme ist das Praxisproblem hinter der neuen NemoClaw-/Ollama-Schwachstelle. Die Frage ist nicht nur, ob der Agent in einem Container läuft. Entscheidend ist, wer den lokalen Inferenzserver erreichen kann und ob dessen Modellvorlage unverändert bleibt.
Am 25. August 2026 veröffentlichte Cyera/Oasis Security eine Analyse zu einer Schwachstelle in NVIDIA NemoClaw, einem Stack zum Betrieb von OpenClaw-Agenten in OpenShell-Sandboxes. Parallel führt der NVIDIA Product-Security-Bulletin für NemoClaw und OpenShell vom 25. August die CVE-2026-65105 als High-Severity-Lücke mit CVSS 8.1. NVIDIA beschreibt sie nüchtern als fehlende Authentifizierung im Inference-Server-Setup von NemoClaw für Linux: Ein Angreifer im angrenzenden Netzwerk kann ohne Zugangsdaten auf den Inferenzdienst zugreifen; mögliche Folgen sind Informationsabfluss und Denial of Service. Die technische Analyse von Oasis zeigt, warum das für Agenten deutlich weiter reicht als bei einem gewöhnlichen lokalen API-Port.
Der technische Kern: 0.0.0.0 statt Loopback
NemoClaw kann Ollama als lokalen Modellserver verwenden. Ollama lauscht typischerweise auf Port 11434 und besitzt selbst keine klassische API-Authentifizierung. Für einen rein lokalen Dienst ist das nur dann akzeptabel, wenn er wirklich nur auf 127.0.0.1 erreichbar ist und Host-Header-Prüfungen Browserzugriffe begrenzen. Das Problem entsteht, wenn ein Wrapper den Dienst auf 0.0.0.0:11434 bindet, damit Docker-Container oder WSL-/Sandbox-Umgebungen den Host erreichen können.
Nach Oasis startet NemoClaw Ollama in bestimmten lokalen Inferenzpfaden genau so: gebunden an alle Netzwerkinterfaces. Damit wird eine Schutzannahme in Ollama geschwächt. Die Host-Header-Validierung, die bei Loopback-Bindings gegen DNS-Rebinding helfen soll, wird bei Nicht-Loopback-Bindings übersprungen. Übrig bleibt im Browserkontext im Wesentlichen CORS-Logik. DNS-Rebinding nutzt aus, dass der Browser die Same-Origin-Policy an den Hostnamen koppelt, nicht an die später aufgelöste IP-Adresse. Eine Angreifer-Domain kann zunächst auf den Angreifer-Server zeigen und anschließend auf 127.0.0.1 oder eine lokale Adresse umgebogen werden. Für den Browser bleibt es derselbe Ursprung; für den lokalen Ollama-Dienst sieht es wie eine zulässige Anfrage aus.
Das ist keine theoretisch neue Webtechnik. NCC Group dokumentierte bereits 2024 eine DNS-Rebinding-Schwachstelle in Ollama selbst (CVE-2024-28224), die in Ollama 0.1.29 behoben wurde. Der aktuelle NemoClaw-Fall ist trotzdem relevant, weil eine Integrationsentscheidung diese Schutzwirkung wieder aushebelt: Container-Erreichbarkeit wird zur Sicherheitsentscheidung.
Warum Agenten stärker betroffen sind als normale Chat-Clients
Mit Zugriff auf Ollamas API kann ein Angreifer laut Oasis Modelle auflisten, Versionen und Modell-Metadaten abfragen, Inferenz auf fremder GPU ausführen, Modelle löschen oder große Modelle nachladen und damit Ressourcen verbrauchen. Für Unternehmen ist jedoch die Integritätsdimension entscheidend: Über Ollamas /api/create lässt sich nicht nur ein Modell anlegen, sondern auch dessen Chat-Template verändern.
Dieses Template ist die Render-Schicht zwischen strukturierten Nachrichten und dem Text, den das Modell tatsächlich sieht. Ein normaler System-Prompt im Agentenclient kann dadurch nicht zuverlässig schützen, weil die manipulierte Vorlage bei jeder späteren Anfrage erneut angewendet wird. Oasis beschreibt einen PoC, bei dem eine Webseite die bestehende Vorlage ausliest, eine versteckte Instruktion ergänzt und die geänderte Vorlage zurückschreibt. Die Änderung bleibt für spätere Sitzungen bestehen und ist für den Client schwer sichtbar, weil Modellname, Größe und allgemeine Metadaten unverändert wirken.
Der Unterschied zu klassischer Prompt Injection ist wichtig: Hier wird nicht nur ein einzelner Prompt manipuliert. Die Inferenzschicht selbst wird zum persistenten Zustand. Wenn der Agent anschließend Zugriff auf Repositorys, Build-Systeme, Cloud-APIs, interne Dokumente oder MCP-Tools hat, bestimmt diese Berechtigungsmenge den Schaden. Die Sandbox schützt den Host nur teilweise; sie begrenzt nicht automatisch, was der Agent über seine legitimen Tools tun darf.
Quellenlage und Patch-Status
Die belastbaren Fakten kommen aus drei Ebenen. Erstens bestätigt NVIDIAs Product-Security-Repository den Security Bulletin „NVIDIA NemoClaw and OpenShell - August 2026“ und CVE-2026-65105 mit CVSS 8.1, CWE-306 und betroffenen Linux-Versionen „0 to 0.0.25“. Zweitens liefert Oasis/Cyera die technische Angriffsanalyse: OLLAMA_HOST=0.0.0.0:11434, DNS-Rebinding, voller Ollama-API-Zugriff und persistente Chat-Template-Manipulation. Drittens bestätigt The Hacker News die Veröffentlichung vom 25. August und ergänzt Repository- und Plattformdetails, unter anderem dass neuere NemoClaw-Pfade für Nicht-WSL-Hosts Ollama auf 127.0.0.1:11434 hinter einen token-gated Reverse Proxy auf 0.0.0.0:11435 legen sollen.
Gleichzeitig gibt es eine wichtige Limitierung: Die öffentlichen Quellen nennen keine beobachtete breite Ausnutzung gegen Unternehmen. The Hacker News schreibt ausdrücklich, dass bis zum 25. August keine Ausnutzung gemeldet war. Auch der CVE-Eintrag spricht primär von Zugriff, Informationsabfluss und Verfügbarkeit, nicht von bestätigter Codeausführung über diese konkrete CVE. Unternehmen sollten den Fall daher nicht als Panikmeldung lesen, sondern als Designfehler mit hohem Präventionswert.
Was Unternehmen jetzt konkret prüfen sollten
Erstens gehört jeder lokale Inferenzserver ins Asset- und Port-Inventar. localhost in einer Installationsmeldung reicht nicht. Prüfen Sie, ob Ollama, vLLM, llama.cpp, OpenAI-kompatible Proxyserver oder Agent-Harness-Komponenten tatsächlich nur auf Loopback lauschen oder auf allen Interfaces. Besonders kritisch sind Entwicklerlaptops in Büro-, Gast- oder Konferenznetzwerken.
Zweitens sollte kein Inferenzdienst ohne Authentifizierung auf 0.0.0.0 laufen. Wenn Container ihn erreichen müssen, ist ein enger Reverse Proxy mit Token, mTLS oder mindestens lokal begrenzter Firewall-Regel besser als ein global offener Port. Für Ollama-Setups ist die Zielkonfiguration: Backend auf 127.0.0.1, kontrollierter Proxy für die wenigen legitimen Pfade.
Drittens brauchen Agenten eine Integritätsprüfung für Modell- und Template-Zustand. Wer lokale Modelle produktiv für Code-Änderungen, Security-Triage oder Infrastrukturaufgaben nutzt, sollte Templates versionieren, Änderungen auditieren und bei Verdacht Modelle aus einer vertrauenswürdigen Quelle neu ziehen. Eine reine EDR-Sicht auf Prozesse reicht nicht, wenn die Manipulation in Modell-Metadaten steckt.
Viertens muss der Blast Radius der Agentenrechte begrenzt werden. Agenten sollten nicht dauerhaft dieselben Cloud-, Git-, CI/CD- und Secret-Rechte besitzen wie ein Senior-Entwickler. Kurzlebige Tokens, projektspezifische Rollen, getrennte Lese-/Schreibpfade, egress-beschränkte Sandboxes und explizite Freigaben für irreversible Aktionen reduzieren den Schaden, falls die Inferenzschicht kompromittiert wird.
Fazit
CVE-2026-65105 ist weniger eine Geschichte über ein einzelnes Produkt als über eine neue Betriebsdisziplin für lokale KI-Agenten. „Lokal“ bedeutet nicht automatisch „sicher“. Ein nicht authentifizierter Modellserver auf allen Interfaces ist ein Unternehmensdienst, auch wenn er auf einem Entwicklerrechner läuft. Wer Agenten in Entwicklung, DevOps oder Security Operations einsetzt, sollte die Inferenzschicht wie eine privilegierte Komponente behandeln: erreichbar nur für berechtigte Clients, mit nachvollziehbarem Zustand, begrenzten Tools und klarer Trennung zwischen Sandbox, Modellserver und Unternehmensressourcen.
Quellen: Cyera/Oasis Security zur NemoClaw-Schwachstelle, NVIDIA Product Security Bulletin 5872, CVE-2026-65105 im NVIDIA-CVE-Record, The Hacker News vom 25. August 2026, NCC Group zu Ollama DNS Rebinding CVE-2024-28224.
