En juin 2026, des chercheurs de Wordfence ont publié l'analyse d'une attaque de supply chain ayant compromis les systèmes de distribution de trois plugins WordPress Pro commercialisés par ShapedPlugin. Les acheteurs de licences commerciales pour ces plugins ont reçu, via le mécanisme de mise à jour automatique, des versions contenant un backdoor complet capable de voler des credentials WordPress, des codes d'authentification à deux facteurs, et des données WooCommerce, tout en installant des mécanismes de persistance conçus pour survivre à une suppression partielle. Les versions gratuites des mêmes plugins, distribuées sur WordPress.org, n'ont pas été affectées par cette compromission.
L'attaque concerne trois plugins WordPress Pro de ShapedPlugin. Product Slider Pro for WooCommerce est affecté dans toutes les versions antérieures à 3.5.4. Cette compromission a reçu l'identifiant CVE-2026-49777 avec un score CVSS de 10.0, le score maximal sur l'échelle CVSS. Real Testimonials Pro est compromis dans la version 3.2.5. Smart Post Show Pro est affecté dans les versions antérieures à 4.0.2. L'incident global est également référencé sous CVE-2026-10735 avec un score CVSS de 9.8.
Le point commun à ces trois plugins est leur canal de distribution : ils sont vendus et distribués via Easy Digital Downloads (EDD), une plateforme de vente de produits numériques WordPress hébergée par ShapedPlugin à account.shapedplugin[.]com. Les mises à jour de ces plugins Pro transitent par ce canal privé plutôt que par le référentiel officiel WordPress.org, plaçant leur sécurité entièrement dans les mains de l'infrastructure de ShapedPlugin.
Easy Digital Downloads (EDD) est une solution e-commerce WordPress couramment utilisée par les développeurs de plugins et thèmes commerciaux pour gérer les ventes, les licences, et la distribution des mises à jour de leurs produits payants. Elle permet aux éditeurs de proposer un système de mises à jour automatiques similaire à celui de WordPress.org pour des plugins distribués hors de ce référentiel officiel.
Ce modèle crée une asymétrie de confiance fondamentale. Lorsqu'un acheteur de licence active les mises à jour automatiques pour un plugin Pro, il établit une relation de confiance implicite avec l'infrastructure de l'éditeur : chaque mise à jour reçue via ce canal est considérée comme légitime par son installation WordPress. La mise à jour arrive via une connexion SSL authentifiée, se comporte comme toutes les mises à jour précédentes, et s'installe automatiquement sans requérir d'approbation manuelle. Rien dans ce processus ne permet au site destinataire de distinguer une mise à jour légitime d'une mise à jour compromise au niveau de l'infrastructure de l'éditeur.
Pour un attaquant qui parvient à compromettre l'infrastructure EDD d'un éditeur, ce mécanisme de confiance devient un vecteur de distribution massif. Il n'est pas nécessaire de compromettre chaque site cible individuellement : une seule compromission de l'infrastructure centrale suffit à livrer le backdoor à l'ensemble des acheteurs ayant activé les mises à jour automatiques. La distinction entre versions gratuites (WordPress.org, avec processus de révision externe) et versions Pro (EDD, sans validation externe équivalente) est structurellement significative : c'est précisément cette absence de contrôle indépendant sur les mises à jour Pro qui a permis à l'attaque de se propager.
L'infection commence au moment où un site WordPress vérifie la disponibilité d'une mise à jour pour l'un des trois plugins affectés et télécharge la version compromise depuis account.shapedplugin[.]com. La mise à jour s'installe normalement, et le plugin fonctionne comme attendu tout en incluant un composant supplémentaire : un loader malveillant intégré dans sa base de code.
Ce loader s'exécute sur chaque chargement de page dans l'interface d'administration WordPress. A chaque visite d'une page admin par un utilisateur connecté, le loader contacte silencieusement le serveur de commande et contrôle à l'adresse 194.76.217[.]28:2871. Le serveur C2 répond en fournissant un faux plugin WordPress encodé. Le loader reçoit ce faux plugin, le décode, et l'installe et l'active dans WordPress sans passer par le processus d'installation standard visible dans l'interface d'administration.
Le faux plugin est actif dans l'installation WordPress dès sa réception, mais il ne figure pas dans la liste des plugins affichée dans l'interface d'administration. C'est à partir de ce moment que les capacités de collecte de données et de persistance du backdoor deviennent opérationnelles sur le site.
WordPress génère la liste des plugins installés en combinant les informations du système de fichiers (dossiers présents dans wp-content/plugins/) avec les données de la base de données, puis applique des filtres PHP avant d'afficher la liste dans l'interface d'administration. Le faux plugin s'accroche au filtre all_plugins, qui est appliqué à cette liste avant son affichage. En supprimant sa propre entrée des résultats retournés par ce filtre, le faux plugin disparait de la vue de tout administrateur consultant la page des extensions installées.
Cette technique de dissimulation est connue dans le domaine de la sécurité WordPress sous le terme de "plugin cloaking". Elle est efficace contre les administrateurs qui s'appuient sur l'interface d'administration pour vérifier leurs plugins installés. La détection nécessite soit une inspection directe du système de fichiers du serveur (lister le contenu de wp-content/plugins/ via SSH ou FTP et comparer avec la liste dans l'admin), soit une requête directe à la table wp_options de la base de données WordPress pour la clé active_plugins, qui liste tous les plugins actifs tels qu'enregistrés en base de données.
Une fois installé, le faux plugin collecte et exfiltre cinq catégories de données sensibles depuis le site WordPress compromis, chacune présentant des risques distincts pour l'organisation.
La première catégorie est le fichier wp-config.php. Ce fichier contient les credentials de connexion à la base de données (hôte, nom de base, identifiant, mot de passe), les clés d'authentification et les salts utilisés pour sécuriser les cookies et jetons WordPress, et toute constante de configuration supplémentaire ajoutée par l'administrateur. Son exfiltration donne à l'attaquant un accès direct à la base de données du site et la capacité de forger des sessions d'authentification WordPress valides sans connaître le mot de passe d'aucun compte utilisateur.
La deuxième catégorie couvre les comptes administrateurs WordPress : liste des comptes avec le rôle "administrator", adresses e-mail associées, et dates d'inscription. Ces informations permettent à l'attaquant d'identifier les cibles pour des attaques ultérieures de phishing ciblé ou de valider des credentials déjà en sa possession.
La troisième catégorie concerne les credentials des plugins de messagerie. Si le site utilise WP Mail SMTP, Post SMTP, ou Easy WP SMTP pour envoyer des e-mails via un compte externe, les credentials SMTP de ces comptes sont collectés. Ces credentials permettent d'envoyer des e-mails au nom du domaine du site, une capacité précieuse pour des campagnes de phishing ou de spam qui exploitent la réputation e-mail du domaine victime.
La quatrième catégorie comprend les données de commandes WooCommerce des trois derniers mois, incluant les informations des acheteurs (noms, adresses de livraison et facturation) et les méthodes de paiement utilisées. Pour un site e-commerce actif, cette exfiltration peut concerner des milliers de transactions et les données personnelles de nombreux clients, déclenchant potentiellement des obligations de notification au titre du RGPD.
La cinquième catégorie est la plus sophistiquée : la capture des codes d'authentification à deux facteurs en temps réel. Si l'administrateur du site utilise une extension 2FA pour WordPress, le backdoor est capable d'intercepter les codes TOTP ou autres tokens au moment de leur saisie. Cette capacité contourne la protection 2FA pour les connexions administrateur : l'attaquant obtient un code valide pendant les secondes qui suivent sa capture, lui permettant de s'authentifier avec ce second facteur sans avoir à compromettre le générateur de codes lui-même.
Les concepteurs du backdoor ont anticipé la possibilité qu'une équipe de sécurité détecte et supprime le faux plugin. Trois mécanismes de persistance indépendants sont déployés pour maintenir l'accès même après une suppression partielle.
Le premier est un point d'extrémité REST WordPress personnalisé. Ce endpoint est enregistré dans WordPress lors de l'installation du faux plugin. Il répond à des requêtes HTTP contenant un token d'authentification connu uniquement des attaquants et permet d'exécuter des écritures de fichiers arbitraires sur le serveur. Un attaquant qui connait ce token peut revenir après la suppression du faux plugin et réinstaller les composants nécessaires via ce canal, sans déclencher de nouveau le mécanisme d'installation initial.
Le second mécanisme est un web shell avec des capacités d'exécution de commandes système. Ce shell est écrit directement sur le système de fichiers du serveur dans un emplacement distinct du répertoire du faux plugin. Sa suppression nécessite d'identifier et de retirer le fichier PHP correspondant sur le serveur, une étape que beaucoup d'administrateurs ne réaliseront pas s'ils ne savent pas qu'il existe.
Le troisième mécanisme est le fichier install-persistent.php. Ce composant est inclus dans le faux plugin et s'exécute une fois au moment de l'installation pour extraire les données sensibles décrites dans la section précédente (wp-config.php, comptes admin, credentials messagerie, données WooCommerce). Après cette exfiltration, install-persistent.php se supprime lui-même du système de fichiers. Sa présence n'est donc plus détectable lors d'une analyse forensique post-incident, ce qui complique la reconstitution de la séquence d'événements.
La combinaison de ces trois mécanismes signifie qu'un site dont seul le faux plugin a été supprimé reste probablement compromis via le REST endpoint ou le web shell. Un nettoyage complet requiert une analyse de l'intégrité complète des fichiers WordPress, et pas uniquement une désinstallation de plugin. La surveillance des indicateurs de compromission spécifiques à ce type de backdoor WordPress est essentielle pour une détection complète.
Un score CVSS de 10.0 représente la combinaison maximale de tous les facteurs de risque : exploitabilité parfaite (accès réseau, faible complexité, aucun privilège requis, aucune interaction utilisateur) et impact total dans les trois dimensions (confidentialité, intégrité, disponibilité). Dans le cas de CVE-2026-49777, cette notation reflète une compromission de supply chain qui livre automatiquement un backdoor complet à tous les sites ayant activé les mises à jour automatiques du plugin. L'attaquant n'a besoin d'aucune action supplémentaire de la victime au-delà de l'activation des mises à jour automatiques, et obtient un accès complet au site WordPress, à sa base de données, et au serveur sous-jacent via le web shell.
CVE-2026-10735 (CVSS 9.8) couvre la portée plus large de la campagne incluant les trois plugins. La différence de 0,2 entre les deux scores reflète des nuances dans les conditions exactes d'exploitation entre les plugins, mais les deux scores communiquent la même réalité opérationnelle : criticité maximale et nécessité d'une réponse immédiate.
Pour les sites WooCommerce ayant collecté des commandes clients pendant la période d'exposition, l'exfiltration des données de commande des trois derniers mois constitue une violation de données personnelles au sens du RGPD. Les données des acheteurs (noms, adresses, méthodes de paiement) sont des données personnelles dont la divulgation non autorisée déclenche des obligations légales.
L'article 33 du RGPD impose une notification à l'autorité de protection des données compétente (en France, la CNIL) dans un délai de 72 heures à compter du moment où l'organisation a eu connaissance de la violation. Cette notification doit décrire la nature de la violation, les catégories de données concernées, le nombre approximatif de personnes affectées, et les mesures prises ou envisagées. L'article 34 impose une notification aux personnes concernées lorsque la violation est susceptible d'engendrer un risque élevé pour leurs droits et libertés, ce qui est vraisemblablement le cas si des données de paiement ou des adresses personnelles ont été exfiltrées.
Les credentials de messagerie SMTP exfiltrés représentent un risque additionnel : si ces credentials sont utilisés pour envoyer des e-mails de phishing au nom du domaine victime, les destinataires de ces messages peuvent également être considérés comme des personnes affectées par la violation. Evaluer l'étendue de sa surface d'exposition inclut nécessairement l'inventaire des plugins commerciaux et de leurs canaux de distribution pour anticiper ce type de risque.
La première étape est la vérification du système de fichiers. Via SSH ou FTP, listez le contenu du répertoire wp-content/plugins/ et comparez avec la liste des plugins affichée dans l'interface d'administration WordPress. Tout dossier présent sur le système de fichiers mais absent de la liste admin est un indicateur de présence d'un plugin malveillant dissimulé.
La deuxième étape est l'audit de la base de données. Interrogez la table wp_options pour la clé active_plugins. Comparez la liste retournée avec la liste du système de fichiers et avec la liste admin pour identifier toute discordance. Un plugin actif en base de données qui n'apparait pas dans l'admin et dont le dossier ne correspond pas à un plugin légitime connu est un indicateur fort de faux plugin.
La troisième étape est la recherche de fichiers PHP récemment créés ou modifiés en dehors des répertoires de plugins connus. Cherchez en particulier des fichiers PHP dans wp-content/uploads/, le répertoire racine de WordPress, ou dans des sous-répertoires système, dont la date de création correspond à la période d'exposition. Ces fichiers peuvent correspondre au web shell déposé par le backdoor.
La quatrième étape est la vérification des endpoints REST enregistrés. Utilisez un outil d'audit WordPress ou inspectez directement la table wp_options pour la clé rewrite_rules et les options liées aux REST routes pour identifier des endpoints inhabituels non documentés par les plugins légitimes installés.
Une fois la désinfection confirmée, toutes les credentials potentiellement exfiltrées doivent être remplacées : mot de passe de base de données (avec mise à jour dans wp-config.php), clés d'authentification WordPress (via régénération des salts sur le site officiel des API WordPress), mots de passe de tous les comptes administrateurs, et credentials des comptes de messagerie SMTP. La mise à jour vers les versions corrigées des plugins (3.5.4 pour Product Slider Pro, 4.0.2 pour Smart Post Show Pro) doit également être réalisée avant de remettre le site en production.
Si vous utilisez Product Slider Pro for WooCommerce antérieur à 3.5.4, Real Testimonials Pro version 3.2.5, ou Smart Post Show Pro antérieur à 4.0.2, et que les mises à jour automatiques étaient activées pendant la période de compromission, votre site a potentiellement reçu la version backdoorée. Vérifiez la version installée dans l'interface d'administration et la date de la dernière mise à jour. En cas de doute, traitez le site comme potentiellement compromis et réalisez les vérifications décrites ci-dessus.
Non. La suppression du plugin depuis l'interface d'administration ne supprime pas le faux plugin caché, le web shell sur le système de fichiers, ni le endpoint REST persistant. Ces trois composants sont conçus pour survivre à cette action. Un nettoyage complet nécessite une inspection du système de fichiers, un audit de la base de données WordPress, et la vérification des endpoints REST. La réinstallation d'une version propre du plugin est nécessaire mais insuffisante.
Non. L'attaque a ciblé exclusivement l'infrastructure EDD de ShapedPlugin. WordPress.org dispose de ses propres processus de validation et serveurs de distribution. Les versions gratuites de Product Slider for WooCommerce, Real Testimonials et Smart Post Show sur WordPress.org n'ont pas été compromises dans cet incident.
La capture s'effectue au niveau de l'interface d'administration WordPress, où le backdoor a accès au DOM des pages chargées par l'administrateur. Techniquement, cela peut se faire via l'injection de JavaScript dans les pages d'administration qui intercepte les valeurs saisies dans les champs de formulaire avant leur envoi au serveur. Depuis la perspective de l'administrateur, la page semble normale ; le code 2FA est capturé et envoyé au C2 avant que l'authentification ne soit traitée par WordPress.
Si le backdoor a été actif pendant une période où des commandes WooCommerce ont eu lieu, les données des acheteurs ont potentiellement été exfiltrées. Selon l'article 33 du RGPD, vous avez l'obligation de notifier la CNIL dans un délai de 72 heures après avoir pris connaissance de la violation si elle est susceptible de présenter un risque pour les droits et libertés des personnes. Consultez votre DPO sans délai pour évaluer l'obligation de notification dans votre contexte spécifique.
Plusieurs mesures réduisent le risque. Maintenir un inventaire des plugins commerciaux avec leurs éditeurs et canaux de distribution permet de réagir rapidement lors d'une divulgation. Configurer une surveillance d'intégrité de fichiers (Wordfence ou un outil similaire) détecte les modifications non autorisées. Désactiver les mises à jour automatiques pour les plugins commerciaux en faveur d'un processus de mise à jour contrôlé (avec test en préproduction) réduit la fenêtre d'exposition aux compromissions de supply chain, au prix d'un délai supplémentaire pour les correctifs légitimes. Abonner l'équipe de sécurité aux bulletins de Wordfence Threat Intelligence permet d'être alerté rapidement lors de découvertes de ce type.
Ce type de menace illustre un problème structurel : les informations critiques sur une campagne active circulent d'abord dans des canaux fermés, forums clandestins et groupes Telegram privés, avant d'atteindre les équipes de sécurité par les canaux habituels. Le temps perdu dans cet écart est souvent celui où l'exploitation est la plus active.
Defendis surveille ces sources en continu. Votre équipe reçoit des signaux d'alerte pertinents avant que l'incident ne devienne public, avec le contexte nécessaire pour agir : nature de la menace, infrastructure associée, secteurs ciblés. Sans que vos analystes aient à patrouiller eux-mêmes dans des espaces qu'ils ne devraient pas avoir à fréquenter.
