NemoClaw CVE-2026-65105 : une seule visite dans un navigateur a réécrit le gabarit de conversation du modèle

Le 25 août 2026, NVIDIA a publié le bulletin de sécurité 5872 et a classé une vulnérabilité dans NVIDIA NemoClaw, l’outil Linux qui exécute des agents OpenClaw dans des environnements sandbox OpenShell, au niveau élevé avec un score de base CVSS de 8,1. CVE-2026-65105 est une vulnérabilité liée à l’absence d’authentification : NemoClaw démarre le serveur d’inférence Ollama sur toutes les interfaces réseau, et l’API d’Ollama ne dispose d’aucune authentification propre. Des chercheurs d’Oasis Security, cités nommément dans les remerciements de NVIDIA et dont l’entreprise est désormais en cours d’acquisition par Cyera, ont réalisé une démonstration dans laquelle une seule visite sur une page web contrôlée par un attaquant a suffi pour atteindre ce serveur depuis l’intérieur du navigateur et réécrire le gabarit de conversation du modèle — une modification qui a survécu aux conversations ultérieures et à la fourniture, par l’agent, de son propre prompt système. Aucune exploitation dans la nature n’a été enregistrée. La fiche complète, avec ses notes de gravité et de confiance, figure dans l’Orca AI Incident Archive aux côtés des incidents voisins du même mois.

Ce que NVIDIA a publié

Le bulletin est intitulé « Bulletin de sécurité : NVIDIA NemoClaw et OpenShell - août 2026 », porte le numéro 5872 et son historique de révisions ne comporte qu’une seule entrée : version 1.0.0, datée du 2026-08-25. Il s’agit d’un récapitulatif, et non d’un avis consacré à une seule CVE — le tableau des produits concernés qu’il contient recense dix-huit CVE réparties entre deux produits, de CVE-2026-65081 à CVE-2026-65105. L’élément le plus important du lot est CVE-2026-65093, une évasion de sandbox dans NVIDIA OpenShell pour Linux, classée 9,9 Critique.

Pour CVE-2026-65105, le bulletin indique que la vulnérabilité « dans la configuration de son serveur d’inférence, où un attaquant distant peut accéder au service d’inférence sans authentification » et qu’une exploitation réussie « peut entraîner une divulgation d’informations et un déni de service ». Le vecteur publié est CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H — réseau adjacent, faible complexité, aucun privilège, aucune interaction utilisateur, impact élevé sur la confidentialité, impact élevé sur la disponibilité — et la classe de faiblesse est CWE-306, « Authentification manquante pour une fonction critique ».

Le tableau des produits affectés de NVIDIA indique les versions affectées comme « 0 à 0.0.25 » pour NemoClaw sous Linux, et la version mise à jour comme « f06796ff3; 0.0.25 » — un hash de commit associé au même numéro de version que celui qui figure dans la colonne des versions affectées. eSecurity Planet, qui rapporte la faille le 27 août 2026, souligne précisément ce chevauchement et conseille aux administrateurs de « vérifier que le code déployé contient le commit de correction plutôt que de se fier uniquement au numéro de version ».

La section des remerciements cite « CVE-2026-65105 : Markus Halvorsen, Elad Luz d'Oasis Security ». La fiche NVD de la CVE a été publiée le 25 août 2026 à 21:17 UTC et modifiée pour la dernière fois le 1er septembre 2026 ; elle comporte le score 8,1 de NVIDIA comme seule évaluation CVSS v3.1, et la CVE n'apparaît pas dans le catalogue Known Exploited Vulnerabilities de la CISA.

Un détail dans la propre entrée de NVIDIA mérite d'être nommé plutôt que passé sous silence. Le vecteur ne comporte aucune composante d'intégrité — I:N, impact sur l'intégrité : aucun — et la description en une ligne ne mentionne que la divulgation d'informations et le déni de service. L'affirmation centrale des chercheurs, examinée ci-dessous, est que le template de chat du modèle a été modifié et l'est resté. Cette lecture du vecteur est la nôtre, pas celle de NVIDIA : l'entreprise n'a publié aucune déclaration indiquant si la piste de la réécriture du template a été prise en compte lors de l'attribution du score.

