Vos plugins WordPress étaient à jour, et ça n'a pas suffi

Ce qui s'est passé

Le 7 août 2026, l'éditeur de sécurité Wordfence est alerté d'attaques visant des sites WordPress équipés d'extensions publiées par BdThemes, un fournisseur de modules complémentaires pour le constructeur de pages Elementor. Sept extensions sont concernées, dont Element Pack Addons for Elementor, qui revendique plus de 100 000 installations actives.

Les 7 et 8 août, WordPress.org ferme l'accès au téléchargement de ces sept extensions, le temps d'un réexamen. Les premières traces de la campagne, d'après les horodatages relevés, pourraient remonter au 23 juin.

Jusque-là, le récit ressemble à beaucoup d'autres. C'est le mécanisme qui mérite l'attention.

Ces extensions affichent, dans le tableau de bord de l'administrateur, des bannières promotionnelles de leur éditeur — des annonces de nouvelles versions, des offres commerciales. Ces bannières ne sont pas écrites en dur dans le code : l'extension va les chercher, à chaque affichage, dans un fichier de données hébergé chez l'éditeur. Un attaquant a obtenu l'accès à cet hébergement et a remplacé le contenu de ce fichier par du code malveillant.

Restait à le faire exécuter. C'est là qu'intervient une seconde faiblesse : le composant chargé d'afficher la bannière insérait une des valeurs reçues dans la page sans la neutraliser au préalable. Une faille classique, introduite le 1^er mars 2026, et cotée 5,4 sur 10 — une sévérité « moyenne » qui, seule, n'aurait alerté personne.

Résultat, pour un site touché : à la simple ouverture du tableau de bord par un administrateur, du code s'exécutait dans son navigateur, avec ses droits. Ce code en profitait pour créer un compte administrateur discret et déposer, ailleurs sur le site, des fichiers permettant de reprendre la main plus tard — y compris après désinstallation de l'extension.

Pourquoi la mise à jour n'y pouvait rien

C'est le point qui dérange, et c'est celui qu'il faut comprendre.

Le conseil qu'on donne partout — et que nous donnons nous-mêmes, y compris dans notre article sur la faille wp2shell — c'est de tenir son site à jour. C'est juste, et ça reste la mesure au meilleur rapport effort/résultat. Mais ici, cela n'aurait rien changé : le code publié sur WordPress.org était propre. Un site parfaitement à jour, mis à jour automatiquement, audité la veille, était exposé — et comme le composant en cause n'est arrivé qu'en mars, il fallait même avoir appliqué ses mises à jour pour l'être.

La raison tient en une phrase : une extension n'est pas seulement le code qu'elle contient, c'est aussi tout ce qu'elle va chercher ailleurs pendant qu'elle tourne. Vérifier la version installée ne dit rien de ce que cette version télécharge et exécute une fois en service.

C'est le même raisonnement que pour les scripts tiers chargés par un site : le jour où le serveur d'en face change de contenu, votre site sert ce nouveau contenu à vos visiteurs, sans que rien n'ait bougé chez vous.

Le tableau de bord fait partie de la surface d'attaque

Il y a une habitude tenace, dans les PME comme ailleurs : considérer que la partie publique du site est la zone à risque, et que l'administration, protégée par un mot de passe, est un endroit sûr.

Cet incident dit le contraire. La charge malveillante ne visait pas les visiteurs : elle attendait qu'un administrateur se connecte. Elle ne s'exécutait pas sur le serveur, mais dans le navigateur de la personne qui avait le plus de droits sur le site. Autrement dit, le fait de se connecter était la condition du déclenchement, pas une protection contre lui.

Corollaire pratique : le nombre de comptes disposant du rôle administrateur n'est pas un détail d'organisation, c'est une mesure de sécurité. Chaque personne qui ouvre ce tableau de bord est une occasion de déclencher ce qui s'y trouve. L'ancien stagiaire qui a gardé son accès, le prestataire passé il y a trois ans, le compte partagé « admin » que tout le monde utilise : autant de déclencheurs potentiels, pour un bénéfice nul.

