Contact
Rechercher dans les tutoriels Genisoft ESC
MCP Adapter 0.3.1 : WooCommerce 11.2.2 garde l'ancienne copie
Actualités

MCP Adapter 0.3.1 : WooCommerce 11.2.2 garde l'ancienne copie

Le 4 novembre, MCP Adapter corrige ses branches 0.3 et 0.4, mais WooCommerce 11.2.2 embarque toujours la 0.3.0. Notre test et quoi vérifier sur votre boutique.

Par

Le 4 novembre 2026, l’équipe de MCP Adapter, la brique qui relie un agent IA à WordPress, a publié les versions 0.3.1 et 0.4.2, qui reportent sur ces anciennes branches un correctif de sécurité classé « élevé » et une limite de stockage de session. Le même jour, WooCommerce 11.2.2 est sortie avec, dans son dossier vendor, la copie 0.3.0 non corrigée : nous l’avons vérifié dans notre bac à sable, ainsi que la façon de la remplacer. Cette semaine, regardez si la fonction MCP de WooCommerce est activée ; si oui, installez le plugin MCP Adapter 0.7.1.

Ce qui a été annoncé

Les versions 0.3.1 et 0.4.2 sont parues le 4 novembre, à quelques secondes d’intervalle, sur les branches maintenance/0.3 et maintenance/0.4. Leurs notes tiennent en une ligne : des correctifs rétroportés depuis les branches plus récentes. Le détail est dans les pull requests #432 et #433, qui reportent deux changements.

Le premier corrige la faille de l’avis GHSA-7x77-5r4r-q4rf, publié le 23 octobre avec une gravité élevée (8,1). Quand la fonction de permission personnalisée d’un serveur MCP refusait l’accès en renvoyant un WP_Error, l’adaptateur retombait sur une vérification par défaut que tout utilisateur connecté passe. D’après l’avis, un simple abonné pouvait alors utiliser un serveur prévu pour les administrateurs. L’avis vise le paquet Composer de la version 0.3.0 à la 0.4.1, et donnait jusqu’ici la 0.5.0 comme première version corrigée.

Le second est la limite de stockage de session livrée dans la 0.7.1 du 16 octobre, qui la présente comme un correctif de sécurité. Les paramètres qu’un client envoie à l’ouverture d’une session sont limités à 4 Kio, et ses icônes ne sont plus stockées. Selon ces notes, des données trop volumineuses pouvaient provoquer des échecs répétés d’écriture en base et des journaux excessifs.

Le même jour, WooCommerce 11.2.2 a été publiée comme version de sécurité. Ses notes portent sur la Store API, l’API REST, l’import CSV et des points d’accès d’administration, pas sur MCP. Le fichier composer.lock du tag 11.2.2 fige wordpress/mcp-adapter en v0.3.0.

La suite est déjà tracée. Le billet de WooCommerce du 21 octobre sur MCP dans 11.3 annonce la fin de la copie embarquée : il faudra le plugin MCP Adapter et un mot de passe d’application. La 11.3.0-beta.2 du 2 novembre ne déclare d’ailleurs plus cette dépendance dans son composer.json.

Ce que ça change pour un site WordPress avec WooCommerce

Ce qui suit est notre analyse, à partir du code et de notre test.

Fonction MCP désactivée (réglage par défaut) : la copie ne tourne pas. Fonction activée : c’est la 0.3.0, visée par l’avis, qui sert la route /wp-json/mcp/mcp-adapter-default-server, le serveur par défaut de l’adaptateur.

La faille ne touche pas tous les serveurs de la même façon. Elle ne joue que pour un serveur protégé par une fonction de permission personnalisée qui renvoie un WP_Error. Le point d’accès propre à WooCommerce n’en dépend pas : sa classe WooCommerceRestTransport remplace entièrement la méthode check_permission() et refuse elle-même la requête. Le serveur par défaut n’a pas de fonction personnalisée : il accepte tout compte connecté, par conception, puis chaque outil vérifie ses propres droits. Le risque concret pour une boutique vient donc d’une autre extension qui créerait son propre serveur MCP et le ferait tourner sur la copie de WooCommerce. La limite de session, elle, concerne tout site où la fonction est active.

Le plugin MCP Adapter prend la main. Dans notre test, une fois le plugin 0.7.1 activé, ce sont ses classes qui se chargent, et non celles de WooCommerce : les correctifs s’appliquent tout de suite, dans la configuration que 11.3 exigera.

Notre test

Le 5 novembre 2026, sur notre WordPress de test (7.1.3, sans autre extension active), nous avons installé WooCommerce 11.2.2 depuis wordpress.org, puis le plugin MCP Adapter 0.7.1. Les classes chargées ont été lues par réflexion PHP (wp eval-file), les routes dans l’index REST local. L’essai de session a été fait en administrateur, par une requête REST interne, sans réseau. Sorties brutes et scripts conservés.

EssaiCe que nous avons observé
Version embarquée par WooCommerce 11.2.2vendor/composer/installed.php : wordpress/mcp-adapter en v0.3.0
Code de la copie embarquéeHttpTransport::check_permission() contient encore « Fall through to default permission check » ; SessionManager n’a pas de méthode validate_client_params
Option woocommerce_feature_mcp_integration_enabled après installationno ; aucune route contenant « mcp » dans l’index REST
Fonction MCP activée, WooCommerce seulroutes /mcp et /mcp/mcp-adapter-default-server, servies par plugins/woocommerce/vendor/wordpress/mcp-adapter/
Requête anonyme (GET et POST) sur le serveur par défautHTTP 401 rest_forbidden, avec la copie 0.3.0 comme avec la 0.7.1
Ouverture de session avec des paramètres d’environ 6 Kio, copie 0.3.0acceptée ; la méta utilisateur mcp_adapter_sessions passe à 7 032 octets
Plugin MCP Adapter 0.7.1 activé en plusclasses chargées depuis plugins/mcp-adapter/, WP_MCP_VERSION = 0.7.1
Même ouverture de session, plugin 0.7.1refusée : erreur -32602 « Initialization parameters exceed the 4096 byte session storage limit » ; rien n’est stocké

