NemoClaw CVE-2026-65105: Ein einziger Browserbesuch schrieb die Chat-Vorlage des Modells um

Am 25. August 2026 veröffentlichte NVIDIA das Sicherheitsbulletin 5872 und stufte eine Schwachstelle in NVIDIA NemoClaw, dem Linux-Tool, das OpenClaw-Agenten in OpenShell-Sandboxes ausführt, als Hoch mit einem CVSS-Basisscore von 8,1 ein. CVE-2026-65105 ist ein Fehler der fehlenden Authentifizierung: NemoClaw startet den Ollama-Inferenzserver auf jeder Netzwerkschnittstelle, und die Ollama-API verfügt über keine eigene Authentifizierung. Forscher von Oasis Security – in NVIDIAs Danksagungen namentlich genannt; Oasis Security wird derzeit von Cyera übernommen – erstellten eine Demonstration, bei der ein einziger Besuch einer von Angreifern kontrollierten Webseite ausreichte, um diesen Server aus dem Browser heraus zu erreichen und die Chat-Vorlage des Modells umzuschreiben – eine Änderung, die spätere Gespräche überdauerte und auch das Bereitstellen eines eigenen System-Prompts durch den Agenten überstand. Es wurde keine Ausnutzung in freier Wildbahn verzeichnet. Der vollständige Eintrag mit seinen Schweregrad- und Konfidenzstufen steht im Orca AI Incident Archive neben den benachbarten Vorfällen aus demselben Monat.

Was NVIDIA veröffentlicht hat

Das Bulletin trägt den Titel „Sicherheitsbulletin: NVIDIA NemoClaw und OpenShell – August 2026“, hat die Nummer 5872, und seine Revisionshistorie verzeichnet einen einzigen Eintrag: Version 1.0.0, datiert auf den 2026-08-25. Es handelt sich um eine Sammelmeldung, nicht um ein Advisory zu einer einzelnen CVE – die darin enthaltene Tabelle der betroffenen Produkte listet achtzehn CVEs über zwei Produkte auf, von CVE-2026-65081 bis CVE-2026-65105. Der größte Eintrag der Sammlung ist CVE-2026-65093, ein Sandbox-Escape in NVIDIA OpenShell für Linux mit der Bewertung 9,9 Critical.

Für CVE-2026-65105 gibt das Bulletin an, die Schwachstelle liege „im Setup seines Inferenzservers, wo ein entfernter Angreifer ohne Authentifizierung auf den Inferenzdienst zugreifen kann“, und eine erfolgreiche Ausnutzung „kann zur Offenlegung von Informationen und zu Denial-of-Service führen“. Der veröffentlichte Vektor ist CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H — benachbartes Netzwerk, geringe Komplexität, keine Privilegien, keine Benutzerinteraktion, hohe Auswirkung auf die Vertraulichkeit, hohe Auswirkung auf die Verfügbarkeit — und die Schwachstellenklasse ist CWE-306, „Missing Authentication for Critical Function“.

Die Tabelle der betroffenen Produkte von NVIDIA gibt die betroffenen Versionen für NemoClaw unter Linux als „0 bis 0.0.25“ und die aktualisierte Version als „f06796ff3; 0.0.25“ an – ein Commit-Hash, gepaart mit derselben Versionsnummer, die in der Spalte der betroffenen Versionen erscheint. eSecurity Planet, das die Schwachstelle am 27. August 2026 meldete, weist genau auf diese Überschneidung hin und empfiehlt Administratoren, „zu überprüfen, ob der bereitgestellte Code den korrigierenden Commit enthält, statt sich allein auf die Versionsnummer zu verlassen“.

Der Abschnitt „Danksagung“ nennt „CVE-2026-65105: Markus Halvorsen, Elad Luz von Oasis Security“. Der NVD-Eintrag für die CVE wurde am 25. August 2026 um 21:17 UTC veröffentlicht und zuletzt am 1. September 2026 geändert; er enthält NVIDIAs Bewertung von 8.1 als einzige CVSS-v3.1-Bewertung, und die CVE erscheint nicht im Known-Exploited-Vulnerabilities-Katalog von CISA.

