CVE-2026-18953 : le Transform MCP Server d'AWS n'avait aucune limite d'écriture

Amazon a publié le bulletin de sécurité 2026-075-AWS le 5 août 2026 concernant la CVE-2026-18953, une traversée de chemin (path traversal) dans l'outil get_resource de awslabs.aws-transform-mcp-server, le serveur open source du Model Context Protocol qui s'exécute sur la machine du développeur lui-même afin qu'un assistant IA puisse piloter des tâches AWS Transform et en récupérer les artefacts. Les versions 0.1.0 à 0.1.4 ne limitaient pas suffisamment les noms de chemin, et le paramètre savePath pouvait écrire des fichiers en dehors du répertoire de travail prévu — ce qui, selon l'avis GitHub publié dans le dépôt d'Amazon, « pourrait conduire à une exécution de code locale ». Amazon lui a attribué une note de 8,6, Élevé. Le correctif est la version 0.1.5, et il n'existe aucun contournement côté serveur ni uniquement par la configuration, car le chemin de code vulnérable est présent dans la configuration par défaut. Aucune source publique n'a enregistré d'exploitation de cette faille. Le dossier complet, avec ses notes de gravité et de confiance, figure dans l'Orca AI Incident Archive aux côtés des incidents MCP et de runtime d'agents enregistrés sous le même mois.

Un serveur MCP qui écrit là où le développeur travaille

Les serveurs Model Context Protocol sont la couche qui fournit à un assistant des outils appelables, et celui-ci est volontairement local. Le bulletin d’Amazon le décrit comme « un serveur MCP open source qui s’exécute localement sur la machine d’un développeur et permet aux assistants alimentés par l’IA d’interagir avec AWS Transform pour exécuter des jobs de transformation de code et récupérer leurs artefacts. » Sa description de paquet sur le Python Package Index indique qu’il expose le cycle de vie de Transform via 19 outils, en gérant les espaces de travail de transformation, les jobs, les connecteurs, les tâches avec intervention humaine, les artefacts et le chat, et qu’il couvre la modernisation des mainframes, la migration VMware, la modernisation .NET et les transformations de code personnalisées.

C’est cet emplacement qui donne toute sa gravité à la faille. Un serveur hébergé sur l’infrastructure d’un fournisseur qui manipule mal un nom de fichier corrompt le stockage de ce fournisseur. Celui-ci s’exécutait avec les privilèges du développeur, dans le répertoire personnel du développeur, à côté de sa configuration shell et de ses clés SSH, et l’impact décrit par Amazon n’est pas un téléchargement corrompu mais une « exécution de code locale ». Tous les scores associés à la CVE s’accordent sur un point : le vecteur d’attaque est local, et non réseau.

L’outil nommé dans l’avis est celui qui télécharge un artefact de tâche sur le disque. get_resource prend un savePath indiquant où le fichier doit être déposé. Le bug est que rien n’empêchait ce chemin de désigner un autre emplacement.

À quel point est-ce grave, et selon l’arithmétique de qui ?

Trois scores sont associés à cette CVE et ils ne concordent pas. Amazon, qui a attribué cette CVE en tant qu'autorité de numérotation, l'évalue à 8,6 (Élevé) selon CVSS v3.1 avec le vecteur CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — local, faible complexité, aucun privilège requis, interaction utilisateur requise, portée modifiée, impact élevé sur la confidentialité, l'intégrité et la disponibilité. L'entrée du NIST dans la National Vulnerability Database porte son propre score principal v3.1 de 8,8 sur un vecteur différent, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H : privilèges faibles requis, aucune interaction utilisateur. Les deux se situent dans la catégorie « Élevé ». Le désaccord porte sur les conditions préalables — si l'acteur doit déjà disposer d'un point d'appui, et si un humain doit être persuadé — et non sur la gravité des conséquences.

Le score CVSS v4.0 d'Amazon pour la même CVE est de 6,3, Moyen, sur CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:H. Lisez les métriques d'impact : rien sur le système vulnérable lui-même, tout est élevé sur le système subséquent. C'est la forme d'une traversée qui franchit les limites propres à un outil — les dégâts sont infligés à tout ce que l'outil peut atteindre, donc cela tombe dans la colonne du sous-système et le système vulnérable obtient un score de zéro.

L’enrichissement du CVE par la CISA, daté du 6 août 2026, enregistre une décision SSVC indiquant Exploitation : aucune, Automatisable : non, Impact technique : total. La fiche du NVD a été modifiée pour la dernière fois le 23 octobre 2026 et présente toujours côte à côte les deux valeurs 8.6 et 8.8. Aucun des deux documents ne considère l’autre comme erroné.

Ce que faisait le code vulnérable, et ce qui a changé dans la 0.1.5