La configuration qui a rendu un serveur local accessible

NemoClaw déploie des agents OpenClaw dans un bac à sable OpenShell et prend en charge Ollama comme backend d’inférence local. Le problème de configuration est un effet secondaire de cet arrangement. Comme l’explique le compte rendu de recherche de Cyera rédigé par Elad Luz et Ofek Itach, OpenShell s’exécute dans Docker, de sorte qu’un serveur Ollama sur l’adresse de bouclage par défaut est inaccessible depuis l’intérieur du conteneur. NemoClaw démarre donc Ollama avec OLLAMA_HOST=0.0.0.0:11434, ce qui lie le port 11434 sur toutes les interfaces plutôt que uniquement sur la boucle locale de l’hôte. Le même compte rendu note que l’installateur affiche « Using Ollama on localhost:11434 » alors que la liaison réelle est bien plus étendue.

L'API d'Ollama n'a pas d'authentification. Ses défenses côté navigateur sont au nombre de deux : un middleware CORS qui considère une requête dont l'Origin est égal à son Host comme provenant de la même origine et laisse passer les requêtes sans en-tête Origin, et une étape de validation de l'en-tête Host qui, normalement, n'accepte que les noms d'hôte locaux. La seconde défense est celle qui disparaît avec la configuration de NemoClaw. Le compte rendu de Cyera indique explicitement que « lorsque Ollama est lié à une adresse non-loopback (comme 0.0.0.0), la validation de l'en-tête Host est entièrement ignorée » — le code vérifie si l'adresse de liaison est loopback et contourne la vérification dans le cas contraire.

C’est cette combinaison qui fait fonctionner le DNS rebinding. Un visiteur charge une page depuis un domaine contrôlé par l’attaquant, le JavaScript de la page s’adressant au port 11434. Le DNS de l’attaquant résout ensuite à nouveau ce même domaine vers 127.0.0.1 ou vers une adresse du réseau local de la victime. Comme la politique de même origine du navigateur est indexée sur le nom d’hôte, et que le nom d’hôte n’a pas changé, le navigateur continue de traiter la requête comme provenant de la même origine. Ollama la reçoit, ignore la validation de l’en-tête Host parce que sa liaison n’est pas en loopback, et voit Origin égal à Host — les deux étant le domaine de l’attaquant — donc la couche CORS l’autorise. Le résumé de Cyera du résultat est « accès complet et non authentifié à l’API ». L’attaquant n’a besoin de contrôler rien d’autre que son propre domaine ; aucun point d’appui sur le réseau ou l’infrastructure DNS de la victime n’est nécessaire.

Le sandbox ne couvrait pas ce cas, car la faille se situe en dessous. eSecurity Planet décrit le bug comme se trouvant « dans la couche d’inférence sous ces contrôles de sandbox », de sorte que le fait de placer l’agent en sandbox a laissé le serveur de modèle auquel il parle sans protection. Cyera formule le même constat de manière plus générale : « Mettre l’agent en sandbox est nécessaire, mais pas suffisant. » La note de recherche de la Cloud Security Alliance sur ce cas, datée du 27 août 2026, ajoute qu’une liaison non-loopback réactive l’exposition liée à un précédent problème de rebinding d’Ollama suivi sous CVE-2024-28224.

Il faut le dire clairement, car il s'agit d'une voie d'exposition distincte de l'attaque via le navigateur : se lier à 0.0.0.0 expose aussi l'API non authentifiée directement sur le réseau local, de sorte que tout hôte capable d'acheminer du trafic vers le port 11434 l'atteint sans même recourir au rebinding DNS.

D'un modèle lisible à un modèle réécrit