Ein Detail in NVIDIAs eigenem Eintrag sollte man benennen, statt es zu glätten. Der Vektor enthält überhaupt keine Integritätskomponente – I:N, keine Auswirkung auf die Integrität – und die einzeilige Beschreibung erwähnt nur die Offenlegung von Informationen und Denial-of-Service. Die zentrale Behauptung der Forscher, weiter unten erläutert, ist, dass das Chat-Template des Modells verändert wurde und verändert blieb. Diese Lesart des Vektors ist unsere, nicht die von NVIDIA: Das Unternehmen hat keine Erklärung dazu veröffentlicht, ob der Pfad zum Umschreiben des Templates bei der Vergabe der Bewertung berücksichtigt wurde.

Die Einrichtung, die einen lokalen Server erreichbar machte

NemoClaw stellt OpenClaw-Agenten in einer OpenShell-Sandbox bereit und unterstützt Ollama als lokales Inferenz-Backend. Das Konfigurationsproblem ist ein Nebeneffekt dieser Anordnung. Wie die Forschungsausarbeitung von Cyera, verfasst von Elad Luz und Ofek Itach, erläutert, läuft OpenShell in Docker, sodass ein Ollama-Server auf der Standard-Loopback-Adresse aus dem Inneren des Containers nicht erreichbar ist. NemoClaw startet Ollama daher mit OLLAMA_HOST=0.0.0.0:11434, wodurch Port 11434 an allen Schnittstellen gebunden wird und nicht nur am Loopback des Hosts. Dieselbe Ausarbeitung merkt an, dass der Installer „Using Ollama on localhost:11434“ anzeigt, obwohl die tatsächliche Bindung deutlich weiter gefasst ist.

Ollamas API verfügt über keine Authentifizierung. Ihre browserbezogenen Schutzmechanismen sind zwei: eine CORS-Middleware, die eine Anfrage, deren Origin gleich ihrem Host ist, als Same-Origin behandelt und Anfragen ohne Origin-Header passieren lässt, sowie ein Host-Header-Validierungsschritt, der normalerweise nur lokale Hostnamen akzeptiert. Der zweite Schutzmechanismus ist derjenige, der unter NemoClaws Konfiguration verschwindet. Cyeras Darstellung ist eindeutig: „Wenn Ollama an eine Nicht-Loopback-Adresse (etwa 0.0.0.0) gebunden ist, wird die Host-Header-Validierung vollständig übersprungen“ – der Code prüft, ob die Bind-Adresse Loopback ist, und umgeht die Prüfung andernfalls.

Diese Kombination macht DNS-Rebinding erst möglich. Ein Besucher lädt eine Seite von einer Domain, die der Angreifer kontrolliert, wobei das JavaScript der Seite Port 11434 anspricht. Das DNS des Angreifers löst dieselbe Domain dann erneut auf 127.0.0.1 oder auf eine Adresse im lokalen Netzwerk des Opfers auf. Da die Same-Origin-Policy des Browsers am Hostnamen festgemacht ist und sich der Hostname nicht geändert hat, behandelt der Browser die Anfrage weiterhin als same-origin. Ollama empfängt sie, überspringt die Host-Validierung, weil es nicht an Loopback gebunden ist, und sieht Origin gleich Host – beides die Domain des Angreifers – sodass die CORS-Schicht sie zulässt. Cyera fasst das Ergebnis als „vollständigen, nicht authentifizierten API-Zugriff“ zusammen. Der Angreifer benötigt nur die Kontrolle über seine eigene Domain; ein Zugangspunkt im Netzwerk oder in der DNS-Infrastruktur des Opfers ist nicht erforderlich.

