Quand l’agent IA se tourne vers l’intérieur : Loom et ToFu montrent que votre serveur est la cible la plus dangereuse

Si vous exploitez un ensemble d’agents IA sur votre propre serveur Linux, vous pensez probablement au trafic sortant surtout en termes d’accès à Internet : où l’agent envoie des données et depuis quel serveur externe il télécharge du code. Un tel ensemble comprend un orchestrateur qui gère les agents, plusieurs serveurs MCP qui leur fournissent des outils, et parfois une connexion à des services cloud. Les connexions qui causent le plus de dégâts se dirigent souvent vers l’intérieur : vers 127.0.0.1, les adresses du réseau privé et les points de terminaison qui fournissent des identifiants d’accès au cloud ou au conteneur. Les deux publications décrivent des cas où le code d’infrastructure de l’orchestrateur, ou les outils qu’il exécute, ont ouvert de telles connexions vers une adresse choisie par une personne autre que l’administrateur. Dans Loom, cela nécessitait un utilisateur authentifié disposant d’une autorisation appropriée.

Nous examinons ces deux publications ensemble parce qu’elles décrivent le même mécanisme : un agent IA transforme le serveur en proxy utilisé contre ce serveur lui-même. En pratique, il faut définir sur l’hôte une politique de destinations propre à chaque processus d’agent. Il ne faut pas compter sur chaque composant pour filtrer les URL qu’il reçoit.

Ce qui a été publié

Trois vulnérabilités dans Loom. Le 2 octobre 2026, AWS a publié le bulletin de sécurité 2026-124-AWS concernant Loom, une plateforme open source d’AWS Labs pour l’orchestration d’agents IA. AWS recommande de passer à la version 1.7.0 et de vérifier que les forks et le code dérivé intègrent également les correctifs. Selon le bulletin :

• CVE-2026-103956 (contournement de l’authentification, CWE-306 et CWE-1188) : dans les versions antérieures à 1.6.1, lorsque le déploiement ne disposait d’aucun fournisseur d’identité configuré, tout client du réseau pouvait obtenir les droits d’administration complets sur le plan de contrôle des agents. Ces droits permettaient d’enregistrer des serveurs d’outils, de lire les identifiants d’accès enregistrés pour les intégrations et de réécrire les politiques IAM associées aux rôles des agents. La vulnérabilité a été corrigée dans la version 1.6.1, publiée le 4 août 2026.
• CVE-2026-103957 (CWE-918 et CWE-201) : dans les versions antérieures à 1.7.0, un utilisateur authentifié disposant de l’autorisation mcp:write ou a2a:write pouvait définir une adresse de découverte OAuth2. Le document présent à cette adresse demandait au serveur d’envoyer des secrets client OAuth2, ou un jeton d’accès d’un autre utilisateur, à un point de terminaison contrôlé par un tiers. Selon AWS, la version 1.6.1 bloquait l’accès aux adresses internes par cette voie, mais ne corrigeait pas entièrement la fuite de jetons. Le correctif complet a été intégré à la version 1.7.0.
• CVE-2026-103958 (CWE-918) : dans les versions antérieures à 1.7.0, un utilisateur disposant des mêmes autorisations pouvait diriger les connexions aux serveurs d’outils (MCP) et aux agents distants (A2A) vers n’importe quelle destination du réseau interne et lire les réponses. Ces destinations comprenaient aussi le point de terminaison fournissant les identifiants d’accès du conteneur.

Une étude sur 273 serveurs MCP. Le 9 octobre 2026, des chercheurs de Pennsylvania State University, d’Université Montpellier et de Dartmouth College ont publié l’article sur ToFu. Ils ont développé un outil de fuzzing qui produit des tests de sécurité à partir des descriptions que les outils fournissent eux-mêmes au modèle. Ils l’ont exécuté sur 273 serveurs MCP open source, comprenant 3,405 outils. Selon l’article, ils ont trouvé 253 bugs confirmés dans 343 outils répartis sur 118 serveurs. Parmi les résultats : 64 cas de traversée de répertoires, 7 de SSRF, 5 d’exfiltration de données et 3 d’injection de commandes système. La catégorie la plus importante comptait 115 cas de sorties renvoyées sans échappement.

