La chaîne d'exploitation NemoClaw expose Olama à accès non authentifié et modifie les modèles de chat

Ce qui s'est passé (faits confirmés): Oasis Security des chercheurs ont publié un rapport décrivant une chaîne d'exploitation contre la configuration de NemoClaw qui permet à une page Web contrôlée par un attaquant d'accéder sans authentification à une instance locale d'Olama et de modifier le "modèle de chat" du modèle pour insérer des instructions cachées qui persistent dans les conversations ultérieures. Oasis Security déclare qu'elle a signalé le problème à l'équipe de NVIDIA PSIRT avant sa publication; selon le rapport, il n'y a pas d'identificateur CVE, ni une gamme de versions touchées ni une version parché indiquée par Oasis. Aucune exploitation sur le terrain n'a été signalée avant le 25 août 2026.

Comment fonctionne la chaîne d'attaque techniquement (explication technique): Le vecteur profite de deux faits concrets: premièrement, que NemoClaw peut démarrer Olama avec OLLAMA _ HOST = 0.0.0: 11434, ce qui fait que le service d'inférence écoute sur toutes les interfaces plutôt que seulement sur loopback; deuxièmement, que l'API dans le port 11434 ne nécessite pas d'authentification et sa protection contre les origines web dépend des contrôles d'hôte / origine et un proxy tokenisé qui, dans certains paramètres (surtout les itinéraires utilisant WSL / Docker Desktop sur Windows), n'est pas présent ou pas appliqué.

Avec l'API affichée de cette façon, un attaquant peut servir un site Web qui répond d'abord de son domaine légitime et puis, au moyen d'une technique deDNS refus, fait résoudre ce domaine à 127.0.0.1. Le navigateur maintient la même politique source (même origine) et, si le serveur n'apprécie pas correctement l'hôte ou l'origine, le navigateur enverra des requêtes que l'API Olama acceptera comme si elles provenaient de la même source. De là la demande à/ api / créervous pouvez écrire un Go template qui modifie la façon dont les messages structurés sont rendez-vous; le modèle malveillant peut ajouter du texte à chaque message système dans l'heure d'inférence, et ce changement est stocké au niveau du modèle, invisible pour les clients ultérieurs qui utilisent l'API.

Ce qui a été confirmé dans le logiciel: Les revues publiques du dépôt NemoClaw montrent que la version d'août a ajouté une vérification (v0.0.106) qui empêche le proxy local de commencer s'il détecte que le moteur Olama est lié à une interface non loopback - mais cette prévention ne couvre pas toutes les voies d'exécution. En particulier, la route Windows-host / Wsl / Docker Desktop utilisée pour accéder au démon à partir de conteneurs définit habituellement OLLAMA _ HOST = 0.0.0.0 pour permettre cette accessibilité, et NemoClaw ne démarre pas le proxy sur ces routes. De plus, aucune validation de l'intégrité du modèle de chat n'a été trouvée dans le dépôt pour empêcher les modifications à distance du modèle.

Incidences pratiques: Si la chaîne est jouée sur une machine cible, un simple site Web malveillant ouvert dans le navigateur de l'utilisateur local pourrait prendre le contrôle de l'agent Olama servant OpenClaw / OpenShell / NemoClaw. Les conséquences comprennent : la persistance d'instructions malveillantes dans le comportement du modèle (gestion des réponses futures), l'exécution indirecte d'outils que l'agent a connectés (par exemple appels à des exécutables locaux ou des API tierces), l'exfiltration de données locales et la création d'agents « enlevés » agissant comme pivot dans l'environnement de l'opérateur. L'opération n'exige pas que l'API soit accessible depuis le réseau externe : il suffit que le navigateur de l'utilisateur local atteigne le port 11434 sur localhost.

Ce qui est confirmé et ce qui est incertain: Confirmé : l'existence de la méthode (contraignant à 0.0.0.0 + absence d'authentification + rerendering DNS) et que NemoClaw présente des routes de démarrage qui laissent le démon accessible à 0.0.0.0 sur certaines plateformes ; a également confirmé qu'une modification de modèle peut persister au niveau du modèle. Incertain / estimé: quels navigateurs et versions spécifiques sont sensibles dans la pratique (le rapport ne précise pas à quel navigateur / OS la chaîne a été vérifiée), et s'il y a une exploitation active dans des environnements réels au-delà des tests de laboratoire. Il n'existe pas non plus de liste publique des versions concernées ni de patch officiel indiqué par Oasis dans son avis initial.

