Quand la mise à jour de votre extension WordPress installe la porte dérobée

Mettre à jour ses extensions est la première consigne de sécurité que nous donnons à nos clients. C'est aussi la plus facile à suivre : un badge rouge dans le tableau de bord, un clic, quelques secondes, et la faille est bouclée. En mai et juin 2026, ce réflexe d'hygiène est précisément devenu le vecteur d'infection.

Sur la seule faille de l'extension Gravity SMTP, Wordfence a bloqué plus de 17 millions de tentatives d'exploitation, avec un pic dépassant les 4 millions de requêtes par jour au début du mois de juin 2026. Quelques semaines plus tôt, l'éditeur ShapedPlugin a distribué à ses clients payants, depuis son propre serveur de mise à jour, des versions piégées de trois extensions professionnelles. Les sites touchés n'avaient rien fait de risqué. Ils avaient fait exactement ce que nous recommandons tous : rester à jour.

Ce retournement n'est pas anecdotique. Il déplace le problème de sécurité là où presque personne ne regarde : non plus dans le code que vous installez, mais dans le canal par lequel il arrive chez vous. Pour une agence comme la nôtre qui maintient des sites WordPress au quotidien, c'est un changement de méthode, pas seulement une alerte de plus.

Le paradoxe de la mise à jour de confiance

Le modèle mental de la sécurité WordPress repose sur une hypothèse simple : le danger vient de l'extérieur, et la mise à jour est le rempart. Un pirate cherche une version vulnérable, vous la corrigez, la porte se referme. Ce raisonnement tient tant que la source du code reste saine.

Une attaque par la chaîne d'approvisionnement inverse cette logique. Au lieu de chercher une faille chez vous, l'attaquant compromet un maillon situé en amont : le serveur de build de l'éditeur, son infrastructure de distribution, ou le compte d'un développeur. Le code malveillant est alors signé, empaqueté et livré à travers le circuit légitime. Votre site ne fait que télécharger et exécuter ce qu'il attendait. Aucun signal d'alerte, aucune alerte de fichier modifié, puisque c'est la mise à jour officielle elle-même qui porte la charge.

La difficulté tient à ce que ce type d'attaque coche toutes les cases de la confiance. La version est authentique, elle vient du bon éditeur, elle s'installe par le mécanisme habituel. Les outils qui vérifient l'intégrité d'un fichier par rapport à la version publiée ne voient rien d'anormal, parce que la version publiée est déjà infectée. C'est le circuit de distribution qui ment, pas le site.

Un même schéma sous trois formes différentes

L'année 2026 a livré plusieurs cas documentés qui, mis côte à côte, racontent la même histoire sous des formes différentes. Aucun n'est isolé, et c'est justement ce qui doit retenir l'attention.

ShapedPlugin : le canal de l'éditeur détourné

L'incident le plus net est celui de ShapedPlugin, un éditeur d'extensions WooCommerce et d'affichage de contenu. Autour de la fin du mois de mai 2026, son pipeline de build a été compromis, et son serveur de mise à jour a commencé à distribuer des versions piégées à ses clients détenteurs de licence. La vulnérabilité a été publiée le 24 juin 2026 sous la référence CVE-2026-10735, avec un score CVSS de 7.5, soit une gravité élevée selon l'advisory WPScan.

Trois produits sont concernés : Smart Post Show Pro dans ses versions antérieures à 4.0.2, Real Testimonials Pro avant 3.2.5, et Product Slider for WooCommerce Pro avant 3.5.3. Le mécanisme est caractéristique de ce genre d'attaque. Le code injecté agit comme un chargeur : à chaque passage dans l'administration, il récupère une charge de second niveau depuis un serveur distant, l'installe sous la forme d'une fausse extension qui se masque de la liste des plugins, et exfiltre les identifiants ainsi que d'autres données sensibles. L'objectif final est la prise de contrôle complète du site, avec capture des mots de passe et, dans les cas observés, des codes de double authentification.