Die Sandbox deckte dies nicht ab, weil der Fehler darunter liegt. eSecurity Planet beschreibt den Fehler als „in der Inferenzschicht unterhalb dieser Sandbox-Kontrollen“ liegend, sodass das Sandboxen des Agenten den Modellserver, mit dem er kommuniziert, ungeschützt ließ. Cyera macht denselben Punkt allgemeiner deutlich: „Das Sandboxen des Agenten ist notwendig, aber nicht ausreichend.“ Die Forschungsnotiz der Cloud Security Alliance zu dem Fall vom 27. August 2026 ergänzt, dass eine Nicht-Loopback-Bindung die Exposition wieder aufleben lässt, die hinter einem früheren Ollama-Rebinding-Problem steht, das unter CVE-2024-28224 geführt wird.

Es lohnt sich, das klar zu sagen, denn es ist ein separater Expositionspfad gegenüber dem Browser-Angriff: Die Bindung an 0.0.0.0 legt außerdem die nicht authentifizierte API direkt im lokalen Netzwerk offen, sodass jeder Host, der an Port 11434 routen kann, sie ganz ohne DNS-Rebinding erreicht.

Von einer lesbaren Vorlage zu einer umgeschriebenen

Sobald JavaScript die API erreichen kann, ist die Reconnaissance alltäglich. Cyera listet auf, was in der Demonstration erreichbar war: die installierten Modellnamen, Größen, Familien und Quantisierungen aus GET /api/tags, die genaue Ollama-Version aus GET /api/version, Modelldetails, System-Prompts, Templates und Lizenzen aus POST /api/show sowie den Hostnamen und den öffentlichen Schlüssel — oder den angemeldeten Benutzernamen — aus POST /api/me. Auch die destruktiven Endpunkte waren erreichbar: POST /api/pull, um beliebige Modelle herunterzuladen und die Festplatte zu füllen, POST /api/push, um Modelle unter dem Konto des Opfers zu ollama.com zu pushen, DELETE /api/delete, um die Modelle des Opfers zu entfernen, und POST /api/signout. Inferenz-Endpunkte, einschließlich der OpenAI-kompatiblen Route /v1/chat/completions, würden Prompts auf der GPU des Opfers ausführen.

Die Persistenz kam von einem dieser Endpunkte. Cyeras Bericht erklärt, dass das Einschleusen eines versteckten Systemfelds über POST /api/create gegen OpenClaw unwirksam war, weil der Agent seinen eigenen System-Prompt im messages-Array sendet und dieser das integrierte Systemfeld des Modells überschreibt. Der stärkere Weg ist das Template-Feld, das /api/create ebenfalls akzeptiert. Ein Ollama-Chat-Template ist ein Go-Template, das steuert, wie Nachrichten vor der Inferenz in Rohtext gerendert werden, und „das Template wird zum Zeitpunkt der Inferenz auf alle Nachrichten angewendet, einschließlich jedes System-Prompts, den der Client sendet“. In der Demonstration rief der Angreifer das ursprüngliche Template über /api/show ab, fügte die Injektion darin ein, während er Tool-Rendering, Spezial-Tokens und Rollenformatierung intakt ließ, und lud es erneut hoch.

Was sich aus dieser Platzierung ergibt, ist der entscheidende Teil. Laut Cyera bleibt die Änderung in allen künftigen Unterhaltungen mit dem Modell bestehen, übersteht vom Client bereitgestellte System-Prompts, ist für den Nutzer unsichtbar, weil Name, Größe, Metadaten und Fähigkeiten des Modells unverändert erscheinen, und betrifft jeden Nutzer des Modells – CLI, API-Clients und Agenten gleichermaßen. Die Darstellung selbst formuliert es so, dass „der Client dies nicht erkennen oder verhindern kann“, weil die Vorlage „eine Eigenschaft auf Modellebene ist, die für API-Nutzer unsichtbar ist“. CSO Online berichtete am 26. August 2026 über den Fall und zitiert Luz mit den Worten, die Vorlage liege „eine Ebene unter allem, was ein Guardrail oder ein Betreiber sehen kann“, und merkt an, dass die Änderung jede künftige Sitzung übersteht.

