Si vous avez reçu un e-mail de ma part vous renvoyant vers cette page, c’est parce que votre site web semble exécuter une version de Welcart e-Commerce (l’extension e-commerce gratuite pour WordPress de Welcart / Collne, qui se trouve dans vos fichiers dans /wp-content/plugins/usc-e-shop/) qui entre dans la plage affectée par un problème de sécurité connu. Cette page explique en quoi consiste le problème, à quel point il compte pour votre site, comment lire votre version sans être induit en erreur et comment mettre à jour.

Le problème est CVE-2026-19914, une vulnérabilité de cross-site scripting (XSS) stocké non authentifié. Elle concerne chaque version jusqu’à la 2.12.1 incluse et a été corrigée dans la 2.12.2, publiée le 31 août 2026. Si vous exécutez la 2.12.1 ou une version antérieure, mettez Welcart à jour vers la 2.12.2 ou une version ultérieure. Le problème est évalué à CVSS 7.2 (High), selon la notation de Wordfence. Je n’ai connaissance d’aucun code d’exploitation public à son sujet.

Il n’existe aucune version antérieure qui soit sûre. Il ne s’agit pas d’une faille introduite à un moment de l’histoire de l’extension et corrigée plus tard. Le rendu sans échappement à l’origine de ce problème a été présent tout au long de l’histoire de l’extension - j’ai confirmé qu’il est présent dès la version 1.7.0 - de sorte que « mon installation est trop ancienne pour être concernée » n’est pas une échappatoire ici. Les seules versions qui ne sont pas concernées sont la 2.12.2 et les suivantes.

Avant toute chose, un mot sur ce qu’est ce problème et sur la manière dont il se produit, car je préfère l’énoncer clairement plutôt que de laisser l’avis paraître plus grave qu’il ne l’est. Il s’agit d’une vulnérabilité de cross-site scripting stocké, et le script qu’elle peut exécuter s’exécute dans le navigateur d’un administrateur de la boutique, et non dans celui d’un visiteur. Pour que cela se produise, deux choses distinctes doivent survenir toutes les deux : une personne passant une commande en tant qu’invité doit soumettre une valeur falsifiée dans un champ de commande personnalisé lors du paiement, puis un administrateur doit ouvrir cette commande sur l’écran d’édition des commandes dans l’espace d’administration de votre WordPress. La valeur soumise est enregistrée avec la commande et rendue sur cet écran sans être échappée, de sorte qu’elle s’exécute lorsque la commande est consultée.

Je peux lire votre version de Welcart depuis un fichier public, mais je ne peux pas voir vos commandes, je ne peux pas voir si une commande contient une valeur falsifiée et je ne peux pas voir si quelqu’un l’a réellement fait sur votre site. Cet avis est donc un avertissement de précaution fondé sur votre numéro de version, et non un constat confirmé au sujet de votre site.

Il vaut aussi la peine d’être précis sur ce qu’est ce problème et sur ce qu’il n’est pas. Le cross-site scripting qui se déclenche dans la session d’un administrateur est un vrai problème qui mérite d’être corrigé : un script qui s’exécute pendant qu’un administrateur est connecté peut agir avec les privilèges de cet administrateur tant que la page est ouverte. Mais ce n’est pas, en soi, une prise de contrôle complète du site. Ce n’est pas de l’exécution de code à distance sur votre serveur, et ce n’est pas un moyen pour un inconnu non authentifié de s’attribuer simplement un compte administrateur. C’est plus limité que les problèmes de compromission totale dont je parle ailleurs, et cela dépend à la fois de la soumission d’une commande et de son ouverture par un administrateur, si bien que je préfère indiquer l’ampleur honnêtement plutôt que de vous laisser une impression plus effrayante que ce que les faits soutiennent.

Il s’agit d’une faille de l’extension, pas d’une faille du cœur de WordPress. Un WordPress parfaitement à jour ne vous protège pas si l’extension Welcart elle-même est dans une version affectée.