Ce qui rend l'affaire instructive, c'est la nature de la cible. Les sites infectés ne sont pas des installations négligées truffées d'extensions nulled téléchargées sur des forums douteux. Ce sont des clients payants, à jour, qui ont fait confiance à un éditeur commercial établi. La correction consiste à passer aux versions saines, mais elle ne suffit pas : une fois la charge déployée, mettre à jour l'extension ne retire pas la porte dérobée déjà installée ailleurs sur le site.

Gravity SMTP : des secrets exposés à grande échelle

Le second cas relève d'un régime différent, et la distinction compte. La faille de l'extension Gravity SMTP, suivie sous la référence CVE-2026-4020, n'est pas une compromission de la chaîne d'approvisionnement mais une vulnérabilité classique de divulgation d'informations, exploitée massivement. Elle permet à un attaquant non authentifié d'extraire des données de configuration sensibles : clés d'API, secrets, jetons OAuth stockés par l'extension.

L'ampleur donne la mesure du phénomène. Wordfence a bloqué plus de 17 millions de tentatives d'exploitation, avec une activité qui a démarré début mai 2026 avant de s'envoler autour du 6 juin 2026, jusqu'à un pic de plus de 4 millions de requêtes en une seule journée. Ce n'est pas une attaque ciblée sur quelques sites de valeur, c'est un balayage automatisé à l'échelle du web, qui teste chaque installation exposée dès qu'une faille de ce type est divulguée.

Nous plaçons ce cas à côté du précédent parce qu'il éclaire l'autre bout du problème. Une extension de messagerie mal sécurisée ne se contente pas d'ouvrir une porte : elle stocke souvent les clés qui ouvrent vos autres portes. Un jeton d'API de service d'envoi, un secret d'intégration, un identifiant de connexion à un CRM. Quand ces secrets fuient, la compromission dépasse le périmètre du site WordPress lui-même.

La technique mu-plugins, ou l'art de survivre au nettoyage

Le troisième élément n'est pas un incident de 2026 mais une technique de persistance documentée par Sucuri en juillet 2025, et régulièrement réutilisée depuis. Elle mérite sa place ici parce qu'elle explique pourquoi une compromission moderne résiste au nettoyage. Le dossier wp-content/mu-plugins/ héberge des extensions dites « must-use » : WordPress les charge automatiquement à chaque requête, elles n'apparaissent pas dans la liste standard des plugins et ne peuvent pas être désactivées depuis le tableau de bord.

Dans la campagne analysée, un fichier wp-index.php déposé à cet endroit servait de chargeur. Il décodait une URL dissimulée par un simple chiffrement ROT13, récupérait une charge de second niveau et la stockait dans la base de données, sous une clé d'options nommée _hdra_core. Le maliciel créait ensuite un compte administrateur discret, officialwp, et réinitialisait au passage les mots de passe de comptes courants comme admin ou root. En logeant son code dans un emplacement à exécution automatique et sa charge utile dans la base plutôt que dans un fichier scannable, l'attaquant obtenait une persistance profonde, capable de reconstruire la porte dérobée après une tentative de suppression partielle.

Pourquoi ces attaques passent sous les radars

La ligne commune à ces trois cas, c'est l'invisibilité. Chacune de ces menaces est conçue pour ne pas déclencher les signaux que surveillent les propriétaires de sites et une partie des outils de sécurité.

La fausse extension qui se retire de la liste des plugins ne se verra jamais dans l'écran des extensions. Le compte administrateur clandestin se fond dans une liste d'utilisateurs que personne ne relit. La charge utile stockée en base de données échappe aux scanners qui n'inspectent que les fichiers. Le chargeur logé dans les mu-plugins survit à une réinstallation des extensions visibles. Et lorsque le code injecté pratique le cloaking, c'est-à-dire qu'il sert un contenu propre à l'administrateur connecté tout en réservant les redirections et les injections aux visiteurs anonymes ou au robot de Google, le propriétaire peut naviguer sur son propre site sans jamais rien remarquer.

