Porte dérobée dans 31 plugins WordPress :
comment vérifier si votre site est touché.

Le chiffre de quatre cent mille sites a circulé partout. Il mérite d’être décomposé, car il ne mesure pas ce qu’on lui fait dire.

Quatre cent mille correspond au nombre d’installations revendiqué par l’éditeur sur son propre site, tous produits confondus, aux côtés d’une mention de plus de quinze mille clients. C’est un argument commercial, cumulé sur des années et jamais audité.

La mesure indépendante donne un ordre de grandeur très différent. Selon les pages du répertoire officiel, les extensions concernées totalisaient un peu plus de vingt mille installations actives au moment des faits. Un facteur vingt sépare les deux chiffres.

Cette différence n’atténue pas la gravité, elle la déplace. Vingt mille sites compromis par une porte dérobée persistante, avec injection dans le fichier de configuration central, constitue un incident majeur. Mais présenter quatre cent mille sites comme exposés revient à confondre la vitrine commerciale d’un éditeur avec un relevé technique. La même précaution vaut pour toutes les annonces de compromission massive, y compris celles visant les extensions de navigateur, comme nous le relevions à propos des extensions Chrome piégées à désinstaller.

La technique employée n’a rien d’inédit. C’est précisément ce qui rend l’affaire embarrassante pour l’écosystème.

Le cœur du dispositif repose sur une injection d’objet PHP par désérialisation non sécurisée, assemblée à partir de trois composants distincts de la suite. Ce type de faille figure dans la boîte à outils des chercheurs en sécurité WordPress depuis plus de dix ans. Aucune innovation, donc : simplement une vulnérabilité introduite volontairement plutôt que par erreur.

Le déclenchement était conditionnel. Le code n’exécutait sa charge que si un point d’accès distant, hébergé sur un sous-domaine de l’éditeur, renvoyait un contenu sérialisé spécifique. Tant que ce serveur répondait normalement, rien ne se produisait. Cette architecture explique la dormance et la rend réversible à volonté depuis l’extérieur.

Une fois activée, la porte dérobée téléchargeait un fichier nommé de manière à passer pour un composant légitime de WordPress, lequel injectait ensuite du code dans wp-config.php, le fichier de configuration central qui contient notamment les identifiants de connexion à la base de données. Pour la résolution de son serveur de commande, la charge utile s’appuyait sur des points d’accès de la chaîne Ethereum, technique qui rend une infrastructure de contrôle très difficile à faire tomber puisqu’aucune autorité ne peut supprimer une donnée inscrite sur une chaîne de blocs. Le schéma rappelle les compromissions par la chaîne d’approvisionnement que nous décrivions à propos de l’attaque visant un composant de l’écosystème de l’intelligence artificielle.

Voici le détail qui distingue cette affaire d’une compromission ordinaire, et qui concerne directement quiconque tient à son référencement.

Le code injecté ne montrait le spam qu’au robot d’exploration de Google. Un visiteur humain, y compris le propriétaire du site connecté à son administration, voyait ses pages parfaitement normales. Le contenu frauduleux, les liens sortants et les fausses pages n’apparaissaient que pour l’agent chargé d’indexer le site.

Cette technique porte un nom dans le métier, le cloaking, et elle constitue une violation caractérisée des règles des moteurs de recherche. La conséquence est double et brutale. D’une part, le propriétaire n’a aucun moyen de constater le problème en naviguant sur son propre site. D’autre part, c’est son domaine qui porte la responsabilité de ce que le moteur indexe.

Un site ayant servi du spam à Googlebot pendant plusieurs semaines s’expose donc à une pénalité, manuelle ou algorithmique. Une baisse de positions inexpliquée survenue au printemps 2026 sur un site utilisant l’une de ces extensions mérite d’être examinée sous cet angle avant toute autre hypothèse. La vérification passe par la console de recherche, dans les sections consacrées aux problèmes de sécurité et aux actions manuelles, et un réexamen doit être demandé après nettoyage.

Au-delà de cet incident, l’affaire met en évidence une faiblesse du modèle qui ne relève d’aucun bogue et qu’aucune mise à jour ne corrigera.

Une extension installée sur des milliers de sites constitue un actif qui se vend. Le répertoire officiel ne prévoit aucun contrôle du changement de propriétaire, aucun audit de code déclenché par l’arrivée d’un nouveau contributeur, et aucune notification aux utilisateurs lorsque l’éditeur d’une extension qu’ils utilisent change de mains. L’acquéreur hérite du canal de mise à jour automatique et de la confiance accumulée par ses prédécesseurs.

Ce schéma n’est pas nouveau. Une campagne comparable avait été documentée près de neuf ans plus tôt, avec le rachat d’extensions populaires suivi de l’insertion de liens dissimulés. Aucune mesure structurelle n’a été mise en place dans l’intervalle. La répétition suggère que le problème n’est pas la vigilance individuelle des administrateurs mais l’architecture de confiance elle-même.

La conséquence pratique pour une entreprise est de considérer chaque extension installée comme une dépendance dont il faut connaître l’éditeur et suivre l’évolution. Les recommandations des autorités convergent sur ce point, comme le montre notre article sur le rapport de la CNIL et les règles annoncées, dans un contexte où les vecteurs d’entrée se multiplient, du courriel piégé décrit dans notre article sur la proportion de messages malveillants reçus aux faux écrans d’assistance technique détaillés à propos de la technique ClickFix.