Mesures spécifiques et vérifiables à mettre en œuvre par les opérateurs(ordonné par facilité et impact):

1) Vérifiez si votre instance locale Olama écoute à 0.0.0.0 et, si oui, changez-la en loopback. Dans les systèmes Linux, par exemple:ss -ltnp-124; grep 11434ounetstat -plntet cochez la colonne « Adresse locale ». Si 0.0.0: 11434 apparaît, reconfigurer l'unité de service pour exporterOLLAMA _ HÔTE = 127.0.0.1: 11434et redémarrez le service.

2) Bloquer l'accès à 11434 à partir d'interfaces réseau non-loopback avec des règles de pare-feu (p. ex. iptables / nftables ou règles de pare-feu Windows) pour empêcher les connexions LAN ou Internet. Cela permet d'atténuer les expositions accidentelles même si la variable environnementale n'est pas corrigée immédiatement.

3) Passez en revue la configuration Docker Desktop / WSL2 sous Windows : ne permettez pas aux conteneurs ou WSL d'accéder au démon dans l'hôte via host.docker. interne ou public obligatoire si ce n'est pas strictement nécessaire. Dans les environnements où cette connectivité est essentielle, appliquer des contrôles supplémentaires (pare-feu local, annuler l'accès aux outils critiques, exécuter l'agent en VM isolé).

4) Limiter la capacité de l'agent : réduire ou désactiver les outils et les capacités d'appel aux API / exécutables que l'agent peut invoquer. Traiter les modèles et leur environnement comme des éléments qui peuvent être compromis; ne pas faire confiance à l'isolement du bac à sable pour protéger les secrets ou accéder aux infrastructures essentielles.

5) Vérifier les modèles et les modèles après suspicion : voir l'API administrative (/ api / spectacleou d'autres voies administratives documentées) pour détecter les changements dans les modèles et le contexte du modèle. Si vous détectez des modèles inattendus, restaurez à partir d'une copie sécurisée ou reformez / réimplémentez le modèle et faites pivoter les identifiants / clés que l'agent pourrait utiliser.

6) Mise à jour et suivi des publications du fournisseur : bien que Oasis Security ait notifié NVIDIA, l'absence d'un CVE ou d'un correctif clair oblige les opérateurs à suivre à la fois le dépôt NemoClaw et les notes Olama et à appliquer des correctifs ou des changements de configuration recommandés par les équipes responsables. Voir la documentation officielle d'Olama sur la sécurité de configuration et de protection contre l'inclinaison DNS: https: / / ollama.com / docs. Pour comprendre la menace technique du DNS et comment l'atténuer dans les applications Web, voir la documentation du PAOAO : https: / / owasp.org / www-community / attaques / DNS _ Reliure.

Recommandations pour les utilisateurs finaux et les développeurs: Utilisateurs: n'ouvrez pas de pages inconnues ou peu fiables sur les machines où des agents locaux sont développés ou exécutés; fermez les onglets inutiles et évitez d'exécuter des navigateurs avec des privilèges élevés. Développeurs/opérateurs: nécessitent l'authentification dans l'API Inference, valident l'en-tête de l'hôte sur le serveur (permettent seulement des valeurs autorisées) et ajoutent des contrôles d'intégrité sur les modèles de chat et de métadonnées pour s'assurer que les modifications administratives sont enregistrées et revisibles. Les validations Host / Origin et la mise en œuvre de tokenization / proxy devraient fonctionner sur toutes les routes de déploiement, y compris les environnements WSL et Docker Desktop.

Contexte supplémentaire et lecture: La technique de « plantation » des instructions traitant des modèles de rendu rapide a déjà été documentée dans d'autres projets d'agents. En outre, l'atténuation classique pour les attaques DNS inclinables est de vérifier l'hôte sur le serveur et de limiter la liaison au loopback, mesures qui ont déjà été recommandées dans les avis antérieurs liés à Olama.

Bref, il existe une chaîne plausible et documentée pour un navigateur local, utilisant DNS inclinant et une API Oflame liée à 0.0.0.0 sans authentification, pour modifier les modèles de chat et pour modifier le comportement persistant d'un agent. La loi relative à la mise en place d'un dispositif contraignant, à l'application de règles de pare-feu et à la limitation des capacités des agents réduit le risque d'exploitation jusqu'à ce qu'il y ait un dispositif patch et des indications officielles couvrant toutes les voies de déploiement.