CVE-2026-65105: NemoClaw-Lücke erlaubt Modellkonfigurationsvergiftung über Ollama
Bei NVIDIA NemoClaw ermöglicht CVE-2026-65105 eine persistente Manipulation des Chat-Templates über die unauthentifizierte Ollama-API, die standardmäßig an alle Netzwerkschnittstellen bindet. Angreifer im LAN oder per DNS-Rebinding aus dem Browser können so über den Endpunkt /api/create dauerhaft in die Modellkonfiguration eingreifen, ohne Trainingsdaten oder Gewichte zu verändern. Ein Patch für macOS und Linux liegt vor, für Windows und WSL ist der Status unklar.
Wer NemoClaw als Referenzstack für einen KI-Coding-Agenten testet oder produktiv betreibt, sollte vor dem nächsten Deployment einen Blick auf die lokale Ollama-Anbindung werfen. Denn nicht das Modell selbst wird angegriffen, sondern seine Konfiguration, und der Weg dahin führt über eine ganz gewöhnliche Webseite im Browser des Entwicklers.
Wer NemoClaw lokal mit Ollama betreibt und die Standardinstallation nicht angepasst hat, sollte das noch heute prüfen, bevor der Agent das nächste Mal mit sensiblen Repositories oder Zugangsdaten arbeitet. Wer Ollama ausschließlich über eine bereits abgesicherte Umgebung mit strikter Netzwerksegmentierung anspricht oder den Dienst gar nicht öffentlich im LAN bindet, ist von der akuten Variante des Problems nicht betroffen, sollte die Konfiguration aber trotzdem gegenprüfen.
Was ist passiert?
NVIDIA pflegt mit NemoClaw einen Open-Source-Referenzstack für KI-Agenten, die in isolierten OpenShell-Sandboxes laufen und dort Code schreiben, ausführen und testen. Für das eigentliche Sprachmodell setzen viele Entwickler lokal auf Ollama, weil es sich einfach installieren lässt und keine Cloud-Anbindung braucht. Genau in dieser Kombination liegt das Problem, das unter CVE-2026-65105 dokumentiert ist.
Ollama bindet seine API in der Standardkonfiguration nicht nur an das lokale Loopback-Interface, sondern an 0.0.0.0 und damit an alle Netzwerkschnittstellen. Eine Authentifizierung findet dabei nicht statt. Wer sich im selben LAN befindet, kann die API direkt ansprechen. Sicherheitsforscher zeigen zusätzlich, dass sich diese Einschränkung sogar aus der Ferne umgehen lässt: Über DNS-Rebinding kann eine bösartige Webseite, die ein Entwickler im Browser öffnet, den eigenen Rechner dazu bringen, Anfragen an die lokale Ollama-Instanz zu senden, ganz ohne dass der Angreifer selbst im LAN sitzt.
Der eigentliche Angriffshebel ist der Ollama-Endpunkt /api/create. Über ihn lässt sich das Chat-Template eines Modells verändern, also die Anweisungen, die festlegen, wie eingehende Prompts formatiert und interpretiert werden. Wird dieses Template manipuliert, bleibt die Änderung persistent bestehen. Jede folgende Anfrage an das Modell läuft dann durch die veränderte Vorlage, ohne dass Nutzer oder Entwickler das im laufenden Betrieb bemerken.
Wichtig für die Einordnung: Es handelt sich nicht um Data Poisoning oder manipuliertes Training. Die Gewichte des Modells bleiben unangetastet. Angegriffen wird die Modellkonfiguration, konkret das Chat-Template, über das sich das Verhalten des Agenten dauerhaft beeinflussen lässt, etwa um Antworten zu verfälschen, Anweisungen einzuschleusen oder den Agenten zu unerwünschten Aktionen zu bewegen.
Wer ist betroffen?
Betroffen sind Entwickler und Teams, die NemoClaw als Referenzstack einsetzen und dabei lokal Ollama als Modell-Backend nutzen, ohne die Netzwerkbindung der Ollama-API bewusst eingeschränkt zu haben. Das trifft vor allem auf lokale Entwicklungsumgebungen und Testsysteme zu, bei denen Ollama schnell mit Standardeinstellungen installiert wurde.
- NemoClaw-Setups auf macOS und Linux mit lokal laufendem Ollama in Standardkonfiguration
- Entwicklerrechner in gemeinsam genutzten LAN-Segmenten, etwa Büro- oder Coworking-Netzwerke
- Windows- und WSL-Installationen, deren Patchstatus laut verfügbaren Sekundärquellen derzeit uneinheitlich beschrieben wird
- Systeme, auf denen Entwickler regelmäßig unbekannte oder wenig vertrauenswürdige Webseiten im selben Browserprofil öffnen wie ihre Entwicklungswerkzeuge
Nicht akut betroffen sind Umgebungen, in denen Ollama ausschließlich an 127.0.0.1 gebunden ist und keine Netzwerkfreigabe für die API besteht, sowie Setups hinter einer Firewall, die eingehende Verbindungen zum Ollama-Port konsequent blockiert. Auch reine Cloud-Deployments von NemoClaw ohne lokale Ollama-Instanz sind von dieser konkreten Schwachstelle nicht betroffen, sollten aber ihre eigene Modell-Backend-Anbindung unabhängig prüfen.
Wie kritisch ist das?
Die Kombination aus fehlender Authentifizierung, der Standardbindung an alle Netzwerkschnittstellen und der Erreichbarkeit über DNS-Rebinding aus dem Browser macht das Risiko real und praktisch ausnutzbar, nicht nur theoretisch. Ein Angreifer muss weder Zugangsdaten stehlen noch eine Schwachstelle im NemoClaw-Code selbst finden. Es reicht, dass ein Entwickler eine präparierte Webseite besucht, während Ollama lokal läuft.
Eine offizielle CVSS-Bewertung war zum Zeitpunkt der Recherche in den verfügbaren Quellen nicht einheitlich benannt, weshalb hier keine Zahl behauptet wird. Entscheidend für die Einordnung ist der Wirkmechanismus: Persistente Manipulation der Chat-Vorlage bedeutet, dass ein einmal kompromittiertes Modell dauerhaft kompromittiert bleibt, bis jemand die Konfiguration aktiv zurücksetzt oder neu erstellt. Eine aktive Ausnutzung in freier Wildbahn ist nach aktuellem Kenntnisstand nicht bestätigt. Diese Einordnung kann sich ändern, sobald weitere Quellen dazu berichten.
Der Patchstatus ist ebenfalls nicht für alle Plattformen einheitlich belegt. Sekundärquellen nennen NemoClaw 0.0.35 als Version mit Fix für macOS und Linux. Für Windows und WSL widersprechen sich die verfügbaren Angaben, weshalb hier keine gesicherte Aussage zum Patchstatus getroffen werden kann. Wer auf Windows oder unter WSL arbeitet, sollte die eigene Version gezielt gegen das offizielle NemoClaw-Repository prüfen, statt sich auf eine pauschale Patchaussage zu verlassen.
Was sollten Admins jetzt tun?
- Installierte NemoClaw-Version prüfen und mit dem offiziellen Repository abgleichen, ob bereits Version 0.0.35 oder neuer im Einsatz ist
- Auf Windows und unter WSL den Patchstatus nicht als gesichert annehmen, sondern im GitHub-Repository die aktuellen Release-Hinweise gezielt nachlesen
- Ollama-Konfiguration prüfen und die API-Bindung auf 127.0.0.1 beschränken, sofern kein Netzwerkzugriff durch andere Systeme erforderlich ist
- Falls Ollama im Netzwerk erreichbar sein muss, den Zugriff über einen Reverse Proxy mit Authentifizierung oder mTLS absichern, statt die API offen zu lassen
- Firewall-Regeln setzen, die den Ollama-Port aus fremden Netzwerksegmenten blockieren, und die Entwicklerrechner sauber vom übrigen LAN trennen
- Zugriffe auf den Endpunkt
/api/createprotokollieren und ungewöhnliche oder unbekannte Aufrufe im Log gezielt nachverfolgen - Nach jedem Verdacht auf Manipulation die Modellintegrität prüfen, etwa durch Vergleich des aktiven Chat-Templates mit der bekannten Ausgangskonfiguration
- Browserprofile trennen, mit denen Entwickler produktiv arbeiten, von Profilen für allgemeines Surfen, um die Angriffsfläche für DNS-Rebinding zu verkleinern
- Interne Richtlinie für lokale KI-Agenten-Stacks ergänzen, dass unauthentifizierte Backend-APIs grundsätzlich nicht ins LAN gebunden werden
- Betroffene Teams informieren, insbesondere wenn NemoClaw-Instanzen mit Zugriff auf produktive Repositories oder Zugangsdaten laufen
| Kriterium | Einordnung |
|---|---|
| Angriffsvektor | Lokale, unauthentifizierte Ollama-API, erreichbar via LAN oder DNS-Rebinding aus dem Browser |
| Betroffene Komponente | Ollama-API-Bindung an 0.0.0.0 im Zusammenspiel mit NemoClaw |
| Manipulierter Bereich | Chat-Template über /api/create, nicht die Modellgewichte selbst |
| Persistenz | Ja, die Manipulation bleibt bis zum aktiven Zurücksetzen bestehen |
| Aktive Ausnutzung | Nach aktuellem Kenntnisstand nicht bestätigt |
| Patch macOS/Linux | Laut Sekundärquellen ab NemoClaw 0.0.35 verfügbar |
| Patch Windows/WSL | Widersprüchliche Angaben, nicht gesichert |
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen, die KI-Agenten für Coding oder Automatisierung testen, zeigt dieser Fall ein Muster, das über NemoClaw hinausgeht: Lokale LLM-Backends wie Ollama werden häufig schnell installiert, um produktiv zu werden, und die Standardkonfiguration wird selten hinterfragt. Genau diese Standardkonfiguration ist hier das eigentliche Problem, nicht ein Fehler im NemoClaw-Code selbst.
Wer KI-Agenten mit Zugriff auf Quellcode, interne Systeme oder Kundendaten betreibt, sollte lokale Modell-Backends grundsätzlich wie jeden anderen internen Dienst behandeln: mit klarer Netzwerksegmentierung, Authentifizierung bei Bedarf und Protokollierung sicherheitsrelevanter Endpunkte. Modellkonfigurationsvergiftung ist ein neueres Angriffsmuster, das mit zunehmender Verbreitung lokaler KI-Agenten an Bedeutung gewinnen dürfte, gerade weil viele Teams noch keine etablierten Prüfroutinen für Modellintegrität haben.
Passende Anleitungen auf S-EDV
- Ollama mit Open WebUI per Docker selbst hosten: zeigt die saubere Docker-basierte Installation von Ollama inklusive Netzwerkkonfiguration, relevant für alle, die die API-Bindung jetzt korrigieren wollen.
- OpenHands als KI-Coding-Agenten per Docker selbst hosten: praktischer Vergleichsfall für einen containerisierten KI-Coding-Agenten mit eigener Sandbox-Isolation.