L’article décrit aussi une attaque que les chercheurs appellent Repeat-After-Me : le modèle est invité à répéter un texte qui ressemble à un appel d’outil. La couche d’orchestration interprète cette sortie comme un véritable appel et l’exécute. Selon l’article, ce comportement a été reproduit dans six couches d’orchestration : LangGraph, MAF, ADK 2.0, AutoGen, Strands et CrewAI. Les chercheurs concluent qu’un argument produit par le modèle ne doit pas être considéré comme une entrée fiable, même s’il respecte le schéma de l’outil.

Le même mécanisme à deux niveaux

Dans Loom, le code d’infrastructure de l’orchestrateur lui-même ouvrait des connexions vers toute adresse fournie par l’utilisateur. Ce code gère la découverte OAuth2 et les connexions aux serveurs d’outils et aux agents distants. Dans ToFu, le même mécanisme apparaît un niveau plus bas, à l’intérieur des outils. Dans l’étude de cas présentée dans l’article, un outil de capture d’écran de pages web vérifie uniquement que l’entrée est une URL valide. Selon les chercheurs, un agent influencé par du contenu injecté peut utiliser cet outil pour lire des fichiers du serveur et capturer les pages de services à l’écoute sur l’interface de bouclage ou le réseau privé. Dans un autre serveur MCP, destiné à WordPress, l’outil accédait sans restriction à l’URL de site fournie par le demandeur. Selon l’article, ce bug a été trouvé lors d’une exécution où tous les tests étaient activés. Le journal d’exécution montre une connexion à l’adresse 127.0.0.1.

Dans les deux cas, un composant reçoit une adresse de l’extérieur et ouvre une connexion vers elle depuis le serveur. Du point de vue du réseau, la connexion provient du processus de l’agent. Tout service qui suppose que seule la machine elle-même y accède se trouve donc exposé à ce type de connexion.

Qui contrôle l’URL

Cette condition restreint relativement le cercle des attaquants possibles. Dans les outils, ce cercle est beaucoup plus large. Le modèle de menace de ToFu suppose un attaquant capable d’influencer ce que le modèle lit : instructions utilisateur, contenu récupéré et sorties d’autres outils. Les chercheurs traitent donc tout argument conforme au schéma comme potentiellement hostile. Selon l’article, de nombreux outils comptent implicitement sur le modèle pour filtrer les entrées, alors que celles-ci peuvent être contrôlées par un attaquant. En pratique, l’auteur d’une page web lue par l’agent peut déterminer l’URL à laquelle un outil MCP accédera.

Pourquoi viser l’intérieur

Vue de l’extérieur, une destination interne semble plus sûre qu’une destination sur Internet. Du point de vue de l’attaquant, c’est l’inverse. Les destinations internes peuvent héberger des services qui n’ont pas été durcis parce qu’ils sont « seulement sur localhost », le plan de contrôle des agents eux-mêmes et des points de terminaison qui fournissent des identifiants d’accès. Avec CVE-2026-103958, l’attaquant n’atteint pas seulement le point de terminaison fournissant les identifiants d’accès du conteneur : il lit aussi la réponse. Si les identifiants du rôle du conteneur ont été lus, AWS recommande donc de remplacer les identifiants de session du rôle IAM et de rechercher dans CloudTrail toute utilisation inattendue. Les dégâts passent ainsi du serveur au compte cloud.

Les tests SSRF développés par les chercheurs pour ToFu définissent les destinations interdites de la même manière : adresses de bouclage, plages RFC 1918, adresses link-local et adresses de métadonnées du cloud. Selon le tableau des impacts de l’article, un bug SSRF correspond à une situation où le serveur se connecte à une adresse choisie par l’attaquant, y compris une adresse de ces catégories. Une telle connexion enfreint l’exigence selon laquelle les requêtes du serveur ne doivent atteindre que les destinations prévues.