Ce message est-il légitime ?

Oui. Il s’agit d’un avis de divulgation responsable et de bonne foi émis par un chercheur en sécurité indépendant. Je ne vous demande pas d’argent, de mots de passe ni d’accès à votre site, et je n’ai pas tenté d’y pénétrer, d’y passer une commande ni d’exploiter quoi que ce soit.

Tout ce que j’ai fait, c’est consulter des pages et des fichiers que votre site web fournit à chaque visiteur (de la même manière que votre page d’accueil est publique) et noter le numéro de version que l’extension publie. En particulier, je n’ai pas passé de commande, pas soumis quoi que ce soit via votre processus de paiement, pas ouvert de session et pas envoyé quoi que ce soit à la fonctionnalité concernée. Rien dans cette vérification ne touche vos données, votre espace d’administration, vos commandes ni aucune partie privée de votre site (plus de détails ci-dessous dans Ce que j’ai fait et n’ai pas fait).

Si vous souhaitez vérifier qui je suis, consultez les coordonnées au bas de cette page et la page À propos.

Pourquoi cela compte

Welcart transforme un site WordPress en boutique en ligne, et c’est l’extension e-commerce la plus utilisée pour WordPress au Japon. Une partie de son rôle consiste à recueillir les informations d’un client lors du paiement, y compris tout champ de commande personnalisé qu’une boutique a ajouté pour collecter des informations supplémentaires, et à les enregistrer avec la commande afin que le personnel puisse les consulter plus tard.

Dans les versions affectées, une valeur soumise dans un champ de commande personnalisé lors d’un paiement en tant qu’invité est enregistrée avec la commande, puis affichée sur l’écran d’édition des commandes dans l’espace d’administration de votre WordPress sans être échappée. L’échappement, c’est ce qui reconvertit en texte brut, pour l’affichage, un texte qui ressemble à du balisage. Sans lui, une valeur falsifiée pour contenir du contenu actif n’est pas affichée comme du texte mais exécutée par le navigateur de l’administrateur qui ouvre cette commande. Comme un invité peut passer une commande sans se connecter, la personne qui fournit cette valeur n’a besoin d’aucun compte sur votre site.

La condition préalable, pour l’énoncer clairement car c’est la partie la plus susceptible d’être mal comprise dans un sens comme dans l’autre : cela nécessite à la fois qu’une commande falsifiée ait été soumise et qu’un administrateur l’ouvre. Cela ne se déclenche pas sur votre vitrine et ne fait rien aux visiteurs ordinaires. Ce que cela atteint, c’est la session d’un administrateur de boutique qui consulte des commandes dans le wp-admin.

Je décris cela au niveau dont un propriétaire de site a besoin pour agir, et pas au-delà. Je ne publie pas les détails qui permettraient à quelqu’un de le reproduire, et je vous demanderais de ne pas l’essayer contre votre propre site ni contre celui de qui que ce soit. Lire votre numéro de version, comme décrit ci-dessous, vous dit tout ce dont vous avez besoin pour décider quoi faire.

Si mon e-mail citait ce problème, cela signifie que la version signalée par votre site est la 2.12.1 ou une version antérieure. Je n’ai pas testé si votre site particulier est exploitable, et je ne peux pas voir vos commandes. Tout ce que j’ai observé, c’est la version.

Suis-je concerné ?

Cela se résume à une question : quelle version de Welcart exécutez-vous ?

Depuis l’espace d’administration de WordPress (source faisant autorité) :

  1. Connectez-vous à votre tableau de bord WordPress (généralement sur yourdomain.com/wp-admin).
  2. Allez dans Extensions puis Extensions installées.
  3. Trouvez Welcart e-Commerce, l’entrée dont le dossier est usc-e-shop, et notez la version affichée sous son nom.

Depuis le manifeste public (aucune connexion nécessaire) : ouvrez

yourdomain.com/wp-content/plugins/usc-e-shop/readme.txt