Die Folgen, die Cyera für einen Agenten auflistet, der auf einer vergifteten Vorlage ausgeführt wird, sind potenziell und nicht beobachtet: das Einfügen von Schwachstellen in generierten Code, das Unterdrücken von Sicherheitswarnungen, das Lenken von Empfehlungen auf angreifergesteuerte Pakete, URLs oder Konfigurationen und die Exfiltration von Gesprächs- oder Dateidaten, wo ausgehender Zugriff besteht. Die Analyse ist zudem sorgfältig darin, was die Sandbox weiterhin begrenzt – Dateisystem-, Netzwerk- und Prozessaktionen auf Host-Ebene – und merkt an, dass der autorisierte Zugriff des Agenten auf Quellcodeverwaltung, CI/CD, interne APIs, Cloud-Dienste und MCP-Server der Bereich ist, in dem die tatsächliche Exposition liegt.

Was die Demonstration zeigte – und was nicht.

Der Proof of Concept verlief in vier Schritten, wie Cyera ihn beschreibt. Die Forscher verbanden sich mit einer NemoClaw-Sandbox und sandten einen Prompt; der Agent antwortete normal. Dann öffneten sie eine Webseite, die DNS-Rebinding gegen den lokalen Ollama-Server durchführte. Diese Seite las die Ollama-Version, die installierten Modelle, den Hostnamen und den öffentlichen Schlüssel aus und vergiftete die Modellvorlage mit einer versteckten Anweisung. Das erneute Senden desselben Prompts ergab eine Antwort, die den injizierten Marker enthielt, ohne dass am Agenten in der Sandbox selbst etwas geändert wurde.

Das ist die stärkste Form der Behauptung, die die Forscher aufstellen, und zugleich der Punkt, an dem die Grenzen der Dokumentation beginnen. Dies ist eine Demonstration unter einer bestimmten Konfiguration – Ollama gestartet mit OLLAMA_HOST=0.0.0.0:11434 – und keine Erhebung über eingesetzte Systeme. In der für diesen Beitrag gesichteten Berichterstattung wird nirgends ein Opfer genannt: weder in NVIDIAs Bulletin noch im NVD-Eintrag, weder in Cyeras Darstellung noch in den Berichten von CSO Online oder eSecurity Planet. Keine von ihnen hat eine Zahl freiliegender NemoClaw-Installationen veröffentlicht, und keine berichtet von Ausnutzung in freier Wildbahn. Das Fehlen eines Eintrags in der CISA-KEV-Liste ist eine Tatsache über den Katalog, kein Beweis dafür, dass es niemand versucht hat.

Unabhängiger Kommentar kam von Randolph Barr von Cequence Security, zitiert von CSO Online: „DNS-Rebinding ist seit über einem Jahrzehnt ein Partytrick im Browser“, sagte er, während „es auf einen nicht authentifizierten lokalen Modellserver zu richten, das Neue ist“. Das ist eine faire Beschreibung des Neuheitsgrads hier – die Browser-Technik ist alt, die Zielklasse ist neu – und es erinnert zugleich daran, dass die Offenlegung auf der Demonstration eines einzelnen Forschungsteams beruht. In der für diesen Artikel gesichteten Berichterstattung wurde keine unabhängige Reproduktion des Template-Poisoning-Ergebnisses gefunden.

Der Fix und die Windows-Lücke