À cela s'ajoute la vitesse. Sur les vulnérabilités classiques comme celle de Gravity SMTP, l'exploitation de masse démarre en quelques heures après la divulgation publique. La fenêtre entre le moment où une faille devient connue et celui où votre site est testé se compte désormais en heures, pas en semaines. Attendre le week-end pour appliquer un correctif, c'est laisser la porte ouverte pendant toute la période la plus active.

La faille n'est pas dans votre site, elle est en amont

Il serait confortable de conclure que ces incidents relèvent de la négligence des éditeurs concernés. La réalité est plus structurelle, et elle tient à la gouvernance même de l'écosystème.

WordPress anime le plus grand marché d'extensions du web, mais ce marché ne repose pas sur les garde-fous présents dans d'autres écosystèmes. Il n'existe pas de signature de code obligatoire qui garantirait qu'un paquet téléchargé correspond bien à ce que le développeur a écrit et validé. Le dépôt officiel a rendu la double authentification obligatoire pour les auteurs d'extensions en octobre 2024, ce qui limite le détournement de comptes, mais rien n'analyse systématiquement le comportement d'une nouvelle version avant sa diffusion. Et lorsqu'une extension change de propriétaire, aucune revue de sécurité n'accompagne le transfert.

Ce dernier point a déjà fait des dégâts. En avril 2026, l'affaire de l'extension Essential Plugin, que nous avons documentée dans un article dédié, reposait précisément sur le rachat d'un portefeuille d'extensions à l'abandon, transformées ensuite en vecteurs d'infection. La même semaine, l'infrastructure de mise à jour de Smart Slider 3 Pro avait été compromise, exposant plusieurs centaines de milliers de sites à une version piégée poussée pendant quelques heures. Le cas ShapedPlugin de juin 2026 s'inscrit dans cette continuité. Ce n'est pas une série de coïncidences, c'est un mode opératoire qui a trouvé sa cible : la confiance accordée au canal de distribution.

Pour vous, propriétaire d'un site, cela ne veut pas dire qu'il faut cesser de mettre à jour. Une extension non corrigée reste la première cause de compromission, et de loin. Cela veut dire que la mise à jour ne peut plus être le seul pilier de votre sécurité. Il faut une seconde couche : la capacité de savoir ce qui tourne réellement sur votre site, et de le comparer à ce qui devrait y tourner.

Ce que nous vérifions concrètement

La bonne nouvelle, c'est que la défense contre ce type d'attaque ne demande pas d'outillage exotique. Elle demande de la méthode et une discipline de vérification. Sur un site dont nous avons la maintenance, nous procédons en distinguant trois temps : la détection, la réaction en cas d'incident et la prévention.

Détecter une compromission qui se cache

Le premier réflexe est de regarder ce que les écrans habituels ne montrent pas. La liste des comptes administrateurs se relit intégralement, à la recherche d'un utilisateur créé récemment ou d'un nom qui ne correspond à personne de connu. En ligne de commande, l'inspection prend quelques secondes.

wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp plugin list --status=active --fields=name,status,version

Vient ensuite le dossier des must-use plugins, souvent vide sur une installation standard. Tout fichier PHP qui s'y trouve mérite un examen, de même que la présence de chargeurs typiques ailleurs dans l'arborescence.

find wp-content/mu-plugins/ -type f -name '*.php'
grep -rEl "eval\(|base64_decode\(|str_rot13\(|gzinflate\(|assert\(" wp-content/ 2>/dev/null

Le fichier functions.php du thème actif est un autre point d'insertion privilégié : quelques lignes ajoutées en tête ou en fin de fichier suffisent à réintroduire une porte dérobée. Enfin, la base de données mérite un contrôle, car c'est là que les campagnes récentes stockent leur charge utile. Une clé d'options au nom inhabituel, un contenu chiffré ou encodé dans wp_options sont des signaux à ne pas ignorer. Sur les sites qui utilisent une extension de messagerie, nous vérifions aussi que les identifiants SMTP et les clés d'API stockées correspondent bien à ceux que nous avons configurés, et qu'aucun secret n'a été modifié à notre insu.