Une fois que JavaScript peut atteindre l’API, la reconnaissance devient banale. Cyera liste ce qui était accessible dans la démonstration : les noms, tailles, familles et quantifications des modèles installés via GET /api/tags, la version exacte d’Ollama via GET /api/version, les détails des modèles, les prompts système, les gabarits et les licences via POST /api/show, ainsi que le nom d’hôte et la clé publique — ou le nom d’utilisateur connecté — via POST /api/me. Les points de terminaison destructeurs étaient également accessibles : POST /api/pull pour télécharger des modèles arbitraires et remplir le disque, POST /api/push pour envoyer des modèles vers ollama.com sous le compte de la victime, DELETE /api/delete pour supprimer les modèles de la victime, et POST /api/signout. Les points de terminaison d’inférence, y compris la route /v1/chat/completions compatible avec OpenAI, exécuteraient des prompts sur le GPU de la victime.

La persistance provenait de l’un de ces endpoints. L’analyse de Cyera explique que l’injection d’un champ système caché via POST /api/create s’est révélée inefficace contre OpenClaw, car l’agent envoie son propre prompt système dans le tableau messages et cela écrase le champ système intégré du modèle. La voie la plus efficace est le champ template que /api/create accepte également. Un template de chat Ollama est un template Go qui contrôle la manière dont les messages sont rendus en texte brut avant l’inférence, et « le template est appliqué au moment de l’inférence à tous les messages, y compris tout prompt système envoyé par le client ». Dans la démonstration, l’attaquant a récupéré le template original via /api/show, y a intégré l’injection tout en conservant le rendu des outils, les tokens spéciaux et le formatage des rôles intacts, puis l’a téléversé à nouveau.

Ce qui découle de ce placement constitue la partie essentielle. Selon Cyera, la modification persiste à travers toutes les conversations futures avec le modèle, survit aux prompts système fournis par le client, est invisible pour l’utilisateur, car le nom, la taille, les métadonnées et les capacités du modèle semblent inchangés, et affecte tous les consommateurs du modèle — clients CLI, clients API et agents confondus. La formulation employée dans l’article est que « le client ne peut ni détecter ni empêcher cela », car le gabarit est « une propriété au niveau du modèle invisible pour les consommateurs de l’API ». CSO Online, qui a rapporté l’affaire le 26 août 2026, cite Luz décrivant le gabarit comme se trouvant « un niveau en dessous de tout ce qu’un garde-fou ou un opérateur peut voir », et note que le changement survit à toutes les sessions futures.

Les conséquences que Cyera énumère pour un agent exécuté sur un modèle piégé sont potentielles, et non observées : l’insertion de vulnérabilités dans le code généré, la suppression d’avertissements de sécurité, l’orientation des recommandations vers des paquets, URL ou configurations contrôlés par l’attaquant, et l’exfiltration de données de conversation ou de fichiers lorsqu’un accès sortant existe. L’analyse prend également soin de préciser ce que le bac à sable limite encore — les actions au niveau de l’hôte sur le système de fichiers, le réseau et les processus — tout en notant que l’accès autorisé de l’agent au contrôle de source, aux systèmes CI/CD, aux API internes, aux services cloud et aux serveurs MCP constitue le véritable point d’exposition.

Ce que la démonstration a montré, et ce qu’elle n’a pas montré

La preuve de concept s’est déroulée en quatre étapes, comme le décrit Cyera. Les chercheurs se sont connectés à un bac à sable NemoClaw et ont envoyé un prompt ; l’agent a répondu normalement. Ils ont ensuite ouvert une page web qui effectuait un DNS rebinding contre le serveur Ollama local. Cette page a lu la version d’Ollama, les modèles installés, le nom d’hôte et la clé publique, et a empoisonné le template du modèle avec une instruction cachée. Le renvoi du même prompt a renvoyé une réponse contenant le marqueur injecté, sans qu’aucune modification n’ait été apportée à l’agent exécuté dans le bac à sable lui-même.

