Amazon Web Services a publié le 10 septembre 2026 des correctifs pour deux vulnérabilités liées dans ses outils Security Agent assistés par IA. CVE-2026-87912 concerne le plugin Security Agent d'Amazon aws-agents-for-devsecops avant la version 1.1.0. CVE-2026-87913 concerne le serveur MCP AWS Security Agent avant la version 0.2.0.
Selon AWS, les deux failles viennent de l'absence de vérification du propriétaire d'un compartiment S3 dont le nom est dérivé d'un identifiant de compte AWS public. Un attaquant distant ayant enregistré le nom attendu en premier pourrait recevoir une archive de code privée envoyée pour analyse. AWS précise qu'une telle archive peut contenir des identifiants et l'état de l'infrastructure.
La remédiation est explicite: mettre à niveau le composant concerné, puis vérifier que le compartiment d'entrée appartient au compte AWS attendu. Une mise à niveau ne récupère pas un nom déjà enregistré par un tiers. Les fiches CVE publiques confirment indépendamment les versions, la date de divulgation et le score CVSS de 5,9. Aucune preuve publique ne démontre toutefois une exploitation active ni un nombre d'utilisateurs touchés.
Comment fonctionne le chemin d'exposition
Une analyse de sécurité nécessite souvent d'empaqueter le code source et la configuration dans une archive, puis de la déplacer vers un stockage accessible au scanner. Ici, les composants vulnérables utilisaient un modèle de nom prévisible. Ils ne vérifiaient pas suffisamment que le compartiment résultant appartenait au compte ayant lancé l'analyse.
La frontière de propriété devient alors confuse. L'agent peut être autorisé à analyser du code privé sans que la destination soit autorisée à le conserver. Les dépôts contiennent souvent des fichiers de déploiement, des références d'environnement, des secrets et des définitions d'infrastructure. Une erreur de destination peut transformer une défense en voie d'exposition.
Le problème touche un plugin et un serveur MCP. MCP facilite l'appel d'outils de sécurité par des agents, mais sa connexion ne remplace ni l'autorisation du service ni la vérification de propriété des ressources.
Le correctif est nécessaire, mais insuffisant
AWS indique la version 1.1.0 comme version corrigée du plugin aws-agents-for-devsecops et la version 0.2.0 pour le serveur MCP Security Agent. Les forks et codes dérivés doivent aussi recevoir les changements pertinents.
Les administrateurs ne doivent pas s'arrêter à la mise à jour. AWS demande de vérifier le propriétaire du compartiment d'entrée nommé selon le modèle security-agent-scans, compte et région. Si un tiers contrôle déjà ce nom, l'installation de la version corrigée n'annule pas cet enregistrement.
Une réponse maîtrisée comprend donc quatre contrôles:
- Recenser chaque déploiement et fork des deux composants.
- Confirmer la version installée et la source exacte du paquet.
- Vérifier propriétaire, politique et historique d'accès de chaque compartiment.
- Déterminer si des archives sensibles ont été écrites hors du compte prévu.
Si une exposition est plausible, les équipes devraient renouveler les identifiants concernés, examiner les journaux d'accès et vérifier les systèmes en aval mentionnés dans l'archive. Ces actions dépendent des preuves locales. Le bulletin AWS ne dit pas que toute installation vulnérable a divulgué des données.
Leçon pour la sécurité des agents
La faille montre pourquoi la validation d'un appel d'outil ne peut se limiter à une requête syntaxiquement correcte. Un agent de sécurité peut choisir la bonne opération tout en transmettant des données au mauvais destinataire. Les contrôles d'exécution doivent vérifier identité, propriété, portée et effet attendu à la frontière de la ressource.
Pour une écriture de stockage, l'enveloppe d'action devrait inclure compte cible, région, identifiant du compartiment, chemin de l'objet, chiffrement et conservation. Avant exécution, le propriétaire résolu doit être comparé au propriétaire approuvé. Après exécution, il faut confirmer que l'archive n'a atteint que l'emplacement prévu.
Le guide Maetra sur les contrôles contre l'injection de prompt pour les agents IA explique pourquoi l'usage des outils doit être contraint face à des entrées non fiables. La liste de contrôle d'inventaire des agents IA aide à retrouver agents, dépôts, outils et responsables concernés.
Preuves à conserver
Les équipes devraient conserver versions des paquets, lieux de déploiement, résultats de propriété, politiques, journaux d'accès, historiques des objets, preuves de renouvellement des identifiants et décisions d'incident. Si un fork contient le modèle vulnérable, il faut enregistrer le commit correctif et les tests démontrant qu'un conflit de propriété échoue de manière sûre.
Un dossier d'audit doit distinguer présence de la vulnérabilité, exploitabilité, exposition suspectée et accès confirmé. Confondre ces quatre états produit soit une assurance trompeuse, soit une escalade inutile.
Le guide des preuves pour les audits d'IA propose une structure reliant constats techniques, responsables, décisions et preuve de remédiation.
Analyse Maetra
Ces vulnérabilités se situent au croisement de la sécurité de l'IA et de l'autorisation cloud classique. L'échec ne vient pas d'une tâche malveillante choisie par l'agent. Un processus de confiance n'effectuait pas un contrôle décisif du propriétaire avant de transmettre une archive de grande valeur.
La correction durable dépasse deux mises à jour. Les déploiements d'agents de sécurité devraient inventorier chaque effet externe, le lier à une identité de ressource vérifiée et conserver la preuve que l'état attendu a été atteint. Ils devraient aussi tester collisions de noms prévisibles, ressources intercomptes et hypothèses d'infrastructure obsolètes avant d'élargir les pouvoirs d'un agent.