La fonctionnalité qui vous a exposé n'était pas pour vous

Il vaut la peine de s'arrêter sur la nature du composant en cause. Ce flux distant ne servait à rien de ce pour quoi ces extensions ont été installées. Il n'affichait pas une page, ne construisait pas une mise en page, n'accélérait rien. Il affichait les annonces commerciales de l'éditeur.

C'est une catégorie de code qu'on retrouve dans beaucoup de logiciels : la remontée de statistiques d'usage, la vérification de licence, le bandeau « passez à la version Pro », la notification de nouveauté. Ces fonctions servent le modèle économique du fournisseur. Elles n'apportent rien au client, et elles élargissent pourtant sa surface d'exposition — puisqu'elles ouvrent, en permanence, un canal entre son site et une infrastructure qu'il ne maîtrise pas.

On ne peut pas toujours les désactiver. Mais on peut en tenir compte au moment de choisir : à fonctionnalité équivalente, une extension qui ne parle à personne vaut mieux qu'une extension qui interroge trois serveurs par jour. Et une extension de moins vaut toujours mieux qu'une extension de plus.

Ce qu'une PME peut vérifier cette semaine

Si votre site tourne sous WordPress — c'est le cas de la majorité des sites vitrines de PME — quelques vérifications valent le quart d'heure qu'elles prennent, que vous utilisiez ces extensions ou non :

• Passez en revue la liste des comptes administrateurs. Un seul nom que personne ne reconnaît suffit. Vérifiez aussi les dates de création : un compte apparu sans raison entre juin et août doit être examiné.
• Retirez les droits devenus inutiles. Anciens salariés, prestataires terminés, comptes de test. Un compte qui ne sert plus n'a pas besoin d'être supprimé dans l'heure, mais il n'a aucune raison de rester administrateur.
• Faites l'inventaire des extensions installées, y compris celles qui sont désactivées — une extension désactivée reste sur le serveur. Désinstallez ce qui ne sert plus.
• Sachez qui met à jour, et selon quel rythme. Si la réponse est « personne » ou « je ne sais pas », c'est le premier sujet à traiter, avant tout le reste.
• Vérifiez que vous avez une sauvegarde restaurable. Face à une compromission, la seule remise à zéro fiable consiste à repartir d'un état antérieur connu — encore faut-il disposer d'un point de restauration antérieur à juin, et avoir déjà essayé de s'en servir.

Si vous utilisez effectivement une des extensions concernées, l'affaire est plus sérieuse : la désinstaller ne suffit pas, puisque le mécanisme de persistance a été déposé en dehors d'elle. Il faut faire inspecter le site — comptes, fichiers ajoutés, options en base — avant de le considérer comme sain.

Notre lecture

Cet incident ne condamne ni WordPress, ni les extensions, ni l'éditeur concerné, qui est lui-même victime d'une intrusion sur son hébergement. Il rappelle simplement que la question « est-ce que mon site est à jour ? » est une bonne question, mais pas la seule.

Celle qui manque, et qu'on pose rarement, est : avec qui mon site parle-t-il, tout seul, sans que je le sache ? Chaque extension installée est un fournisseur de plus, avec sa propre infrastructure, ses propres pratiques et son propre niveau d'exposition. On ne peut pas auditer tout le monde. On peut, en revanche, en avoir le moins possible, savoir lesquels sont là, et être capable de revenir en arrière quand l'un d'eux tombe.

C'est moins spectaculaire qu'un pare-feu, mais c'est ce qui distingue un site qu'on remet debout en une matinée d'un site qu'on découvre compromis trois mois plus tard.

Sources : l'analyse publiée par Wordfence (Defiant) le 8 août 2026, reprise et recoupée par BleepingComputer, Infosecurity Magazine, The Hacker News et Cyber Security News ; dates de fermeture relevées sur les fiches WordPress.org des extensions concernées. Wordfence, qui a analysé et documenté la campagne, est éditeur de solutions de sécurité pour WordPress et donc partie prenante du sujet. Au moment de la rédaction, BdThemes n'avait pas publié de communiqué public.