Selon l’enquête publiée par Anchor Hosting, un portefeuille de plus de 30 plugins WordPress issus de l’éditeur Essential Plugin a été acquis, puis modifié, pour intégrer une porte dérobée restée dormante pendant huit mois avant d’être activée à grande échelle début avril 2026.
Le 7 avril 2026, WordPress.org a fermé 31 plugins liés à cet éditeur, puis a poussé une mise à jour forcée le 8 avril pour neutraliser une partie du mécanisme malveillant.
Ce cas est particulièrement marquant car il s’agit d’extensions déjà installées sur de nombreux sites, rachetées via une place de marché, puis utilisées comme vecteur d’accès vers des environnements de production, des bases de données et potentiellement des données personnelles.
Ce que révèle vraiment cette affaire
Le point de départ de l’enquête est un message d’alerte vu dans le tableau de bord WordPress d’un client au sujet du plugin Countdown Timer Ultimate. Lors de l’audit, le plugin avait déjà été mis à jour de force en version 2.6.9.1, mais le site restait compromis, car le code malveillant s’était déjà propagé dans le fichier critique wp config.php.
Problématique supplémentaire : la capacité du plugin à déposer une charge persistante ailleurs dans le socle du site. En matière de sécurité et de protection des données, cela signifie qu’une simple désactivation n’est pas nécessairement suffisante, puisque la persistance peut survivre au correctif initial.
Comment l’attaque a fonctionné
D’après l’enquête, le module wpos analytics intégré aux plugins a contacté le domaine analytics.essentialplugin.com, téléchargé un fichier nommé wp comments posts.php, puis utilisé ce fichier pour injecter un bloc massif de PHP dans wp config.php. Le code injecté servait ensuite des redirections, du spam SEO et de fausses pages depuis un serveur de commande et contrôle, avec un affichage réservé à Googlebot afin de rester invisible pour les administrateurs du site.
Le mécanisme allait encore plus loin, puisque la résolution du domaine de commande et contrôle passait par un smart contract Ethereum consulté via des points de terminaison RPC publics. Cela rendait les opérations de neutralisation beaucoup plus complexes, car un simple retrait de domaine ne suffisait plus à casser durablement la chaîne de commande.
L’auteur de l’enquête a également reconstitué la fenêtre d’injection en comparant plusieurs sauvegardes quotidiennes de wp config.php. Son analyse situe la compromission active le 6 avril 2026, entre 04 h 22 UTC et 11 h 06 UTC, avec un fichier passé d’environ 3,3 Ko à 9,5 Ko.
Une porte dérobée préparée des mois à l’avance
L’élément le plus préoccupant est que la porte dérobée n’a pas été introduite au moment de l’attaque visible, mais bien plus tôt. Selon l’analyse de l’historique du plugin, la version 2.6.7 publiée le 8 août 2025 aurait ajouté 191 lignes de code dans class anylc admin.php, sous couvert d’un simple message de compatibilité avec WordPress 6.8.2.
Ce nouveau code introduisait trois briques critiques : un appel à file get contents vers le serveur de l’attaquant, un passage de la réponse à unserialize(), puis l’exécution d’une fonction contrôlée à distance à partir des données désérialisées. L’enquête mentionne aussi un point d’accès REST non authentifié avec permission callback défini sur __return_true, ce qui correspond à un schéma typique d’appel de fonction arbitraire.
Autrement dit, la charge malveillante était déjà en place, mais restait silencieuse. Elle n’a été activée que les 5 et 6 avril 2026, soit environ huit mois après son introduction dans le code.
Le rachat du portefeuille et la rupture de confiance
L’article retrace l’historique de l’éditeur. Les plugins étaient initialement développés par une équipe opérant sous le nom WP Online Support à partir de 2015, avant une évolution de marque vers Essential Plugin. À la fin de l’année 2024, la baisse de revenus aurait conduit à la mise en vente de l’activité sur Flippa, puis à un rachat en 2025 par un acheteur identifié sous le prénom Kris, présenté comme ayant un profil lié au SEO, à la crypto et au marketing dans les jeux d’argent.
Selon l’enquête, le premier commit SVN du nouvel acquéreur aurait précisément introduit la porte dérobée dans les plugins. Ce point est essentiel pour la sensibilisation, car il montre que la compromission ne vient pas d’un défaut historique du produit, mais d’un changement de contrôle survenu après des années d’usage légitime.
Il faut toutefois apporter une nuance importante pour rester rigoureux. La documentation officielle de WordPress.org prévoit bien une procédure de transfert de plugin, y compris un traitement spécifique pour les extensions dépassant 10 000 utilisateurs, ce qui signifie qu’il existe formellement un mécanisme de transfert. Le problème mis en lumière ici semble donc moins être l’absence de procédure que l’absence de signalement clair du changement de contrôle pour les utilisateurs, ainsi que l’insuffisance apparente des garde fous ou de la revue renforcée dans ce cas précis.
Pourquoi cette affaire concerne directement la protection des données
Un plugin WordPress ne se contente pas d’ajouter une fonctionnalité visuelle. Il peut accéder au code applicatif, à la base de données, aux comptes d’administration, aux formulaires et parfois aux parcours clients, ce qui en fait un composant à privilèges élevés. Lorsqu’un tel composant est compromis, le risque porte sur l’intégrité du site, la confidentialité des données, la disponibilité des services et l’image de l’organisation.
Dans cette affaire, le payload servait notamment du spam SEO et des redirections invisibles à l’administrateur. Mais une telle porte d’entrée pourrait tout aussi bien être utilisée pour exfiltrer des données de formulaires, déposer d’autres scripts, créer des accès persistants ou manipuler des contenus transactionnels. Pour toute structure qui collecte des données personnelles, il faut donc analyser l’incident sous l’angle de la violation de données, de la traçabilité, de l’obligation de documentation et, selon les cas, de la notification réglementaire.
Ce qu’il faut corriger dans la gouvernance WordPress
Cette affaire montre que la sécurité d’un site ne dépend plus seulement de la qualité du code au moment de l’installation. Elle dépend aussi de l’identité de la personne ou de l’entité qui contrôle ce code, de la continuité de maintenance, de la transparence du changement de propriété et de la capacité à détecter des modifications anormales dans une mise à jour pourtant présentée comme légitime.
Pour une entreprise, un plugin doit donc être traité comme un fournisseur critique. Acheter ou conserver un plugin populaire revient à prolonger un lien de confiance avec un tiers qui peut évoluer, être revendu ou se faire compromettre. C’est précisément cette dépendance silencieuse qui transforme aujourd’hui la chaîne de confiance en surface d’attaque.
Les actions immédiates à recommander
Si un site utilise l’un des plugins concernés, il ne faut pas se limiter à la désinstallation. L’enquête montre que la mise à jour forcée de WordPress.org neutralisait le mécanisme de contact distant, mais ne nettoyait pas automatiquement le code déjà injecté dans wp config.php.
Les mesures prioritaires sont les suivantes :
- Identifier immédiatement la présence d’un plugin Essential Plugin dans votre parc WordPress.
- Contrôler le fichier wp config.php, en particulier la ligne contenant require once ABSPATH . wp settings.php; , car le malware pouvait s’y ajouter discrètement sur la même ligne.
- Rechercher une hausse anormale de la taille du fichier, l’enquête évoquant un ajout d’environ 6 Ko lors de l’injection.
- Vérifier les dates de modification, les comptes administrateurs, les tâches planifiées et les connexions sortantes du serveur.
- Restaurer depuis une sauvegarde saine ou procéder à une remédiation complète si le site a effectivement été compromis.
- Réinitialiser les secrets d’accès sensibles, notamment WordPress, hébergement, base de données, SFTP et éventuelles clés applicatives.
- Évaluer si des données personnelles ont pu être consultées, altérées ou exfiltrées.
Nous répondons à vos questions :
Un plugin WordPress légitime peut il devenir malveillant ?
Oui. Dans cette affaire, l’enquête décrit un changement de contrôle du portefeuille de plugins, suivi de l’introduction d’une porte dérobée dans une version présentée comme une simple mise à jour de compatibilité.
La mise à jour forcée de WordPress.org suffisait elle à nettoyer les sites ?
Non complètement. L’enquête précise que la mise à jour forcée neutralisait le mécanisme de contact distant, mais ne supprimait pas automatiquement le code déjà injecté dans wp config.php.
Pourquoi parle t on d’attaque supply chain ?
Parce que l’attaquant n’a pas ciblé d’abord les sites finaux. Il a compromis la chaîne de distribution logicielle en prenant le contrôle de plugins déjà dignes de confiance aux yeux des utilisateurs.
Quels fichiers faut il vérifier en priorité ?
Le fichier wp config.php est central dans cette affaire, car l’injection malveillante y aurait été déposée après activation de la backdoor.
Cette attaque concerne t elle seulement WordPress ?
Non. Le cas se déroule dans l’écosystème WordPress, mais la logique est celle d’une compromission de chaîne d’approvisionnement, un risque qui existe dans tous les environnements reposant sur des composants tiers.