dans un navigateur et lisez la ligne Stable tag: près du début. Si cette adresse renvoie une erreur « introuvable », essayez README.txt en majuscules - certains hébergeurs sont sensibles à la casse, et quelques paquets livrent le fichier en majuscules.

Depuis le code source de votre page (aucune connexion nécessaire) : affichez le code source de votre page d’accueil et recherchez la propre feuille de style de l’extension exactement à ce chemin :

/wp-content/plugins/usc-e-shop/css/usces_default.css?ver=...

Le numéro ?ver= attaché à ce fichier est la propre version de l’extension, et c’est la source publique que j’ai lue. Welcart charge cette feuille de style sur ses pages de boutique, si bien qu’une page de boutique ou de panier est un endroit fiable pour la trouver. Ne lisez la version que depuis usces_default.css : d’autres fichiers écrits dans votre page portent leurs propres numéros ?ver=, totalement indépendants, et lire le premier que vous trouvez peut vous laisser avec la version d’un autre logiciel. Si vous n’arrivez pas du tout à obtenir un numéro lisible depuis le code source de la page, c’est courant et ce n’est le signe de rien - les extensions de cache et d’optimisation retirent couramment la valeur ?ver= des URL des ressources - utilisez alors le readme.txt ou l’écran d’administration.

Appliquez ensuite cette règle, et notez que les versions se comparent numériquement, et non par ordre alphabétique, de sorte que la 2.12.1 est plus récente que la 2.9.1 même si « 12 » paraît plus petit que « 9 » en tant que texte :

  • 2.12.1 ou antérieure : concernée. Mettez à jour vers la 2.12.2 ou une version ultérieure. Il n’y a pas de seuil en dessous duquel une version plus ancienne redevient sûre.
  • 2.12.2 ou ultérieure : déjà corrigée en ce qui concerne ce problème. Installer la dernière version disponible est le meilleur choix.

Comment mettre à jour

L’extension est gratuite, toujours publiée et activement maintenue, si bien que le correctif est une mise à jour normale. La voie la plus sûre consiste à mettre à jour via WordPress lui-même, et à faire d’abord une sauvegarde :

  1. Sauvegardez votre site (fichiers et base de données) avant d’apporter des modifications. La plupart des hébergeurs proposent des sauvegardes en un clic, ou utilisez une extension de sauvegarde pour WordPress.
  2. Dans l’administration de WordPress, allez dans Tableau de bord puis Mises à jour, ou dans Extensions puis Extensions installées. Si une mise à jour de Welcart est listée, installez-la depuis ici.
  3. Si vous préférez la ligne de commande, WP-CLI fait la même chose : wp plugin update usc-e-shop (la commande utilise le nom du dossier, pas le nom affiché).
  4. Si aucune mise à jour n’apparaît, vous pouvez obtenir la dernière version directement depuis la page de l’extension dans le répertoire WordPress.org, Welcart e-Commerce, et mettre à jour via Extensions puis Ajouter une extension puis Téléverser une extension.
  5. Après la mise à jour, confirmez le nouveau numéro de version (2.12.2 ou ultérieure) à l’aide des étapes ci-dessus, et ouvrez une commande récente dans votre espace d’administration pour vous assurer que les écrans de commande s’affichent toujours normalement.

La version 2.12.2 a également corrigé d’autres problèmes de sécurité en plus de celui-ci, si bien que la mise à jour en vaut la peine de toute façon. Pendant que vous y êtes, il vaut la peine de confirmer que le cœur de WordPress et vos autres extensions sont à jour, car le même principe s’applique à tous.

Après la mise à jour

La mise à jour vers la 2.12.2 ou une version ultérieure clôt le problème, et pour la plupart des sites c’est là toute la tâche. Cette page est un avis de précaution, pas un rapport d’incident : je n’ai aucune visibilité sur ce qui a pu se passer sur votre site, et je n’ai pas regardé.

