Plateforme d'agents AWS Loom : accès administrateur non authentifié et SSRF dans les connecteurs MCP/A2A

What is this?

Le 2 octobre 2026, AWS a publié deux bulletins de sécurité concernant ses outils pour agents. Le bulletin 2026-124-AWS porte sur Loom, une plateforme open source d’AWS Labs qui orchestre des agents IA, des serveurs d’outils MCP et des connexions d’agents distants A2A. Le bulletin 2026-125-AWS porte sur le script de démarrage des Studio Spaces d’Amazon SageMaker Unified Studio (images SageMaker Distribution). AWS les classe tous deux « Important ». GBHackers les a résumés le 5 octobre 2026. Le bulletin remercie Kenneth Cox pour sa collaboration à la divulgation coordonnée des failles Loom ; le bulletin SageMaker ne nomme aucun chercheur.

Cet article est un résumé défensif des bulletins de l’éditeur. Il ne contient aucun détail d’exploitation au-delà de ce qu’AWS a lui-même publié.

How it works

Les problèmes de Loom sont trois faiblesses distinctes dans un même plan de contrôle :

1. Authentification absente. Dans les déploiements sans fournisseur d’identité configuré, n’importe quel client réseau pouvait obtenir le contrôle administrateur complet. Selon AWS, cela incluait l’enregistrement de serveurs d’outils, la lecture des identifiants d’intégration stockés et la réécriture des politiques IAM des rôles d’agents gérés. Corrigé dans Loom 1.6.1 (publié le 2026-08-04).
2. Divulgation d’identifiants via des requêtes sortantes. Un utilisateur disposant du scope mcp:write ou a2a:write pouvait amener le backend à envoyer des secrets client OAuth2, ou le jeton d’accès d’un autre utilisateur, vers un point de terminaison tiers. La version 1.6.1 bloquait les adresses internes sur ce chemin mais ne fermait pas complètement la fuite de jetons ; Loom 1.7.0 la corrige.
3. Falsification de requêtes internes dans les connexions MCP/A2A. Les mêmes scopes d’écriture permettaient de diriger le backend vers des emplacements réseau internes arbitraires, y compris le point de terminaison de distribution d’identifiants du conteneur, et d’en lire les réponses. Corrigé dans la 1.7.0.

Le problème SageMaker est une injection de commandes système dans le script de démarrage des Spaces. Le script vérifie l’accès réseau par rapport aux connexions SageMaker d’un projet, mais les détails de connexion n’étaient pas correctement assainis. Un membre de projet avec des droits de contributeur ou supérieurs pouvait exécuter du code dans l’Space d’un autre membre et, lorsque la Trusted Identity Propagation est activée, obtenir les identifiants temporaires du rôle d’exécution de ce membre.

Why it matters

Un plan de contrôle d’agents concentre la confiance : il stocke des secrets d’intégration, décide quels serveurs d’outils les agents peuvent appeler et peut détenir des permissions de modification d’IAM. Une absence d’authentification y transforme un service accessible par le réseau en compte administrateur, et les failles des connecteurs montrent comment « peut enregistrer un serveur MCP » peut devenir « peut lire les identifiants que détient la plateforme ». Le même schéma se retrouve dans l’infrastructure d’agents, où le composant qui se connecte aux outils est lui-même un client côté serveur de grande valeur.

Defenses

• Mettez Loom à jour vers la 1.7.0 et corrigez tout fork ou code dérivé, comme le recommande AWS.
• N’exposez jamais le backend sans fournisseur d’identité. Configurez un pool d’utilisateurs Amazon Cognito ou un IdP externe actif avant de l’exposer au-delà de la boucle locale, et vérifiez que LOOM_ALLOW_UNAUTHENTICATED_LOCAL_DEV n’est défini dans aucun environnement déployé.
• Restreignez les scopes d’écriture. Limitez mcp:write et a2a:write aux administrateurs de confiance (groupes g-admins-super, g-admins-mcp, g-admins-a2a et g-admins-demo). AWS précise que cela réduit le risque mais ne remplace pas le correctif.
• Après la mise à jour, faites une rotation. Renouvelez les secrets client OAuth2 des intégrations MCP/A2A, révoquez et réémettez les jetons actifs pendant la période concernée et, si les identifiants du rôle du conteneur ont pu être atteints, renouvelez les identifiants de session du rôle IAM et examinez CloudTrail à la recherche d’activité inattendue.
• Redémarrez les Studio Spaces SageMaker. Le correctif est déployé globalement et s’applique au prochain démarrage de l’Space. Aucun contournement n’est indiqué. Les versions des lignes en fin de support (2.8.x à 2.13.x et 3.3.x à 3.8.x) n’ont pas de correctif et doivent migrer vers une ligne prise en charge.
• Durcissez la couche des connecteurs de façon générale : résolvez et validez les adresses de destination au moment de la connexion, bloquez les plages de métadonnées et link-local, et donnez à chaque agent son propre rôle étroitement limité.

Status

Élément	Statut	Référence
Contournement d’authentification Loom (versions antérieures à 1.6.1)	Corrigé dans 1.6.1 (2026-08-04) et 1.7.0	CVE-2026-103956
Divulgation de jetons et secrets OAuth2 Loom (antérieur à 1.7.0)	Corrigé dans 1.7.0	CVE-2026-103957
Falsification de requêtes internes MCP/A2A Loom (antérieur à 1.7.0)	Corrigé dans 1.7.0	CVE-2026-103958
Injection de commandes au démarrage des Spaces SageMaker Distribution	Corrigé dans 2.14.12, 3.9.12, 4.0.11, 4.1.11, 4.2.8, 4.3.5, 4.4.3 ; 4.5.x non affecté	CVE-2026-104019