Pourquoi un correctif au niveau du composant ne suffit pas

Il y a trois raisons à cela. Premièrement, les correctifs arrivent par étapes. Dans Loom, la version 1.6.1 bloquait les adresses internes dans le mécanisme de découverte. Une version supplémentaire a pourtant été nécessaire pour corriger entièrement la fuite de jetons. Deuxièmement, ToFu a trouvé 7 bugs SSRF dans les outils testés. Selon l’article, les analyseurs qui recherchent dans le code une liste fixe d’opérations dangereuses passent à côté d’une propriété comme « la destination est restreinte à une liste d’autorisation ». Il n’existe pas de point précis du code à rechercher pour vérifier cette propriété. Troisièmement, selon l’article, seuls 273 des 1,404 dépôts exposant des outils ont pu être exécutés lors des tests. Les autres n’ont pas pu être compilés, n’ont pas démarré ou exigeaient des identifiants d’accès. Les chiffres décrivent ce qui a pu être testé, et non l’ensemble des dépôts.

Les chercheurs recommandent que chaque outil fasse lui-même respecter les limites qu’il annonce. Cette recommandation est pertinente pour les auteurs d’outils, mais elle ne suffit pas à l’administrateur d’un serveur qui exécute dix outils de dix auteurs différents. L’hôte est l’endroit où vous avez la main. Une règle appliquée à l’adresse à laquelle le processus se connecte réellement ne dépend pas de la manière dont l’URL est écrite. ToFu teste des entrées contenant d’autres représentations des adresses IP, comme la notation octale ou hexadécimale et les adresses IPv4 mappées en IPv6. Au niveau de la connexion, l’adresse a déjà été interprétée et ces différences ne comptent plus.

Le bouclage n’est pas une frontière face à un processus local

La mesure temporaire recommandée par AWS pour CVE-2026-103956 consiste à vérifier qu’un fournisseur d’identité est configuré avant de rendre le backend accessible au-delà de l’interface de bouclage. Limiter l’écoute à cette interface protège contre les clients du réseau, ce qui correspond précisément au problème posé par cette vulnérabilité. Mais cela ne protège pas contre les SSRF : un agent exécuté sur le même hôte atteint 127.0.0.1 sans difficulté. Il faut donc agir des deux côtés. Les plans de contrôle doivent écouter sur l’interface de bouclage, et les processus des agents doivent être limités aux destinations que vous avez explicitement autorisées, sans autre accès à l’interface de bouclage de l’hôte.

Mesures pratiques sur le serveur

Si vous exécutez Loom :

• Passez à la version 1.7.0 et vérifiez que vos forks intègrent aussi les correctifs.
• Avant la mise à jour : assurez-vous qu’un groupe d’utilisateurs Cognito ou un fournisseur d’identité externe est entièrement configuré avant de rendre le backend accessible au-delà de l’interface de bouclage. Vérifiez aussi que la variable LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV n’est définie dans aucun environnement déployé autre qu’un environnement de développement local. C’est la consigne d’AWS. Contrairement à ce qu’indiquait l’article de GBHackers, elle ne se limite pas à la production. Limitez également mcp:write et a2a:write aux administrateurs de confiance. Selon AWS, cette mesure réduit le risque, mais ne le supprime pas sans le correctif.
• Après la mise à jour : remplacez les secrets client OAuth2 des intégrations MCP et A2A. Révoquez et réémettez les jetons qui étaient actifs pendant la période où le système était vulnérable. Si les identifiants du rôle du conteneur ont été lus, remplacez les identifiants de session et examinez CloudTrail.

Pour tout ensemble d’agents :