C'est la forme la plus forte de l'affirmation avancée par les chercheurs, et c'est aussi là que commencent les limites du dossier. Il s'agit d'une démonstration dans une configuration spécifique — Ollama lancé avec OLLAMA_HOST=0.0.0.0:11434 — et non d'une étude des systèmes déployés. Aucune victime n'est nommée nulle part dans les sources examinées pour cet article : ni dans le bulletin de NVIDIA, ni dans la fiche NVD, ni dans l'analyse de Cyera, ni dans les articles de CSO Online ou d'eSecurity Planet. Aucun d'entre eux n'a publié de décompte des installations NemoClaw exposées, et aucun ne signale d'exploitation dans la nature. L'absence d'une inscription au catalogue CISA KEV est un fait concernant ce catalogue, et non la preuve que personne n'a essayé.

Un commentaire indépendant est venu de Randolph Barr, de Cequence Security, cité par CSO Online : « Le DNS rebinding est un tour de passe-passe de navigateur depuis plus d’une décennie », a-t-il déclaré, tout en « le dirigeant vers un serveur de modèle local non authentifié, ce qui est la nouveauté ». C’est une description fidèle de la nouveauté ici — la technique du navigateur est ancienne et la catégorie de cible est nouvelle — et c’est aussi un rappel que la divulgation repose sur la démonstration d’une seule équipe de recherche. Aucune réplication indépendante du résultat d’empoisonnement de gabarit n’a été trouvée dans la couverture examinée pour cet article.

Le correctif, et l'écart Windows

Le commit que NVIDIA désigne comme correctif, f06796ff3, est intitulé « fix(security): bind Ollama to localhost with authenticated proxy ». Lu par rapport au dépôt public, il fait trois choses. Il modifie le chemin d’inférence local pour qu’Ollama soit démarré sur 127.0.0.1:11434 au lieu de 0.0.0.0:11434. Il ajoute un petit proxy inverse authentifié, scripts/ollama-auth-proxy.js, qui écoute sur 0.0.0.0:11435 et valide un jeton bearer généré par instance lors de l’onboarding et stocké dans l’identifiant du fournisseur OpenShell, afin que la passerelle conteneurisée puisse toujours atteindre l’inférence tandis que tout ce qui est dépourvu du jeton reçoit un 401 ; GET /api/tags est volontairement exempté pour les contrôles d’état des conteneurs. Et il met à jour le script d’installation et les tests d’inférence locale vers le port du proxy. Le message de commit consigne le ticket interne comme « PSIRT bug 6002780, CVSS 7.5 High », par rapport au 8.1 que NVIDIA a publié plus tard pour la CVE.

L’état de la remédiation au-delà de ce commit est le point où les sources divergent, et cette divergence devrait être signalée plutôt que résolue. CSO Online rapporte que « la faille a désormais été corrigée par Nvidia pour les systèmes non Windows ». La note de la Cloud Security Alliance du 27 août 2026 est plus précise : elle indique que macOS et Linux ont été corrigés dans la v0.0.35, qu’une build ultérieure, la v0.0.106, refuse de démarrer à moins qu’Ollama ne soit lié à la boucle locale, et que « la remédiation de NVIDIA couvre macOS et Linux mais, à la date de publication, ne s’étend pas à Windows ni à WSL ». Selon cette version, le contrôle au démarrage « n’atteint pas le chemin de code utilisé sous Windows et WSL », la v0.0.34 « n’a ajouté qu’un avertissement au lieu d’imposer la liaison à la boucle locale », et « les déploiements Windows et WSL restaient exposés au moment de la divulgation ». Le bulletin de NVIDIA lui-même ne confirme qu’une partie de ces informations : son tableau des produits affectés limite CVE-2026-65105 à Linux, indique un unique commit et une unique version mis à jour, et ne liste aucune entrée Windows, que ce soit comme affectée ou comme corrigée. NVIDIA n’a répondu à cette divergence dans aucun des documents examinés ici.

La déclaration publique de NVIDIA est intervenue après la publication, dans CSO Online : « Nous apprécions la découverte et le rapport des chercheurs », a déclaré l’entreprise, ajoutant qu’« Nvidia a publié une mise à jour que les clients peuvent télécharger et installer ».

Les mesures du côté opérateur énumérées par eSecurity Planet constituent le reste pratique du dossier :

