Une page web malveillante pouvait atteindre le serveur de modèles local situé derrière un déploiement vulnérable de NVIDIA NemoClaw et modifier le modèle utilisé par un agent d’IA.
NVIDIA a corrigé la faille, référencée sous le nom CVE-2026-65105, le 25 août. L’entreprise lui attribue une gravité élevée, avec un score CVSS de 8,1, et indique que les versions 0 à 0.0.25 de NemoClaw pour Linux sont concernées. Une exploitation réussie peut entraîner une divulgation d’informations ou un déni de service.
NemoClaw peut exécuter des agents OpenClaw dans des sandboxes OpenShell tout en utilisant Ollama pour l’inférence locale. Cette faiblesse atteint la couche d’inférence sous-jacente à ces contrôles, ce qui s’ajoute aux préoccupations soulevées par les vulnérabilités récentes d’OpenClaw concernant l’infrastructure des agents, les privilèges et les limites des sandboxes.
Comment la faille de NemoClaw expose l’inférence locale
Dans son bulletin de sécurité consacré à CVE-2026-65105, NVIDIA classe la faille comme CWE-306, soit l’absence d’authentification pour une fonction critique. Son vecteur CVSS indique une faible complexité d’attaque, l’absence de privilèges requis et d’interaction utilisateur, ainsi qu’un vecteur d’attaque sur le réseau adjacent.
Dans la configuration examinée par Oasis Security, NemoClaw lançait Ollama avec OLLAMA_HOST=0.0.0.0:11434, exposant le service sur toutes les interfaces réseau au lieu de le limiter à la boucle locale. Comme l’API d’Ollama n’exige aucune authentification, les systèmes capables d’atteindre le service pouvaient interagir directement avec lui.
Les chercheurs d’Oasis ont démontré une attaque par rebinding DNS qui permettait au code JavaScript du navigateur d’atteindre Ollama dans la configuration vulnérable. Ils ont ensuite utilisé le /api/createpoint de terminaison pour modifier le modèle de conversation, qui contrôle la mise en forme des messages avant l’inférence.
Les instructions insérées ont persisté lors des conversations suivantes et sont restées actives même lorsque l’agent fournissait une autre invite système. Dans leur preuve de concept, les chercheurs ont répété une requête après avoir empoisonné le modèle sous-jacent et obtenu une réponse contenant un marqueur injecté, sans modifier directement l’agent placé dans la sandbox.
Des problèmes d’isolation similaires sont apparus ailleurs dans les outils de développement de l’IA. Lors de Black Hat 2026, des chercheurs ont révélé des failles critiques dans des agents de codage IA susceptibles d’exposer des identifiants et des environnements de développement via des entrées non fiables.
NVIDIA corrige la faille tandis que les équipes renforcent leurs contrôles
NVIDIA indique que les versions 0 à 0.0.25 sont concernées et identifie le commit f06796ff3, associé à la version 0.0.25, comme contenant la mise à jour de sécurité. Comme la version 0.0.25 apparaît à la fois dans les champs des versions concernées et mises à jour, les administrateurs doivent vérifier que le code déployé contient le commit correctif plutôt que de se fier au seul numéro de version.
Les organisations peuvent réduire davantage leur exposition autour des services d’inférence locale :
- Mettez à jour les déploiements concernés et vérifiez le correctif. Vérifiez que le code NemoClaw déployé contient le commit correctif de NVIDIA.
- Limitez Ollama aux accès via la boucle locale. Maintenez le backend sur
127.0.0.1sauf si un accès plus large est explicitement requis. - Exigez une authentification pour les accès distants. Placez un proxy authentifié et des contrôles de pare-feu devant les services d’inférence.
- Surveillez les dérives de configuration et d’exécution. Surveillez les interfaces en écoute, les modèles de conversation, les paramètres et l’activité sensible des API afin de détecter toute modification inattendue.
- Appliquez le principe du moindre privilège aux agents d’IA. Limitez les dépôts, systèmes CI/CD, API, ressources cloud et identifiants auxquels ils peuvent accéder ; une gouvernance formelle de l’IA agentique peut définir et faire respecter ces limites.
- Établissez une configuration de référence des modèles. Conservez des modèles de conversation et des paramètres connus comme fiables afin de détecter les altérations et de faciliter la restauration.
- Testez les plans de réponse aux incidents. Mettez à l’épreuve des scénarios d’empoisonnement de modèles et d’exposition de l’inférence, notamment l’isolation, les contrôles d’intégrité, la rotation des identifiants et la restauration.
CVE-2026-65105 montre pourquoi les serveurs d’inférence et la configuration des modèles nécessitent les mêmes contrôles d’authentification, de segmentation, de surveillance et de réponse aux incidents que ceux appliqués aux autres infrastructures de production dotées de privilèges.
En savoir plus : les attaquants explorent également les techniques d’injection indirecte d’invite qui dissimulent des instructions malveillantes dans des pages web, des documents et d’autres contenus traités par les agents d’IA.