Une petite chose vaut la peine d’être faite tant que la mise à jour est fraîche :

  • Confirmez que la version a réellement changé, avec celle des vérifications ci-dessus qui est la plus simple, et ouvrez une commande dans votre espace d’administration pour vous assurer que les écrans de commande s’affichent toujours.

Vous remarquerez qu’il n’y a pas sur cette page de liste de contrôle du type « partez du principe que vous avez été compromis », et c’est délibéré et non un oubli. Ce que ce problème produit, c’est un script qui s’exécute dans le navigateur d’un administrateur, et seulement là où à la fois une commande falsifiée a été soumise et un administrateur l’a ouverte par la suite. Il n’exécute pas de code sur votre serveur et ne crée pas de lui-même de compte administrateur, si bien que l’audit des administrateurs et la rotation des mots de passe que je recommande après une faille de la classe prise de contrôle ne seraient pas proportionnés ici. Mettez à jour, confirmez et poursuivez. Si vous avez une raison précise de croire que cela a été utilisé contre votre site - ce pour quoi cet avis, fondé uniquement sur un numéro de version, ne vous donne aucune preuve, il est alors raisonnable de traiter les connexions de vos administrateurs avec la prudence habituelle, mais la version à elle seule ne l’exige pas.

Ce que j’ai fait et n’ai pas fait

Pour être tout à fait transparent sur la vérification qui se cache derrière mon e-mail : je n’ai lu que des fichiers que votre site fournit déjà à chaque visiteur, à savoir votre page d’accueil et l’adresse de la feuille de style de Welcart qui y est inscrite, ainsi que le readme.txt public de l’extension à l’intérieur de wp-content/plugins/usc-e-shop/. Je n’ai pas accédé à votre espace d’administration WordPress, à votre base de données, à vos commandes ni à aucune partie privée du site.

En particulier, je n’ai jamais passé de commande, soumis quoi que ce soit via votre processus de paiement, ouvert de session ni envoyé quoi que ce soit à la fonctionnalité concernée. Rien n’a été soumis, testé ni exploité. C’est important ici, car soumettre une valeur falsifiée lors du paiement est très proche de l’action exacte dont il est question dans ce problème, de sorte que « je n’y ai pas touché » constitue toute la différence entre une divulgation et une intrusion.

Je m’abstiens aussi délibérément de publier les détails qui aideraient quelqu’un à agir sur ce problème. La description ci-dessus s’en tient au niveau dont un propriétaire de site a besoin, et je ne renvoie vers aucun code de preuve de concept.

Il s’agit d’une observation fondée sur la version : votre site signale une version 2.12.1 ou antérieure. Ce n’est pas une affirmation selon laquelle votre site était exploitable au moment où je l’ai vérifié. Comme ce problème dépend à la fois de la soumission d’une commande falsifiée et de son ouverture par un administrateur - des choses que je ne peux pas voir, un site dans la plage affectée pourrait très bien ne pas avoir été exposé, et un site dans cette plage peut être protégé par ailleurs par d’autres moyens tels qu’un pare-feu applicatif web ou un correctif rétroporté. Si vous avez déjà mis à jour, ou remédié à cela d’une autre manière, aucune action n’est nécessaire, et je vous prie de m’excuser pour la gêne occasionnée.

Je n’ai pas de webmestre / je suis bloqué

Si vous n’êtes pas la personne qui maintient le site, veuillez transférer cette page à celle qui s’en charge (votre développeur web, votre agence ou votre hébergeur). Elle reconnaîtra rapidement les étapes ci-dessus.

Si vous maintenez le site vous-même et que vous êtes bloqué, je suis heureux de vous aider à vous orienter dans la bonne direction, sans frais. Contactez-moi en utilisant les coordonnées ci-dessous.

Contact

Evan Harris, chercheur en sécurité

Je prends contact au sujet de ce genre de problème uniquement pour aider les exploitants à sécuriser leurs sites. Si vous préférez ne plus être contacté, faites-le-moi simplement savoir et je le respecterai.

Références

Avis officiels et suivi

Éditeur / extension