• Mettre à jour NemoClaw et confirmer que le code déployé contient le commit f06796ff3, plutôt que de se fier à la chaîne de version, étant donné que 0.0.25 apparaît à la fois dans la colonne « affecté » et dans la colonne « mis à jour ».

• Limitez Ollama à 127.0.0.1, sauf si un accès plus large est explicitement nécessaire, ce qui supprime la liaison non-loopback à l’origine de l’omission de la validation de l’hôte.

• Placez un proxy authentifié et des contrôles de pare-feu devant les services d’inférence plutôt que de compter sur la frontière réseau propre à l’application.

• Surveillez les interfaces d'écoute, les modèles de modèles, les paramètres de modèle et l'activité de l'API afin de détecter tout changement inattendu, car le modèle empoisonné laisse intacts le nom, la taille et les métadonnées du modèle.

• Conservez des copies de référence fiables des gabarits de modèles et des paramètres pour la détection des altérations et la récupération, et testez les plans de réponse aux incidents pour l’empoisonnement de modèles et l’inférence exposée — isolation, contrôles d’intégrité, rotation des identifiants et restauration.

• Appliquez le principe du moindre privilège à tout ce à quoi l'agent peut accéder : dépôts, systèmes CI/CD, API, ressources cloud et identifiants, car le bac à sable limite les actions sur l'hôte mais pas les droits accordés à l'agent.

Ce qui est établi, ce qui est attribué et ce qui n’est pas connu

Confirmé. NVIDIA a publié le bulletin 5872 le 25 août 2026, avec CVE-2026-65105 notée 8.1 High, CWE-306, affectant NemoClaw pour Linux versions 0 à 0.0.25 et corrigée au commit f06796ff3. Le dossier NVD corrobore le score, le vecteur et la classe de faiblesse indépendamment de la page du bulletin elle-même. La reconnaissance de NVIDIA cite Markus Halvorsen et Elad Luz d'Oasis Security. Le commit public désigné comme correctif modifie le bind vers loopback et introduit un proxy authentifié par jeton sur le port 11435. La CVE ne figure pas dans le catalogue Known Exploited Vulnerabilities de la CISA.

Attribué. Qu'une seule visite de page web suffise à réécrire le gabarit de chat d'un modèle et que cette modification survive aux sessions ultérieures ainsi qu'aux invites système fournies par le client, tel est le constat d'Oasis Security, rapporté dans l'analyse de recherche de Cyera et relayé par CSO Online et eSecurity Planet. Que macOS et Linux aient été corrigés dans les versions v0.0.35 et v0.0.106, tandis que Windows et WSL n'ont fait l'objet que d'un avertissement dans la v0.0.34, c'est là la version de la Cloud Security Alliance ; la version plus concise de CSO Online de cette même affirmation est que le correctif couvre les systèmes non Windows. La liste des conséquences en aval pour l'agent — code vulnérable, avertissements supprimés, paquets dirigés par l'attaquant, exfiltration de données — est la description par Cyera d'effets potentiels, et non d'un résultat observé.

Non établi. Personne n'a publié combien de déploiements NemoClaw ont tourné avec la liaison sur 0.0.0.0, ni combien étaient joignables depuis un réseau adjacent. On ignore si la voie d'empoisonnement a été prise en compte dans le score 8.1 de NVIDIA — le vecteur publié ne comporte aucun impact sur l'intégrité, et NVIDIA n'a rien dit en aucun sens. Aucune victime, aucun rapport d'incident et aucune exploitation en conditions réelles n'a été recensé par une quelconque source examinée ici, et aucun second groupe de recherche n'a publié de réplication.

L'enregistrement lui-même est une conclusion de recherche, et non un événement de déploiement : l'entrée d'archive porte une gravité élevée avec une note de confiance A, ne consigne aucun préjudice réel et l'indique comme non contesté. Cela correspond à ce que montrent les sources — une vulnérabilité bien documentée avec un exploit démontré et aucune victime signalée — et c'est la raison pour laquelle cet article sépare la démonstration de ses conséquences plutôt que de traiter les deux comme une seule affirmation.