Loom for AWS livrait le contrôle total de ses agents à quiconque sans fournisseur d’identité
Le 2 octobre 2026, AWS publie quatre correctifs pour Loom, sa plateforme open source d’orchestration d’agents IA, et pour SageMaker Unified Studio. Le plus grave, CVE-2026-103956, donne le contrôle administratif complet du plan de contrôle des agents à tout client réseau quand aucun fournisseur d’identité n’est configuré — une leçon qui vaut pour tout déploiement MCP ou A2A.
2 octobre 2026. AWS publie deux bulletins de sécurité qui referment quatre failles dans Loom, sa plateforme open source d’orchestration d’agents IA, et dans Amazon SageMaker Unified Studio. 2 octobre 2026. La plus sévère, CVE-2026-103956, permet à n’importe quel client réseau d’obtenir le contrôle administratif complet du plan de contrôle des agents dès lors qu’aucun fournisseur d’identité n’est configuré. 2 octobre 2026. Trois autres failles exposent des secrets OAuth2, des identifiants AWS temporaires et l’exécution de code dans l’espace d’un autre utilisateur. Pourquoi c’est important : la couche d’orchestration d’agents — MCP et A2A — est devenue une surface d’attaque à part entière, et le défaut d’authentification par défaut est le symptôme le plus clair de sa jeunesse.
Une plateforme d’agents livrée sans authentification par défaut
Loom est l’orchestrateur d’agents AWS : il connecte des serveurs d’outils MCP (Model Context Protocol) et des agents distants A2A (Agent2Agent) à un plan de contrôle central qui détient les identifiants d’intégration et les rôles IAM des agents. La faille CVE-2026-103956 frappe ce cœur. Elle affecte les versions antérieures à 1.6.1 et repose sur un défaut de validation dans la dépendance d’authentification : quand le déploiement ne référence aucun fournisseur d’identité, n’importe quel client réseau peut prendre la main sur le plan de contrôle.
Les conséquences sont mécaniques. Un attaquant peut enregistrer des serveurs d’outils malveillants, lire les identifiants d’intégration stockés, et modifier les politiques des rôles IAM attachés aux agents gérés. AWS classe la faille sous CWE-306 — absence d’authentification sur une fonction critique — et CWE-1188 — initialisation par défaut non sécurisée des permissions. Autrement dit, le défaut n’est pas un dépassement de tampon subtil : c’est un produit qui démarre grand ouvert tant qu’on n’a pas branché d’annuaire.
Trois failles qui suivent la chaîne de l’agent
Les trois autres CVE dessinent le chemin exact d’une escalade à l’intérieur d’une plateforme d’agents.
CVE-2026-103957 porte sur la découverte OAuth2. Un utilisateur authentifié disposant du scope mcp:write ou a2a:write peut pointer le backend vers une URL de découverte well-known contrôlée par l’attaquant, et faire envoyer les secrets clients OAuth2 ou le jeton d’accès d’un autre utilisateur vers cet endpoint. Le correctif 1.6.1 avait bloqué l’accès aux adresses internes sur ce chemin, sans supprimer la fuite de jetons ; seule la version 1.7.0 referme entièrement le problème.
CVE-2026-103958 est une faille de type SSRF dans la logique de connexion des serveurs d’outils MCP et des agents distants A2A. Un utilisateur avec mcp:write ou a2a:write peut forcer la plateforme à se connecter à des destinations internes arbitraires et à en renvoyer les réponses — y compris l’endpoint de distribution d’identifiants du conteneur, qui délivre des identifiants AWS temporaires exploitables dans la limite du rôle concerné.
CVE-2026-104019 quitte Loom pour SageMaker Unified Studio. C’est une injection de commandes OS dans les scripts de démarrage des Spaces SageMaker, due à une mauvaise validation des paramètres de connexion. Un membre d’un projet peut fabriquer des informations de connexion qui exécutent du code dans l’espace d’un autre membre. Si la Trusted Identity Propagation est activée, l’exploitation permet à un contributeur d’obtenir les identifiants de rôle d’exécution temporaires d’un autre membre et d’invoquer des services AWS en son nom.
La leçon vaut au-delà d’AWS
Le fil conducteur de ces quatre failles n’est pas un produit, c’est un pattern. Les plateformes d’agents exposent trois surfaces que les applications classiques avaient appris à fermer : l’authentification du plan de contrôle, la gestion des jetons OAuth2 entre composants, et les appels sortants d’un composant vers l’intérieur du réseau. Loom les cumule, et il le fait sur une base MCP / A2A que beaucoup d’équipes réutilisent telles quelles dans leurs propres agents.
La faille d’authentification par défaut est la plus instructive. Une variable comme LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV existe précisément pour le développement en boucle locale — et AWS recommande de vérifier qu’elle n’est pas définie en production. Ce type de bascule, qui rend un mode pratique en local dangereux en production, est en train de devenir la signature des outils d’agents. Le blog ETTAYEB a déjà documenté le même risque du côté des SDK MCP Python avec le vol d’identifiants OAuth — la répétition confirme que le problème est structurel, pas conjoncturel.
Ce qu’il faut faire
La remédiation est double : monter de version, puis nettoyer les traces.
- 1. Passer Loom en 1.7.0. C’est la version qui referme CVE-2026-103957 et CVE-2026-103958 en plus de CVE-2026-103956. Les forks et déploiements dérivés doivent appliquer les mêmes correctifs.
- 2. Brancher un fournisseur d’identité avant d’exposer. AWS recommande d’exiger un user pool Cognito ou un fournisseur d’identité externe actif avant d’exposer Loom au-delà du loopback.
- 3. Vérifier la variable de développement. Assurez-vous que
LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEVn’est pas définie en production. - 4. Restreindre les scopes d’écriture. Les scopes
mcp:writeeta2a:writedoivent être réservés aux administrateurs de confiance. - 5. Nettoyer après la mise à jour. Faites pivoter les secrets clients OAuth2, révoquez et réémettez les jetons actifs pendant la fenêtre d’exposition, faites pivoter les identifiants de session des rôles IAM potentiellement touchés, et relisez CloudTrail à la recherche d’activités suspectes.
Pour SageMaker, redémarrez les Spaces Studio concernés pour charger les images corrigées — les versions 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5 et 4.4.3 sont corrigées, et la branche 4.5.x n’est pas affectée.
L’agent IA devient une chaîne d’approvisionnement
Le point le plus profond de ces bulletins est que l’agent IA a cessé d’être un outil isolé pour devenir une chaîne d’approvisionnement : un orchestrateur, des serveurs d’outils MCP, des agents distants A2A, chacun avec ses jetons, ses secrets et ses droits. Chaque maillon qui se connecte à un autre est une frontière de confiance, et Loom montre ce qui arrive quand ces frontières ne sont pas traitées comme telles.
Le parallèle avec la supply chain logicielle classique est instructif. Là où un paquet npm malveillant exfiltrait des secrets au moment de l’installation, un serveur d’outils MCP malveillant les exfiltre au moment de l’exécution — et il peut, en plus, atteindre les identifiants du conteneur qui l’héberge. La correction ne consiste pas seulement à patcher Loom, mais à reconnaître que les agents qui se branchent sur un plan de contrôle sont des dépendances d’exécution, pas des extensions de confiance. C’est ce changement de nature — de l’outil à la dépendance — que les équipes doivent intégrer à leurs revues de sécurité.
Verdict
Si vous exploitez Loom, montez en 1.7.0 et branchez un fournisseur d’identité avant toute chose — la correction logicielle seule ne suffit pas si votre déploiement reste sans annuaire. Si vous construisez vos propres agents sur MCP ou A2A, traitez ces quatre CVE comme une liste de contrôle pour votre propre plateforme : authentifiez le plan de contrôle par défaut, verrouillez la découverte OAuth2, et interdisez les connexions sortantes vers les endpoints d’identifiants internes. Le signal le plus net de ces bulletins est qu’AWS lui-même a dû corriger trois fois son orchestrateur d’agents en quatre mois — la surface d’attaque des agents est réelle, et elle n’est pas près de se refermer seule.