Lokale KI-Modelle: Wenn eine Webseite dein Modell vergiftet

Eine NemoClaw-Lücke zeigt, wie lokale KI-Modelle über eine besuchte Webseite dauerhaft manipuliert werden. Was dahintersteckt und was du prüfen solltest.

Lokale KI-Modelle gelten als die datenschutzfreundliche Variante: Alles bleibt auf dem eigenen Rechner, nichts wandert in fremde Clouds. Eine am 25. August 2026 veröffentlichte Analyse der Sicherheitsforscher von Oasis Security (Cyera) zeigt jedoch, wie in NVIDIAs Agenten-Stack NemoClaw eine einzige besuchte Webseite ausreicht, um dem lokal laufenden Modell dauerhaft versteckte Anweisungen unterzuschieben.

Wie der Angriff auf lokale KI-Modelle funktioniert

NemoClaw ist NVIDIAs quelloffener Referenz-Stack, um KI-Agenten in OpenShell-Sandboxes zu betreiben. Als lokales Inferenz-Backend kommt unter anderem Ollama zum Einsatz – also genau die Software, mit der viele Leute ihr lokales Modell betreiben.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Der Kern des Problems ist eine Konfigurationsentscheidung. Auf dem Windows-Host-Pfad startet NemoClaw Ollama mit OLLAMA_HOST=0.0.0.0:11434, damit Docker-Desktop-Container den Dienst über host.docker.internal erreichen. Der Dienst lauscht damit auf allen Netzwerkschnittstellen statt nur auf der Loopback-Adresse – und die Ollama-API auf Port 11434 kennt keine Authentifizierung.

Zwei Schutzmechanismen sollten browserbasierte Zugriffe eigentlich blockieren: die Prüfung des Host-Headers und die Cross-Origin-Regeln des Browsers. Beide greifen hier nicht. Sobald die Bind-Adresse nicht mehr Loopback ist, überspringt Ollama die Host-Prüfung. Und die CORS-Schicht wertet die Anfrage als gleichen Ursprung, weil Origin und Host dieselbe Angreifer-Domain tragen. Über DNS-Rebinding – die Angreifer-Domain löst zuerst auf den eigenen Server und dann auf 127.0.0.1 auf – schließt sich die Lücke zur lokalen Maschine.

Warum das schlimmer ist als ein normaler Prompt-Injection-Trick

Der eigentlich interessante Teil ist die Nutzlast. Über den Endpunkt /api/create schreibt der Angreifer ein manipuliertes Go-Template. Dieses Chat-Template bestimmt, wie die strukturierte Nachrichtenliste in Rohtext übersetzt wird, bevor das Modell sie verarbeitet. Die vergiftete Fassung hängt an jede System-Nachricht zusätzlichen Text an – zur Inferenzzeit, bei jeder späteren Konversation.

Damit überlebt die Manipulation den Neustart eines Chats und setzt sich auch dann durch, wenn die Anwendung ihren eigenen System-Prompt mitliefert. Auslesen ließe sich das Template über /api/show durchaus – nur prüft es kein Client. NemoClaw fragt diesen Endpunkt laut Bericht ausschließlich nach Kontextlänge und Tool-Calling-Fähigkeit ab, eine Integritätsprüfung des Templates gibt es im Repository nicht. Die Sandbox hilft hier ebenfalls nicht: Sie schirmt das Endgerät ab, aber wer den Agenten übernimmt, übernimmt dessen Zugriffe und Werkzeuge.

Der Blick in NVIDIAs Advisory lohnt sich

The Hacker News schreibt, die Forschung trage keine CVE-Nummer. Das war zum Redaktionsschluss vermutlich richtig – inzwischen ist es überholt. NVIDIA hat am 25. August 2026 das Security Bulletin 5872 zu NemoClaw und OpenShell veröffentlicht, und darin steht CVE-2026-65105: „NemoClaw for Linux contains a vulnerability in its inference server setup, where a remote attacker may access the inference service without authentication.“ Bewertung: CVSS 3.1 mit 8.1 (hoch), Vektor AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H, CWE-306. Betroffen sind laut Tabelle die NemoClaw-Linux-Versionen 0 bis 0.0.25.

Zwei Dinge fallen dabei auf. Erstens die Lücke zwischen den Bewertungen: NVIDIA stuft die Auswirkung als „Information disclosure“ mit Angriffsvektor Adjacent ein, also aus dem lokalen Netz. Die Forscher beschreiben dagegen eine dauerhafte Übernahme des Agenten über den Browser des Nutzers. Beides kann stimmen und beschreibt trotzdem ein sehr unterschiedliches Risiko – wer nur den CVSS-Wert liest, unterschätzt den Fall.

Zweitens geht die interessantere Nachricht in der Berichterstattung fast unter: Bulletin 5872 umfasst 18 CVEs. Die höchstbewerteten sind nicht die Ollama-Geschichte, sondern zwei OpenShell-Schwachstellen mit jeweils CVSS 9.9 – ein Sandbox-Ausbruch (CVE-2026-65093) und eine unvollständige Eingabe-Sperrliste in der Sandbox-Provisionierungs-API (CVE-2026-65083). Wer nur die Schlagzeile patcht, verfehlt das eigentliche Bild.

Für den unter Windows und WSL nicht behobenen Pfad gibt es keine eigene CVE. Laut Bericht ist das Problem in NemoClaw v0.0.35 für macOS und Linux behoben; für Windows und WSL wurde in v0.0.34 lediglich ein Warnhinweis bei der Installation ergänzt. NVIDIAs Bulletin nennt für CVE-2026-65105 dagegen die Fassung 0.0.25 als korrigierte Version – im Zweifel gilt die Herstellerangabe. Eine bekannte Ausnutzung gibt es nach Angaben der Forscher nicht.