1. Recensez les orchestrateurs, agents et serveurs MCP exécutés sur le serveur, et ceux qui reçoivent une URL, un nom d’hôte ou une adresse en entrée. Par exemple : outils de récupération de pages et de capture d’écran, webhooks et mécanismes de découverte.
2. Faites écouter les plans de contrôle, les interfaces d’administration et les bases de données sur 127.0.0.1. Vérifiez l’état réel, pas seulement le fichier de configuration.
3. Exécutez chaque agent sous son propre utilisateur, dans un espace de noms réseau distinct ou dans un conteneur distinct, de sorte que son interface de bouclage ne soit pas celle de l’hôte et que les règles du pare-feu puissent identifier son trafic.
4. Pour ces processus, bloquez par défaut l’accès à l’interface de bouclage de l’hôte, aux adresses link-local (169.254.0.0/16 et fe80::/10), aux plages RFC 1918 (10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16) et aux adresses IPv6 privées (fc00::/7). N’autorisez que les destinations internes dont l’agent a réellement besoin, une par une.
5. Ne vous contentez pas de bloquer sans journaliser : consignez chaque tentative d’un processus d’agent d’atteindre une adresse de métadonnées ou un point de terminaison fournissant des identifiants d’accès. Une telle tentative justifie une vérification.
6. Réduisez les autorisations du rôle cloud associé à l’agent. En cas de fuite d’identifiants d’accès, ces autorisations détermineront l’étendue des dégâts.
7. Testez les nouveaux serveurs MCP dans un environnement isolé. Selon l’article, quatre serveurs ont eu des effets sur l’hôte pendant les tests : ils ont supprimé des fichiers hors de l’espace de travail, accédé à un chemin hors du répertoire prévu, fermé des sessions de terminal qui ne leur appartenaient pas et lancé des processus sans limite. Les chercheurs précisent que ces cas constituent une raison supplémentaire d’exécuter ces tests dans un bac à sable.

Comment nuDefend aide

La commande nudefend workloads affiche les outils IA exécutés sur le serveur, notamment les plateformes d’agents et les serveurs MCP, qu’ils tournent directement sur l’hôte ou dans un conteneur. Les informations ayant servi à identifier chaque outil sont affichées à côté de celui-ci.

La commande nudefend egress review affiche, pour chaque outil, les destinations auxquelles il s’est connecté, le volume de trafic par destination et la date de première détection de chacune. Une destination identifiée apparaît sous son nom, accompagné d’une description de son type d’activité. Une destination inhabituelle à laquelle vous ne vous attendiez pas ressort ainsi dans la liste.

Ces informations permettent de définir une politique. Commencez par surveiller les connexions, autorisez les destinations dont l’outil a réellement besoin, puis activez la restriction. Une fois celle-ci activée, l’outil ne peut se connecter qu’aux destinations autorisées. Toute tentative de connexion à une autre destination est bloquée avant que le trafic ne quitte le serveur. nuDefend limite aussi les noms que l’outil peut résoudre. Chaque requête de résolution bloquée est affichée à côté du nom de l’outil.

La commande nudefend expose affiche chaque service à l’écoute sur le serveur et indique qui peut y accéder, du point de vue du serveur lui-même. Un service qui écoute sur 127.0.0.1 ou ::1 est marqué local-only. Si un service auparavant réservé aux accès internes devient accessible de l’extérieur, nuDefend détecte le changement et émet une alerte. Si un service est exposé involontairement, vous pouvez bloquer son port depuis le tableau de bord ou la ligne de commande, après un aperçu indiquant exactement ce qui sera bloqué. Pour en savoir plus, consultez la page sur le trafic sortant et la page sur l’exposition.

En résumé

Les vulnérabilités de Loom et les résultats de ToFu décrivent le même problème à deux niveaux : un composant de l’ensemble d’agents reçoit une adresse d’une personne autre que l’administrateur et ouvre une connexion vers elle depuis le serveur. La destination est souvent le serveur lui-même, le réseau privé ou un point de terminaison qui fournit des identifiants d’accès. Passez Loom à la version 1.7.0 et traitez les identifiants d’accès selon les consignes d’AWS. Au-delà de ces mesures, n’attendez pas que chaque auteur d’outil corrige le traitement des URL. Faites écouter les plans de contrôle sur l’interface de bouclage, isolez chaque agent au niveau réseau et bloquez par défaut l’accès des processus des agents aux destinations internes. Traitez chacune de leurs tentatives d’accès à une adresse de métadonnées comme un événement à examiner.