Der Commit, den NVIDIA als Fix nennt, f06796ff3, trägt den Titel „fix(security): bind Ollama to localhost with authenticated proxy“. Im Abgleich mit dem öffentlichen Repository betrachtet, bewirkt er drei Dinge. Er ändert den lokalen Inferenzpfad so, dass Ollama auf 127.0.0.1:11434 statt auf 0.0.0.0:11434 gestartet wird. Er fügt einen kleinen authentifizierten Reverse-Proxy hinzu, scripts/ollama-auth-proxy.js, der auf 0.0.0.0:11435 lauscht und ein Bearer-Token validiert, das pro Instanz beim Onboarding generiert und im OpenShell-Provider-Credential gespeichert wird, sodass das containerisierte Gateway weiterhin auf die Inferenz zugreifen kann, während alles ohne das Token einen 401 erhält; GET /api/tags ist bewusst für Container-Healthchecks ausgenommen. Und er aktualisiert das Setup-Skript und die Tests für lokale Inferenz auf den Proxy-Port. Die Commit-Nachricht führt das interne Ticket als „PSIRT bug 6002780, CVSS 7.5 High“ auf, gegenüber den 8.1, die NVIDIA später für die CVE veröffentlichte.

Der Behebungsstatus jenseits dieses Commits ist der Punkt, an dem die Quellen auseinandergehen, und die Divergenz sollte berichtet statt aufgelöst werden. CSO Online berichtet, dass „die Schwachstelle inzwischen von Nvidia für Nicht-Windows-Systeme gepatcht wurde“. Die Mitteilung der Cloud Security Alliance vom 27. August 2026 ist konkreter: Sie besagt, dass macOS und Linux in v0.0.35 korrigiert wurden, dass ein späterer Build, v0.0.106, den Start verweigert, sofern Ollama nicht an Loopback gebunden ist, und dass „Nvidias Behebung macOS und Linux abdeckt, sich aber zum Zeitpunkt der Veröffentlichung nicht auf Windows oder WSL erstreckt“. Dieser Darstellung zufolge „erreicht die Startprüfung den auf Windows und WSL verwendeten Codepfad nicht“, v0.0.34 „fügte nur eine Warnung hinzu, statt die Loopback-Bindung zu erzwingen“, und „Windows- und WSL-Bereitstellungen blieben zum Zeitpunkt der Offenlegung exponiert“. Nvidias eigenes Bulletin stützt nur einen Teil davon: Seine Tabelle der betroffenen Produkte ordnet CVE-2026-65105 Linux zu, nennt einen einzigen aktualisierten Commit und eine Version und führt keinen Windows-Eintrag auf, weder als betroffen noch als behoben. Nvidia ging auf diese Diskrepanz in keinem der hier geprüften Dokumente ein.

Die öffentliche Stellungnahme von NVIDIA erfolgte nach der Veröffentlichung in CSO Online: „Wir begrüßen die Entdeckung und den Bericht der Forscher“, sagte das Unternehmen und fügte hinzu, dass „Nvidia ein Update veröffentlicht hat, das Kunden herunterladen und installieren können“.

Die von eSecurity Planet aufgeführten Maßnahmen auf Betreiberseite sind der praktische Rest des Datensatzes:

• Aktualisieren Sie NemoClaw und bestätigen Sie, dass der bereitgestellte Code den Commit f06796ff3 enthält, anstatt der Versionszeichenfolge zu vertrauen, da 0.0.25 sowohl in der Spalte „Betroffen“ als auch in der Spalte „Aktualisiert“ erscheint.

• Beschränke Ollama auf 127.0.0.1, sofern nicht ausdrücklich ein umfassenderer Zugriff erforderlich ist – dadurch entfällt die Nicht-Loopback-Bindung, die dazu führt, dass die Host-Validierung übersprungen wird.

• Stellen Sie einen authentifizierten Proxy und Firewall-Kontrollen vor Inferenzdienste, anstatt sich auf die anwendungseigene Netzwerkgrenze zu verlassen.

• Überwachen Sie Listening-Schnittstellen, Modellvorlagen, Modelleinstellungen und API-Aktivitäten auf unerwartete Änderungen, da die vergiftete Vorlage Name, Größe und Metadaten des Modells unverändert lässt.