La description du mécanisme par Amazon tient en une phrase et elle est prudente : l’outil « n’a pas suffisamment restreint les noms de chemin », ce qui pourrait permettre à « un acteur dépendant du contexte » d’« écrire des fichiers arbitraires en dehors du répertoire de travail prévu via le paramètre savePath ». L’avis ne définit pas l’acteur, ne dit pas ce qui déclenche l’écriture et ne décrit pas à quoi ressemble un exploit réussi. Il indique seulement que le résultat « pourrait conduire à une exécution de code local ».

La description publique la plus détaillée du mécanisme n'est pas celle d'Amazon. Il s'agit d'un petit dépôt de preuve de concept, ronamosa/CVE-2026-18953, publié sur GitHub le 8 août 2026 sous Apache-2.0 — deux commits, aucune étoile ni aucun fork au moment de la rédaction — qui reproduit mot pour mot les versions vulnérable et corrigée de file_validation.py et fait passer les deux par les mêmes entrées.

Son interprétation de la version 0.1.4 est la suivante : validate_write_path() a résolu savePath avec realpath et expanduser, a rejeté une courte liste de refus d'emplacements (~/.aws, ~/.ssh, ~/.gnupg, ~/.docker, ~/.aws-transform-mcp, /etc/shadow, /etc/passwd) et a retiré les composants de répertoire du nom de fichier fourni. Il n'a jamais confiné le chemin résolu à un répertoire de base ou de travail quelconque. Une liste de blocage de noms de fichiers sensibles — .bashrc, .zshrc, authorized_keys, id_rsa — était appliquée en lecture, mais pas en écriture.

Le dépôt démontre trois écritures que cela autorise : un chemin absolu qui ne nécessite aucune traversée du tout, une évasion relative ../../, et un nom de fichier caché que le chemin de lecture aurait refusé. Les trois aboutissent dans un répertoire temporaire créé par le script, et sa sortie d'exemple montre dropped_by_absolute_path.sh, dropped_by_traversal.sh et un .bashrc sous un répertoire personnel leurre ; le véritable répertoire personnel n'est jamais touché. La version 0.1.5 ajoute la limite manquante : un répertoire de base tiré de $AWS_TRANSFORM_MCP_WRITE_DIR ou le répertoire de travail de démarrage du serveur, sous lequel chaque écriture résolue doit se trouver, ainsi que la liste de blocage des noms de fichiers appliquée au chemin d'écriture résolu final. Le validateur corrigé déclenche « Write path must be within the working directory » pour les trois.

Aucun de ces détails n’apparaît dans l’avis, et le dépôt ne prétend pas qu’ils en proviennent. Considérez la liste de refus, la vérification du nom de fichier en lecture seule et la correction du répertoire de base comme une reconstruction à partir du code source, et non comme un second constat officiel. Ce que le dépôt ajoute au-delà de l’avis, c’est une explication de qui peut fournir le chemin : parce que le rôle du serveur est d’extraire le contenu des jobs et des tâches dans le contexte d’un assistant, la partie qui choisit savePath ne doit pas nécessairement être la personne devant le clavier. Un assistant piloté par du contenu non fiable qu’il a récupéré via le même outil peut prendre la décision. C’est l’argument du dépôt, fondé sur le code et la conception de l’outil, et non une affirmation d’Amazon ; l’« acteur dépendant du contexte » qu’Amazon ne définit pas est compatible avec cet argument, et s’arrête là.

Sept semaines entre le correctif et le bulletin

Le correctif n’est pas arrivé avec l’annonce. L’historique des versions du Python Package Index — métadonnées de première main provenant du registre par lequel le paquet est distribué — date la 0.1.4 du 20 mai 2026 et la 0.1.5 du 17 juin 2026, sept semaines avant la publication du bulletin 2026-075 le 5 août. Il n’y a aucun fichier 0.1.0 sur l’index ; le plus ancien artefact publié dans la plage concernée est la 0.1.1, mise en ligne le 9 mai 2026. Un développeur installant depuis l’index n’aurait donc pu recevoir qu’une version vulnérable entre le 9 mai et le 17 juin, et toute personne suivant les versions était déjà sur du code corrigé à la mi-juin.

Amazon ne précise pas quand elle a eu connaissance du problème, quand le signalement lui est parvenu, ni pourquoi la version qui y a mis fin a été publiée. La seule personne nommée dans le dossier est Drew Raines, remercié à la fois dans le bulletin et dans l'avis GitHub « pour sa collaboration sur ce problème dans le cadre du processus coordonné de divulgation des problèmes ». GHSA-66mr-jr63-2jgw a été publié dans le dépôt awslabs/mcp d'Amazon le 5 août 2026, le même jour que le bulletin ; l'enregistrement CVE a été réservé à 13:44 UTC et publié à 19:33 UTC ce jour-là.

