Une découverte d’Oasis Security alerte sur un scénario rarement envisagé : une simple page web contrôlée par un attaquant pourrait mener à la mise en danger du modèle local utilisé par des agents IA déployés avec NVIDIA NemoClaw et un moteur d’inférence local comme Ollama. Le cœur du problème ne réside pas dans l’exécution elle‑même, mais dans la manière dont l’API locale est exposée et dont le modèle peut être empoisonné via des paramètres invisibles côté client.
À la date du 25 août 2026, le rapport ne mentionne pas d’exploitation observée. Il n’y a pas non plus de référence CVE, de plage de versions concernées ou de correctif clairement identifié, ce qui complique la vérification côté opérateur.
Pourquoi NemoClaw peut être ciblé
NemoClaw est une pile de référence open source d’NVIDIA pour exécuter des agents, notamment dans des environnements isolés type “sandbox” OpenShell. Dans ce schéma, Ollama fait partie des moteurs d’inférence locaux pris en charge. L’alerte d’Oasis Security vise plus précisément la façon dont NemoClaw démarre Ollama et expose son service API.
Selon le rapport, NemoClaw peut lancer Ollama avec une configuration du type OLLAMA_HOST=0.0.0.0:11434, ce qui lie le serveur de modèle à toutes les interfaces réseau. Une fois cette API joignable, l’attaquant pourrait modifier le chat template de manière à injecter des instructions cachées, appliquées ensuite à chaque nouvelle conversation.
Le piège : un accès API sans authentification
Le rapport insiste sur un point technique : le service exposé sur le port 11434 ne prévoit pas d’authentification. À la place, la protection dépend de couches intermédiaires censées bloquer les requêtes venant d’un navigateur. Le problème apparaît lorsque l’adresse de liaison n’est pas limitée à la boucle locale.
Dans certaines configurations, le contrôle basé sur l’en‑tête Host peut être contourné. Ensuite, la logique CORS peut traiter la requête comme “même origine” si les en‑têtes Origin et Host correspondent au domaine de l’attaquant. Concrètement, une page servie par l’agresseur sur le même port peut déclencher des appels au service local.
DNS rebinding : le pont entre le navigateur et localhost
Pour que l’exploit fonctionne dans un contexte navigateur, le rapport décrit l’enchaînement classique de DNS rebinding. L’attaquant fait d’abord résoudre son domaine vers son propre serveur, puis le même nom de domaine revient vers 127.0.0.1 pendant que le navigateur conserve la perception d’une même origine. Ainsi, des requêtes destinées au domaine de l’attaquant peuvent finir par atteindre le service local d’Ollama.
Le rapport ne précise pas contre quels navigateurs ou systèmes d’exploitation la chaîne a été vérifiée. Néanmoins, la recommandation générale pour ce type d’attaque reste claire : vérifier correctement les en‑têtes Host et Origin côté serveur.
Un précédent connu : la surface d’Ollama et le correctif
Cette technique n’est pas sortie de nulle part. Un avis publié par NCC Group a relié des problèmes d’exposition de l’API d’Ollama à une mauvaise validation du Host header, avec une recommandation d’autoriser uniquement des valeurs prévues. L’avis renvoie aussi à un correctif fourni par Ollama en v0.1.29 (14 mars 2024) et associé à CVE‑2024‑28224.
Le point important pour l’opérateur : même si l’on a déjà traité le risque “DNS rebinding” au niveau d’Ollama, le rapport d’Oasis Security montre une deuxième couche de danger — l’impact devient particulièrement grave lorsqu’un attaquant obtient la capacité de modifier durablement la manière dont le modèle interprète les messages.
Comment l’empoisonnement du chat template se produit
Une fois l’accès à l’API établi, Oasis Security décrit un mécanisme d’empoisonnement via un appel du type /api/create. Le rapport indique que la charge utile injecte une version altérée du template Go qui sert à rendre les tableaux de messages structurés en texte brut avant le traitement par le modèle.
Le template empoisonné ajoute du texte contrôlé par l’attaquant à chaque message de type system au moment de l’inférence. Résultat : des instructions cachées peuvent influencer le comportement de l’agent dès les prochaines interactions.
Le rapport souligne aussi une limite pénible pour le défenseur : l’attaque vise une propriété de niveau “modèle”, et l’application cliente peut être incapable de détecter ou d’empêcher le problème. Oasis Security formule l’idée de manière directe : le client ne peut pas distinguer ce qui a été injecté, car le template altéré n’est pas “visible” pour un consommateur de l’API.
Une protection partielle : la sandbox ne suffit pas
On peut être tenté de penser qu’une sandbox protège l’endpoint. Le rapport insiste toutefois sur le fait que prendre le contrôle de l’agent, c’est aussi prendre le contrôle de ses accès et de ses outils. Autrement dit, même si l’environnement d’exécution isole l’agent d’une partie du système, l’attaque agit en amont : elle modifie la logique de lecture des instructions au niveau du modèle.
En pratique, cela revient à remplacer la “boussole” qui guide l’agent, plutôt qu’à contourner une barrière d’exécution classique.
Des différences selon la plateforme qui changent la probabilité d’exposition
Le rapport ne décrit pas une unique configuration universelle : la manière dont NemoClaw et Ollama se comportent dépend du contexte d’exécution.
- Hôtes hors WSL : Ollama peut être maintenu sur 127.0.0.1:11434 derrière un proxy inverse contrôlé par un mécanisme de jeton. La liaison externe peut alors passer par 0.0.0.0:11435. L’onboarding redémarre un service déjà lié ailleurs pour revenir à la boucle locale.
- Docker Desktop sur WSL : le proxy est contourné, car le conteneur atteint la boucle locale de l’hôte via host.docker.internal.
- Chemin Ollama côté Windows hôte : le paramètre OLLAMA_HOST=0.0.0.0:11434 est défini pour permettre aux conteneurs Docker Desktop d’atteindre le démon. Dans ce scénario, il est aussi question d’un absence d’authentification requise sur le port 11434.
La page d’intégration d’Ollama associée à NemoClaw recommande aussi, dans certains environnements (notamment WSL2 ou conteneur), de définir OLLAMA_HOST=0.0.0.0. Or, le rapport rappelle qu’un tel choix de liaison a déjà été identifié comme facteur d’exposition, typiquement lorsque l’instance sort du périmètre strict de la machine.
Un contrôle supplémentaire : la vérification de binding et ses limites
Le 25 août 2026, The Hacker News indique avoir examiné le dépôt NemoClaw à un commit précis et observé un mécanisme de contrôle : le proxy local refuserait de démarrer si le backend Ollama n’est pas lié à la boucle locale. Ce comportement a été introduit par un changement par défaut antérieur.
Le rapport mentionne toutefois un point clé : la vérification peut être inatteignable dans certains chemins de plateforme où le proxy n’est pas démarré. Dans ce cas, la logique qui devrait empêcher le contournement ne se déclenche pas.
Le fait que la pile puisse ne pas couvrir tous les chemins d’exécution renforce l’idée centrale : il ne suffit pas de raisonner “sandbox + outil local”, car la chaîne d’attaque exploite des écarts de configuration.
L’absence de garde‑fou “template integrity”
Autre observation rapportée après revue du dépôt : il n’existerait pas de contrôle d’intégrité du chat template à l’endroit pertinent. Les appels à /api/show seraient utilisés principalement pour récupérer des informations comme la longueur de contexte native du modèle et ses capacités de “tool calling”. Rien n’empêcherait donc une modification malveillante du template d’être prise en compte lors des futures inférences.
Que peuvent faire les opérateurs dès maintenant
En l’absence de CVE et sans plage de versions clairement indiquée, la meilleure approche consiste à réduire la surface d’exposition et à aligner la configuration sur les bonnes pratiques connues pour Ollama.
- Limiter le binding : éviter de lier l’API de modèle à des interfaces externes quand ce n’est pas nécessaire.
- Assurer la robustesse côté serveur : vérifier que les validations d’en‑têtes (notamment Host et Origin) sont bien en place dans la configuration et les versions utilisées.
- Appliquer les correctifs disponibles : si vous utilisez Ollama, vérifiez que la version inclut les remédiations associées à l’avis connu (notamment autour de CVE‑2024‑28224).
- Surveiller la modification de modèles/templates : même sans preuve d’exploitation à la date du rapport, un contrôle d’historique et de cohérence peut aider à détecter une altération inattendue.
Le rapport indique aussi que NVIDIA documente des recommandations pour ne pas exposer le port 11434 à un réseau local ou à Internet. Toutefois, l’attaque décrite n’exige pas forcément une exposition réseau : elle peut tirer parti du fait que le navigateur de l’utilisateur peut atteindre la boucle locale.
Conclusion : traiter le risque, pas seulement l’endpoint
La mise en danger du modèle local décrite par Oasis Security montre une dynamique plus large : quand un agent IA s’appuie sur des services locaux d’inférence et des API sans authentification stricte, la sécurité doit englober le cycle complet — depuis l’exposition des endpoints jusqu’à la possibilité d’altérer les paramètres de génération comme le chat template.
Même sans exploitation confirmée à la date du 25 août 2026, les mécanismes détaillés (liaison à 0.0.0.0, dépendance à des contrôles d’en‑têtes, DNS rebinding et persistance de l’instruction injectée) constituent un signal clair. Pour les opérateurs, l’enjeu est de réduire la surface et de vérifier que les correctifs pertinents sont effectivement déployés dans l’environnement utilisé.
Source: https://thehackernews.com/2026/08/a-malicious-webpage-could-poison-your.html
