Amazon Q exécutait la config MCP d'un dépôt, exposant les clés cloud du développeur

De quoi s’agit-il ?

Le 26 juin 2026, Wiz Research a publié une analyse d’une faille de gravité élevée dans Amazon Q Developer, l’assistant de code IA d’Amazon. L’extension chargeait et lançait automatiquement des serveurs Model Context Protocol (MCP) définis dans un fichier situé dans le projet ouvert — .amazonq/mcp.json — dès que le développeur ouvrait le dossier et activait Amazon Q. Aucune invite, aucun consentement, aucune vérification de confiance de l’espace de travail. Les serveurs MCP étant des processus locaux que l’assistant démarre, et ces processus héritant de l’environnement complet du développeur, ouvrir un dépôt piégé pouvait exécuter du code arbitraire avec la session cloud active du développeur. La couverture a suivi via The Hacker News, et Amazon a publié le Bulletin de sécurité 2026-047-AWS.

La faille a été signalée de manière responsable par Maor Dokhanian, de Wiz : découverte le 17 avril, signalée à Amazon le 20 avril, corrigée le 12 mai, puis divulguée publiquement le 26 juin — bien au-delà du délai de divulgation coordonnée, correctif déjà déployé. AWS indique qu’aucune exploitation publique n’est connue.

Comment ça marche

Le problème est une confusion de frontière de confiance, pas un payload astucieux. Quand vous ouvrez un dossier de projet dans un IDE, vous faites implicitement confiance à des dizaines de fichiers de configuration déclaratifs — ils décrivent un comportement, ils n’exécutent pas de code. La configuration MCP brise cette hypothèse : une entrée MCP nomme une commande à lancer.

Une config MCP bénigne paraît ordinaire — un command, ses args et un bloc env qu’utiliserait un outil légitime de base de données ou de build. Amazon Q lisait ce fichier directement à la racine de l’espace de travail et démarrait les serveurs listés, avant que le développeur n’ait relu la moindre ligne. Deux choix de conception combinés ont rendu la situation dangereuse :

• Exécution automatique sans consentement. La config était chargée à l’ouverture du dossier, sans dialogue ni contrôle de confiance : un texte contrôlé par l’attaquant dans le dépôt devenait automatiquement un processus en cours d’exécution.
• Héritage complet de l’environnement. Le processus lancé recevait l’environnement complet du développeur — clés d’accès cloud, jetons de session CLI, secrets d’API, sockets d’agent SSH — donc tout ce qui s’exécutait disposait des identifiants actifs du développeur.

Aucun payload fonctionnel n’est reproduit ici ; le mécanisme est structurel. Dans sa démonstration, Wiz a simplement fait lire l’identité cloud active par la commande lancée et envoyé le résultat à un serveur externe, prouvant qu’un fichier dans un dépôt cloné pouvait basculer de « git clone » à la compromission du cloud. Le même correctif a aussi corrigé un second problème lié : un contrôle de lien symbolique manquant permettant d’écrire des fichiers hors de la frontière de l’espace de travail — la même classe que le RCE par approbation de symlink dans les agents de code.

Pourquoi c’est important

Le runtime qui fait tourner Amazon Q est distribué sur VS Code, JetBrains, Eclipse et Visual Studio : chaque plugin embarquant une ancienne copie était donc exposé. La condition préalable est une habitude quotidienne du développeur : cloner un projet inconnu — une pull request tentante, un paquet typosquatté, ou un « test de code » envoyé lors d’un faux entretien d’embauche — et l’ouvrir. Cela en fait une voie de chaîne d’approvisionnement crédible, de la même famille qu’Agentjacking et que l’écart d’identité et d’identifiants des agents de code, où du contenu de dépôt non fiable devient une commande exécutée avec les droits du propriétaire.

Surtout, ce n’est pas l’erreur d’un seul éditeur. Wiz et d’autres ont documenté la même forme dans tout l’écosystème — Claude Code, Cursor et Windsurf ont chacun vu une config MCP au niveau projet se transformer en exécution de commande, par un chemin légèrement différent. Une configuration transportée dans le dépôt qui configure silencieusement un agent IA est un anti-pattern systémique, pas un bug isolé.

Défenses

La correction durable consiste à traiter tout fichier pouvant se trouver dans un dépôt comme une entrée non fiable, et à exiger un oui explicite avant qu’il ne puisse exécuter du code.

1. Mettre à jour d’abord. Amazon a corrigé la faille dans Language Servers for AWS 1.65.0 ; le bulletin AWS conseille de passer à 1.69.0, qui embarque aussi le correctif de symlink. Le serveur de langage se met à jour automatiquement sauf blocage réseau — recharger l’IDE récupère la dernière version. Versions de plugin minimales corrigées : VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, boîte à outils Visual Studio 1.94.0.0.
2. Soumettre les serveurs MCP au consentement. Charger un serveur MCP depuis la config de l’espace de travail devrait toujours déclencher une invite. Quand votre assistant signale un serveur MCP non fiable, lisez la commande avant d’autoriser, et refusez tout ce que vous n’avez pas ajouté.
3. Réduire l’environnement. Les processus enfants ne devraient recevoir que l’environnement strictement nécessaire, jamais l’ensemble. Gardez les clés cloud et ~/.ssh / ~/.aws hors de portée de tout ce qu’un agent lance.
4. Se méfier des dépôts inconnus. Vérifiez la présence de dossiers .amazonq/ (ou de config d’agent équivalente) inattendus avant d’ouvrir un projet, et ne pointez jamais un agent vers la pull request d’un fork sans surveillance.
5. Adopter la confiance d’espace de travail. Utilisez la fonction de confiance de l’espace de travail de l’IDE pour que les dossiers non fiables ne puissent pas exécuter automatiquement le comportement d’une extension.

Statut

Élément	Référence	Date	Notes
Faille d’exécution auto	CVE-2026-12957 (CVSS 8.5)	Divulgué le 2026-06-26	Amazon Q chargeait la config MCP de l’espace de travail sans consentement
Faille d’écriture symlink	CVE-2026-12958	Divulgué le 2026-06-26	Contrôle de symlink manquant ; corrigé dans la même version
Corrigé dans	Language Servers for AWS 1.65.0 (AWS conseille 1.69.0)	Correctif livré le 2026-05-12	Mise à jour auto sauf blocage réseau
Découvreur	Maor Dokhanian, Wiz Research	2026-04-17 → 2026-06-26	Divulgation coordonnée ; aucune exploitation publique connue
Même classe	Claude Code, Cursor, Windsurf	2025–2026	Config MCP au niveau projet → exécution de commande

Le cadrage honnête n’est pas « un outil IA a eu un bug » — c’est qu’une config transportée dans un dépôt qui configure un agent IA est une entrée exécutable, et que la transformer en processus doit exiger un oui humain explicite. Tant que les agents ne verrouillent pas ce passage par défaut, la défense vous revient : corriger, exiger le consentement pour les serveurs MCP, réduire l’environnement et traiter tout dépôt inconnu comme du code non fiable.