Ainsi, la date du correctif est établie, mais pas sa raison. Une version corrigée présente dans le registre sept semaines avant l’avis est compatible avec un correctif discret suivi d’une divulgation coordonnée — mais il s’agit d’une déduction tirée de deux horodatages, et aucun des deux documents ne l’indique.

Ce que le dossier établit, et ce qu’il n’établit pas

L'archive attribue à cette entrée la note A — bien documentée, les sources primaires concordent — et ne la marque pas comme contestée. Elle la classe comme un dossier de recherche, une découverte de vulnérabilité plutôt qu'un incident de déploiement, sans préjudice réel enregistré. La note porte sur la qualité de la documentation et, au vu des éléments examinés, elle se confirme : le bulletin, l'avis GitHub et l'enregistrement CVE sont trois documents publiés par Amazon qui concordent sur le produit, les versions, le correctif et le crédit.

• Établi.Amazon a publié le bulletin 2026-075-AWS le 5 août 2026 concernant CVE-2026-18953, une traversée de chemin CWE-22 dans la gestion de get_resource par savePath dans awslabs.aws-transform-mcp-server 0.1.0 à 0.1.4, corrigée dans la version 0.1.5, sans solution de contournement côté serveur ni limitée à la configuration, car le chemin vulnérable se trouve dans la configuration par défaut.

• Établi. Les scores et leur divergence : 8,6 Élevé de la part d’Amazon en tant qu’autorité de numérotation CVE, 8,8 Élevé de la part de NIST en tant que score principal NVD, 6,3 Moyen sur CVSS v4.0, et la décision SSVC de la CISA du 6 août selon laquelle aucune exploitation ni aucun chemin automatisable n’avaient été observés.

• Établi. Les dates de publication sur le Python Package Index, ainsi que le crédit accordé à Drew Raines pour la divulgation coordonnée.

• Déduit du code source, par un tiers. La liste de refus, la liste de blocage des noms de fichiers en lecture seule, le répertoire de base absent et le correctif _ALLOWED_WRITE_BASE proviennent tous du dépôt de preuve de concept ronamosa, dont n'importe qui peut comparer les copies intégrées des deux versions du validateur.

• Déduit des horodatages et de la conception. Que la version 0.1.5 était une publication de sécurité délibérée, et qu'un assistant guidé par du contenu non fiable pourrait fournir le chemin malveillant. Amazon n'affirme ni l'un ni l'autre.

• Non établie. Toute exploitation en conditions réelles. La mention « Exploitation : aucune » de la CISA est datée du 6 août, deux jours avant l’apparition de la preuve de concept publique ; elle ne reflète donc que ce moment-là et rien de ce qui a suivi. Aucun décompte des utilisateurs affectés, aucune notification aux clients ni aucune télémétrie n’ont été publiés.

• Non établi.Reportage indépendant. Aucun média grand public ne semble avoir couvert cette CVE. Le dossier public se compose des trois documents d’Amazon, des enrichissements apportés par le NIST et la CISA, des pages de suivi qui reprennent le dossier, et du petit dépôt de preuve de concept décrit ci-dessus.

Ce qui a changé et ce qu'il faut vérifier

La solution d’Amazon consiste en une incrémentation de version et rien d’autre : passer à la version 0.1.5 ou ultérieure, et « veiller à ce que tout code forké ou dérivé soit corrigé afin d’intégrer les nouveaux correctifs ». C’est la seconde clause qui est déterminante. Le serveur est open source, et un fork ayant intégré le validateur 0.1.4 en vendoring hérite de la faille sans hériter de l’avis ; le bulletin demande aux opérateurs de code dérivé de répercuter la modification dans leur code, autrement dit la version amont n’atteint pas une copie maintenue par quelqu’un d’autre.

Le dépôt de preuve de concept suggère quelque chose que l'avis refuse de faire. Les opérateurs qui ne peuvent pas mettre à niveau immédiatement devraient, selon lui, exécuter le serveur avec son répertoire de travail défini sur un répertoire vide dédié et considérer tout fichier dans lequel il peut écrire comme compromis. La position d'Amazon est plus stricte : il n'existe aucun contournement côté serveur ni uniquement de configuration. De l'aveu même du dépôt, cette suggestion est également faible, car le code vulnérable n'a jamais confiné les écritures au répertoire de travail au départ. Là où les deux divergent, l'instruction du fournisseur de mise à niveau uniquement prévaut.

Ce qui est utile dans cette fiche, ce n’est pas son score, mais sa structure : un serveur MCP local, un téléchargement d’artefact avec une destination fournie par l’appelant, et aucune frontière entre les deux. Le contrôle qui compte n’est pas la date du bulletin, mais la version épinglée : 0.1.5 ou ultérieure, et la même modification intégrée dans tout fork qui a copié le validateur.