Was das für dich bedeutet

Wer selbst lokale KI-Modelle betreibt, sollte zwei Dinge auseinanderhalten. Der konkrete Fehler betrifft NemoClaw – das nutzen die wenigsten. Das dahinterliegende Muster betrifft praktisch jeden, der Ollama, LM Studio oder eine vergleichbare Lösung laufen hat.

Denn die Ursache ist nicht exotisch: Ein lokaler Dienst ohne Authentifizierung wird von Loopback auf alle Schnittstellen umgestellt, weil sonst der Container nicht drankommt. Eine Bequemlichkeitsentscheidung, wie sie in jedem zweiten Docker-Setup vorkommt. Genau dieser Angriffsweg war bei Ollama schon einmal geschlossen: DNS-Rebinding gegen die Ollama-API wurde 2024 als CVE-2024-28224 von der NCC Group veröffentlicht und mit Version 0.1.29 behoben, indem der Host-Header geprüft wird. Nur greift diese Prüfung eben nicht mehr, sobald die Bind-Adresse nicht Loopback ist – und genau so konfiguriert NemoClaw sie. Die Lehre ist unbequem: Ein gefixter Angriffsweg kommt zurück, sobald eine Ebene darüber die Voraussetzungen wiederherstellt.

Aus Security-Sicht ist das der klassische Denkfehler bei „läuft ja nur lokal“. Localhost ist keine Sicherheitsgrenze. Jeder Browser auf demselben Rechner ist ein potenzieller Client für jeden lokalen Dienst – und der Browser besucht ständig fremde Seiten. Dieselbe Klasse haben wir kürzlich bei unsicheren MCP-Servern gesehen, nur eine Schicht höher im Stack.

Was du jetzt konkret tun solltest

Bind-Adresse prüfen. Unter Linux und macOS: ss -tlnp | grep 11434 beziehungsweise lsof -iTCP:11434 -sTCP:LISTEN. Unter Windows: netstat -ano | findstr :11434 oder Get-NetTCPConnection -LocalPort 11434. Steht dort 0.0.0.0 statt 127.0.0.1, ist der Dienst für mehr erreichbar als gedacht.
Auf Loopback zurückstellen – mit Ersatz. OLLAMA_HOST=127.0.0.1:11434 setzen, wenn keine Container zugreifen müssen. Achtung unter Windows: NemoClaw hinterlegt die Variable dauerhaft als Benutzer-Umgebungsvariable, ein Export in der WSL-Shell ändert daran nichts. Und wer den Port zumacht, bricht die Container-Anbindung über host.docker.internal – davor gehört dann ein Reverse Proxy mit Token-Prüfung, kein offener Port.
Auf die aktuelle Version gehen. Das Projekt ist bei v0.0.114 angekommen; die Schutzfunktion aus v0.0.106 und die Korrekturen aus dem August-Bulletin stecken nur in aktuellen Ständen. Auf dem Windows-/WSL-Pfad gibt es keinen Fix – dort hilft nur, den Aufbau selbst abzusichern oder diesen Pfad zu meiden.
Modelle im Verdachtsfall neu ziehen. Ein manipuliertes Chat-Template lässt sich nicht wegdiskutieren – betroffenes Modell löschen und sauber neu beziehen.
Den KI-Agenten wie einen Benutzer behandeln. Er bekommt Zugangsdaten, Werkzeuge und Netzwerkzugriff. Alles, was du bei einem Dienstkonto beachten würdest – minimale Rechte, kein pauschaler Dateisystemzugriff, keine dauerhaften Tokens – gilt hier genauso.

Wer sich fragt, ob lokale KI-Modelle deswegen die falsche Entscheidung sind: nein. Der Datenschutzvorteil bleibt, das Sicherheitsproblem liegt in der Konfiguration und nicht im Konzept. Wie ein sinnvoller Unterbau dafür aussieht, habe ich im Ratgeber zu NAS, Heimserver und Selfhosting mit lokaler KI zusammengefasst. Wie leistungsfähig lokale Modelle inzwischen sind, zeigt der Blick auf Ollama v0.32.0.

Einordnung: Wie akut ist das?

Keine Panik: Es gibt keine bekannte Ausnutzung, und der Angriff braucht sowohl eine verwundbare Konfiguration als auch einen Browser, der eine präparierte Seite besucht. Die vollständige Kette wurde laut Aussage des Oasis-Forschungsleiters gegenüber The Hacker News unter macOS mit Firefox getestet.

Bemerkenswert ist etwas anderes: NemoClaw hat seit Version 0.0.106 eine Schutzfunktion, die den lokalen Proxy nicht starten lässt, wenn Ollama auf einer Nicht-Loopback-Adresse lauscht. Nur läuft dieser Proxy auf den WSL-Pfaden gar nicht – also genau dort nicht, wo die problematische Konfiguration gesetzt wird. Eine Schutzmaßnahme, die an der einzigen Stelle nicht greift, an der sie gebraucht würde: Das Muster kennt man aus vielen Sicherheitsarchitekturen. Es lohnt sich, bei eigenen Setups zu prüfen, ob die eingebauten Schutzmechanismen im tatsächlich genutzten Pfad überhaupt aktiv sind.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden

Lokale KI-Modelle: Wie eine Webseite dein Modell vergiftet