• Bewahren Sie bekannt gute Kopien von Modellvorlagen und -einstellungen für Manipulationserkennung und Wiederherstellung auf, und testen Sie Incident-Response-Pläne für Modellvergiftung und offengelegte Inferenz – Isolation, Integritätsprüfungen, Rotation von Anmeldeinformationen und Wiederherstellung.

• Wende das Prinzip der geringsten Rechte auf alles an, was der Agent erreichen kann: Repositories, CI/CD-Systeme, APIs, Cloud-Ressourcen und Zugangsdaten, denn die Sandbox begrenzt Host-Aktionen, aber nicht die Berechtigungen, die dem Agenten erteilt wurden.

Was gesichert ist, was zugeschrieben wird und was nicht bekannt ist

Bestätigt.NVIDIA veröffentlichte am 25. August 2026 das Bulletin 5872 zu CVE-2026-65105, bewertet mit 8.1 High, CWE-306, das NemoClaw für Linux in den Versionen 0 bis 0.0.25 betrifft und mit Commit f06796ff3 behoben wurde. Der NVD-Eintrag bestätigt Score, Vektor und Schwachstellenklasse unabhängig von der eigenen Seite des Bulletins. In der Danksagung von NVIDIA werden Markus Halvorsen und Elad Luz von Oasis Security genannt. Der als Fix genannte öffentliche Commit ändert die Bindung auf Loopback und führt einen token-authentifizierten Proxy auf Port 11435 ein. Die CVE ist nicht in CISA's Known Exploited Vulnerabilities-Katalog enthalten.

Zugeschrieben. Dass ein einziger Besuch einer Webseite ausreicht, um die Chat-Vorlage eines Modells umzuschreiben, und dass die Änderung spätere Sitzungen und vom Client bereitgestellte System-Prompts überdauert, ist die Feststellung von Oasis Security, berichtet in Cyeras Forschungsbericht und aufgegriffen von CSO Online und eSecurity Planet. Dass macOS und Linux in v0.0.35 und v0.0.106 behoben wurden, während Windows und WSL in v0.0.34 nur gewarnt wurden, ist die Darstellung der Cloud Security Alliance; CSO Onlines kürzere Version derselben Behauptung lautet, dass der Patch Nicht-Windows-Systeme abdeckt. Die Liste der nachgelagerten Agentenfolgen – anfälliger Code, unterdrückte Warnungen, vom Angreifer gesteuerte Pakete, Datenexfiltration – ist Cyeras Beschreibung möglicher Auswirkungen, kein beobachtetes Ergebnis.

Nicht belegt. Wie viele NemoClaw-Deployments mit der 0.0.0.0-Bindung liefen und wie viele von einem angrenzenden Netzwerk aus erreichbar waren, hat bislang niemand veröffentlicht. Ob der Vergiftungspfad in NVIDIAs 8.1-Bewertung eingepreist wurde, ist unbekannt – der veröffentlichte Vektor weist keine Integritätsauswirkung auf, und NVIDIA hat sich dazu in die eine oder andere Richtung nicht geäußert. Kein Opfer, keine Vorfallmeldung und keine Ausnutzung in freier Wildbahn wurde von einer der hier geprüften Quellen erfasst, und keine zweite Forschungsgruppe hat eine Replikation veröffentlicht.

Der Eintrag selbst ist ein Forschungsergebnis, kein Deployment-Ereignis: Der Archiveintrag weist hohe Schwere mit einem Vertrauensgrad A aus, verzeichnet keinen realen Schaden und kennzeichnet ihn als unbestritten. Das entspricht dem, was die Quellen zeigen – eine gut dokumentierte Schwachstelle mit einem nachgewiesenen Exploit und ohne gemeldete Opfer –, und das ist der Grund, warum dieser Beitrag die Demonstration von ihren Folgen trennt, statt beides als eine einzige Behauptung zu behandeln.