Le bac à sable a été remis en état : option et méta de session supprimées, plugins désactivés et supprimés, liste des plugins identique à l’état initial.

Limites du test. Nous n’avons pas exécuté la 0.3.1 elle-même : nous avons comparé la copie 0.3.0 au plugin 0.7.1, qui porte les mêmes correctifs, et lu le code 0.3.1 dans le diff entre les deux versions. Nous n’avons pas reproduit la faille de permission. Sur notre installation neuve, la route /wp-json/woocommerce/mcp n’est pas apparue ; d’après le code de 11.2.2, ce serveur n’est créé que si une capacité porte la métadonnée expose_in_deprecated_woocommerce_mcp. Nous n’avons donc pas vérifié qu’un assistant déjà branché sur ce point d’accès continue de fonctionner avec le plugin. Aucun agent IA n’a été connecté.

Que faire cette semaine

  1. Regardez si la fonction MCP est activée. Dans WooCommerce > Réglages > Avancé > Fonctionnalités, ligne « WooCommerce MCP ». Ou, en WP-CLI :

    wp option get woocommerce_feature_mcp_integration_enabled

    no ou une option absente : rien à faire de plus pour cette copie.

  2. Si elle est activée et que vous ne vous en servez pas, désactivez-la. C’est la mesure la plus simple, et elle supprime les routes MCP.

  3. Si vous vous en servez, installez le plugin MCP Adapter, sur une copie de la boutique d’abord :

    wp plugin install mcp-adapter --activate

    Puis vérifiez quelle copie se charge :

    wp eval "echo (new ReflectionClass('WP\MCP\Core\McpAdapter'))->getFileName();"

    Le chemin doit contenir plugins/mcp-adapter/ et non plugins/woocommerce/vendor/.

  4. Cherchez la trace d’un contournement. L’avis indique que les requêtes concernées laissent la ligne « Permission callback returned WP_Error » dans les journaux. Avec WooCommerce, l’adaptateur écrit dans le journal d’erreurs PHP du serveur (ou wp-content/debug.log si la journalisation de débogage de WordPress est active).

  5. Mettez à jour WooCommerce. Au 5 novembre 2026, la version stable sur wordpress.org est la 11.2.2, publiée le 4 novembre ; le plugin MCP Adapter est en 0.7.1. Si un assistant utilise encore l’ancien point d’accès /wp-json/woocommerce/mcp, préparez sa bascule : il recevra une erreur 410 en 11.3.

Pour un développeur de plugins

Si votre extension embarque wordpress/mcp-adapter par Composer en 0.3.x ou 0.4.x, passez à 0.3.1 ou 0.4.2 :

composer update wordpress/mcp-adapter

Une contrainte ^0.3.0, comme celle de WooCommerce, accepte la 0.3.1 : c’est le fichier composer.lock qui la retient en 0.3.0. Si vous ne pouvez pas mettre à jour, l’avis donne un contournement : faire renvoyer false, et non un WP_Error, à votre transport_permission_callback quand il refuse l’accès. Après la mise à jour, l’inverse se vérifie aussi : un WP_Error renvoyé dans un cas légitime bloquera désormais la requête.

À terme, l’intégration par Composer est dépréciée (depuis la 0.7.0) : testez la présence des classes WP\MCP\* à l’exécution, ou déclarez Requires Plugins: mcp-adapter, comme le conseille WooCommerce.

Limites et incertitudes

Questions fréquentes

Ma boutique est-elle exposée si je n’ai jamais touché aux réglages MCP ?

Dans notre test, non : la fonction est désactivée après l’installation de WooCommerce 11.2.2, et aucune route MCP n’est alors enregistrée. La copie 0.3.0 reste présente dans les fichiers, sans être lancée.

Installer le plugin MCP Adapter peut-il casser WooCommerce 11.2.2 ?

Sur notre installation de test, WooCommerce est resté actif et le serveur par défaut a répondu avec les classes du plugin 0.7.1. Nous n’avons pas testé l’ancien point d’accès propre à WooCommerce : faites l’essai sur une copie de la boutique avant la production.

Comment cet article a été produit : faits vérifiés dans les sources primaires listées plus bas ; installation de WooCommerce 11.2.2 et du plugin MCP Adapter 0.7.1, lecture des classes chargées et des routes REST, et essai d’ouverture de session comparant la copie 0.3.0 embarquée au plugin 0.7.1, réalisés le 5 novembre 2026 sur notre WordPress de test 7.1.3 (sorties conservées), plus lecture du diff 0.3.0 → 0.3.1. Rédigé avec l’aide de Claude (Anthropic), puis relu et validé par l’équipe Genisoft avant publication.

Sources

Pour aller plus loin :

Agence web PrestaShop & WordPress

Agence web spécialisée PrestaShop et WordPress : création, maintenance, sécurité, performance et référencement. Nos tutoriels sont issus de nos interventions sur de vraies boutiques.

L'agence Genisoft → LinkedIn →