Réagir sans aggraver la situation

Si l'un de ces contrôles remonte quelque chose d'anormal, la précipitation est mauvaise conseillère. Supprimer le fichier visible sans traiter la persistance en base ou dans les mu-plugins ne fait que masquer le problème quelques heures, jusqu'à ce que le chargeur reconstruise la porte dérobée. La séquence que nous suivons commence par isoler avant de nettoyer.

Concrètement, cela signifie considérer que tous les secrets du site sont compromis. Les mots de passe de l'ensemble des comptes sont réinitialisés, les secrets de double authentification révoqués et régénérés, et surtout les clés d'API et jetons manipulés par le site, ceux d'un service d'envoi de courriels ou d'une passerelle de paiement par exemple, sont invalidés côté fournisseur puis recréés. Un mot de passe changé ne sert à rien si l'attaquant détient déjà une clé qui lui donne un accès parallèle. La restauration s'appuie ensuite sur une sauvegarde antérieure à la date probable de compromission, ce qui suppose d'avoir daté l'infection, et non sur la dernière sauvegarde disponible qui contient peut-être déjà la charge. C'est tout l'intérêt d'une rétention de sauvegardes suffisamment longue, un point que nous développons dans notre article sur la maintenance préventive.

Réduire la surface avant l'incident

La prévention réelle se joue en amont, sur la composition du site. Chaque extension installée est une dépendance dont vous héritez de toute la chaîne de confiance : le sérieux du développeur, la sécurité de son infrastructure, sa réactivité en cas de faille. Un site qui embarque quarante extensions expose quarante fois cette surface. Le premier geste préventif est donc un audit honnête de ce qui est réellement utile, et le retrait de tout ce qui dort sans servir.

Ensuite vient le monitoring d'intégrité, qui prend le relais là où la mise à jour ne protège plus. Un dispositif qui surveille l'apparition ou la modification de fichiers, en particulier dans wp-config.php, functions.php et le dossier des mu-plugins, alerte sur ce que le tableau de bord ne montre pas. Un pare-feu applicatif filtre en amont les tentatives d'exploitation de masse comme celles observées sur Gravity SMTP, et gagne un temps précieux quand une faille est divulguée et exploitée dans la journée. Nous conservons enfin des sauvegardes multiples, à la fois côté hébergeur et dans un emplacement hors ligne indépendant, parce qu'une sauvegarde stockée au même endroit que le site peut être chiffrée ou effacée en même temps que lui. Aucune de ces mesures n'est spectaculaire. Prises ensemble, elles transforment une compromission potentiellement silencieuse et durable en un incident détecté tôt et réparable.

Rester à jour sans rester naïf

La leçon de ces incidents n'est pas de se méfier des mises à jour, ce serait le pire des conseils. Une extension obsolète reste la porte d'entrée la plus fréquente, et la mise à jour demeure votre meilleur rempart au quotidien. La leçon, c'est qu'elle ne peut plus être votre seul rempart. Le jour où le canal de distribution lui-même devient l'attaquant, seule une seconde couche de vérification permet de s'en apercevoir.

Cette seconde couche n'a rien de réservé aux grandes structures. Relire ses comptes administrateurs, surveiller l'intégrité de quelques fichiers sensibles, garder des sauvegardes datées et hors ligne, savoir qui contacter et avec quels accès en cas d'urgence : ce sont des gestes de bon sens, à la portée de n'importe quel site, à condition qu'ils soient posés à froid et non improvisés dans la panique d'une infection. C'est précisément ce travail de fond, discret et régulier, qui distingue un site simplement en ligne d'un site réellement tenu.

Chez MtoM Création, c'est la part la moins visible de notre métier, et sans doute la plus utile. Si vous n'êtes pas certain de ce qui tourne réellement sous le capot de votre site, ou si vous voulez qu'un regard extérieur passe en revue vos extensions et votre dispositif de sauvegarde, c'est exactement le genre de conversation que nous aimons avoir avant qu'un incident ne la rende urgente.