Ce qu’ont fait les chercheurs
Zenity Labs a publié le 8 octobre la première partie d’une chaîne qu’il appelle AgentCorruption. La cible est Amazon Bedrock AgentCore Runtime, le service géré que les entreprises utilisent pour exécuter des agents IA sur AWS.
Les chercheurs ont déployé un agent d’exemple construit avec Strands, le SDK d’agents open source d’AWS, en utilisant son outil intégré http_request. Ils ont ensuite demandé à l’agent d’interroger le point de terminaison de métadonnées d’instance à l’adresse 169.254.169.254 et de relayer la réponse vers un récepteur qu’ils contrôlaient. Il l’a fait. Ils ont reproduit le résultat via l’outil shell du SDK.
La conclusion de Zenity porte sur la plateforme plutôt que sur l’outil : “La micro-VM ne restreignait pas le trafic vers le service de métadonnées”, et “La défaillance d’isolation se situe au niveau de la plateforme, pas de l’outil”.
Ce que les métadonnées ont livré
Le service de métadonnées a renvoyé le nom du rôle d’exécution de l’agent et ses identifiants STS temporaires. Les chercheurs ont confirmé que ces identifiants fonctionnaient entièrement en dehors d’AgentCore : aws sts get-caller-identity renvoyait le rôle assumé par l’agent.
À partir de là, les métadonnées ont continué de livrer. Les données utilisateur ont révélé l’URI de l’image conteneur de l’agent dans Elastic Container Registry. Les étiquettes d’instance ont exposé du matériel de certificat et de clé mTLS ainsi qu’une URL S3 présignée.
Pourquoi un agent les atteignait tous
Le rôle d’exécution est la partie sur laquelle Zenity est la plus dure : “Le rôle qu’AgentCore attache par défaut au runtime de l’agent est bien trop privilégié”. Il portait des permissions de lecture ECR avec caractères génériques, et AgentCore nomme les dépôts d’images de façon prévisible, sous la forme bedrock-agentcore-<nom_agent>.
Cette combinaison a transformé un agent compromis en annuaire de tous les autres agents du même compte et de la même région. Selon les chercheurs, “exécuter notre outil automatisé sur tous les agents découverts nous a donné tout le code source de tous les agents de la région en quelques secondes”. Zenity indique que les prochains billets couvriront les capacités de lecture, d’écriture et de suppression dans AgentCore et d’autres services AWS de la région.
Ce qu’AWS a changé, et ce qu’il dit aujourd’hui
La chronologie de Zenity n’est pas cohérente avec elle-même : le texte indique que les conclusions ont été transmises à AWS le 17 décembre 2025, tandis que son propre tableau date la divulgation du problème IMDS du 25 décembre 2025. Les dates suivantes sont plus nettes. Le 14 février 2026, AgentCore est passé à IMDSv2 uniquement, si bien que les agents nouvellement déployés démarrent avec. Le 12 avril 2026, AWS a répondu et clos le rapport comme “informatif”. Aucun CVE n’a été attribué.
La position d’AWS, dans une déclaration rapportée par The Decoder le 9 octobre, est que la recherche “présente de manière inexacte un comportement attendu et documenté comme une vulnérabilité”. AWS a déclaré qu’un agent ne peut atteindre les ressources d’un autre compte que lorsqu’un développeur a explicitement accordé des permissions à la fois sur le rôle d’exécution et sur la ressource visée, et renvoie à sa documentation sur les permissions du runtime ainsi qu’aux rôles de moindre privilège. The Decoder rapporte qu’AWS a ensuite aussi resserré le rôle d’exécution par défaut, en retirant les permissions d’invoquer d’autres agents, de lire des conversations privées et de récupérer des identifiants dans Secrets Manager.
Le désaccord de fond
Les deux camps s’accordent sur la mécanique et divergent sur la responsabilité. L’argument d’AWS est qu’un rôle par défaut est un point de départ et que la documentation dit de le resserrer. Celui de Zenity est qu’un runtime d’agents géré dont le bac à sable ne bloque pas le service de métadonnées, et dont le rôle par défaut peut énumérer ses voisins, livre un réglage que la plupart des clients ne changeront jamais.
C’est la même discussion que le secteur du cloud a eue à propos des buckets S3 publics, et elle a été tranchée en changeant le réglage par défaut, pas la documentation.
Ce qu’il faut surveiller
Zenity dit qu’il s’agit du premier volet. Les suivants sont ceux qui comptent : l’accès initial aux identifiants est une conclusion sérieuse, mais ce qui a retenu l’attention est le déplacement latéral entre tous les agents d’une région, et cette partie reste à publier en détail.
Pour qui exécute des agents sur AgentCore aujourd’hui, la mesure à prendre ne fait pas débat. Le fournisseur et ses critiques disent la même chose : ne pas passer en production avec le rôle d’exécution par défaut.
