Quelqu’un a racheté 30 plugins WordPress et y a implanté une porte dérobée dans chacun d’eux

• Le même attaquant a racheté plus de 30 plugins WordPress, puis a inséré du code de porte dérobée dès le premier commit, compromettant ainsi la chaîne d’approvisionnement
• Le code malveillant est resté dormant pendant environ 8 mois, avant de s’activer début avril 2026 pour injecter sur de nombreux sites des liens de spam et des redirections
• WordPress.org a fermé définitivement 31 plugins concernés en une seule journée, le 7 avril 2026, et a déployé des mises à jour forcées
• L’attaquant a acquis sur Flippa le portefeuille « Essential Plugin » pour un montant à six chiffres, puis a utilisé un smart contract Ethereum pour masquer le domaine C2
• Cet incident reproduit à grande échelle l’attaque de la chaîne d’approvisionnement observée en 2017 avec « Display Widgets » et met en lumière l’absence de gestion de la confiance dans l’écosystème des plugins WordPress

---

Cas d’attaque de la chaîne d’approvisionnement des plugins WordPress

• Plus de 30 plugins WordPress ont été rachetés par un même attaquant, puis piégés avec une porte dérobée
• L’attaquant a acheté sur Flippa le portefeuille « Essential Plugin » pour un montant à six chiffres, puis a ajouté du code malveillant dès le premier commit
• La porte dérobée est restée inactive pendant 8 mois avant de s’activer début avril 2026 et d’infecter un grand nombre de sites
• WordPress.org a fermé définitivement 31 plugins liés à l’incident en une seule journée, le 7 avril 2026
• L’incident est considéré comme une répétition du schéma d’attaque de la chaîne d’approvisionnement similaire à l’affaire « Display Widgets » de 2017

Découverte de l’attaque et réponse initiale

• La première infection a été confirmée via une alerte de sécurité dans wp-admin sur le site d’un client
  • L’équipe des plugins WordPress.org a averti que le plugin « Countdown Timer Ultimate » contenait du code permettant un accès non autorisé
  • WordPress.org a déployé une mise à jour forcée (v2.6.9.1), mais certains sites étaient déjà compromis
• L’audit de sécurité a montré que le module wpos-analytics du plugin se connectait à analytics.essentialplugin.com pour télécharger le fichier wp-comments-posts.php, qui servait ensuite à effectuer une injection massive de code PHP dans wp-config.php

Fonctionnement du malware

• Le code injecté récupérait depuis le serveur C2 des liens de spam, des redirections et de fausses pages, affichés uniquement à Googlebot
• L’attaquant utilisait un smart contract Ethereum pour gérer dynamiquement le domaine C2
  • Le domaine était résolu via un endpoint RPC blockchain, ce qui le rendait impossible à bloquer avec un simple blocage de domaine
• La mise à jour forcée de WordPress.org n’a fait qu’interrompre la fonction de phone-home du plugin, tandis que le code malveillant dans wp-config.php restait en place

Traçage du moment de l’infection via l’analyse des sauvegardes

• À l’aide des sauvegardes restic de CaptainCore, la taille de 8 versions successives de wp-config.php a été comparée
  • Entre le 6 avril 2026 à 04:22 et 11:06 UTC, la taille du fichier est passée de 3 345 octets à 9 540 octets
  • L’infection a donc été confirmée dans cet intervalle de 6 heures et 44 minutes

Moment d’insertion de la porte dérobée et structure du code

• Dans la version 2.6.7 du plugin (8 août 2025), 191 nouvelles lignes de code ont été ajoutées, marquant l’insertion de la porte dérobée
  • Le journal des modifications indiquait « Compatibilité confirmée avec WordPress 6.8.2 »
• Fonctions principales du code ajouté
  1. fetch_ver_info() traite avec @unserialize() les données venant du serveur de l’attaquant
  2. version_info_clean() exécute le nom de fonction reçu dans les données distantes
  3. Création d’un endpoint d’API REST appelable sans authentification (permission_callback: __return_true)
• Cette structure permet une exécution arbitraire de fonctions (RCE) et est restée inactive pendant 8 mois avant d’être activée les 5 et 6 avril 2026

Processus de rachat des plugins

• L’équipe de développement d’origine était WP Online Support, basée en Inde, qui développait ces plugins depuis 2015
  • Elle s’est ensuite rebaptisée Essential Plugin et exploitait plus de 30 plugins gratuits et payants
• Fin 2024, après une baisse de chiffre d’affaires de 35 à 45 %, l’entreprise a mis en vente l’ensemble de l’activité sur Flippa
• Début 2025, une personne nommée « Kris » a racheté l’ensemble, avec un passé dans le SEO, les cryptomonnaies et le marketing des jeux d’argent en ligne
  • En juillet 2025, Flippa a présenté cette transaction comme une success story sur son blog
• Dès le premier commit SVN après le rachat (8 août 2025), le code de porte dérobée a été ajouté
• Les 5 et 6 avril 2026, analytics.essentialplugin.com a commencé à distribuer la charge utile malveillante à tous les sites
• Le 7 avril 2026, WordPress.org a fermé définitivement tous les plugins d’Essential Plugin (31 au total)

Liste des plugins fermés

• Accordion and Accordion Slider, Countdown Timer Ultimate, Popup Anything on Click, WP Blog and Widgets, WP Team Showcase and Slider et plus de 30 autres plugins
• Une recherche de cet auteur sur WordPress.org ne renvoie désormais aucun résultat
• analytics.essentialplugin.com renvoie actuellement la réponse {"message":"closed"}

Cas similaires dans le passé

• En 2017, une personne nommée « Daley Tias » a racheté le plugin Display Widgets (200 000 installations) pour 15 000 $, avant d’y injecter du code de spam
• Plus de 9 autres plugins ont ensuite été infectés de la même manière
• L’incident actuel est confirmé comme une reproduction de la même méthode, mais à une échelle plus importante (plus de 30 plugins)

Réparation des dégâts et travail de correctif

• La mise à jour forcée de WordPress.org n’était qu’une mesure temporaire
  • Le module wpos-analytics lui-même était toujours présent
• Une version corrigée supprimant complètement le module de porte dérobée a été créée en interne
  • Parmi 22 sites clients, des plugins Essential Plugin ont été trouvés sur 12 sites, et 10 ont été corrigés manuellement
  • La version corrigée supprime le répertoire wpos-analytics, retire la fonction de chargement et ajoute -patched au numéro de version
• Exemples : Countdown Timer Ultimate, Popup Anything on Click, WP Testimonial with Widget

Méthode de correctif manuel

• Supprimer le répertoire wpos-analytics/
• Retirer du fichier principal du plugin le bloc « Plugin Wpos Analytics Data Starts » ou le bloc wpos_analytics_anl
• Ajouter -patched à l’en-tête Version:, puis recompresser le plugin
• Installer avec wp plugin install your-plugin-patched.zip --force
• Si la taille du fichier wp-config.php a augmenté d’environ 6 Ko, il faut considérer le site comme activement infecté et procéder à une restauration complète

Problème de confiance dans l’écosystème des plugins WordPress

• Au cours des 2 dernières semaines, des attaques de la chaîne d’approvisionnement se sont succédé
  • Rachat de plugins de confiance puis insertion de code malveillant
  • Héritage direct des droits de commit sur WordPress.org et diffusion sans vérification supplémentaire
• WordPress.org ne dispose d’aucun mécanisme de surveillance des changements de propriété ni de réexamen du code
  • Aucun avertissement utilisateur ni revue automatique lors de l’ajout d’un nouveau committer
• La réaction de l’équipe des plugins a été rapide, mais l’insertion de la porte dérobée est restée non détectée pendant 8 mois
• Les administrateurs de sites WordPress doivent vérifier la liste de leurs plugins, supprimer ou corriger immédiatement les plugins de la gamme Essential Plugin, et contrôler impérativement le fichier wp-config.php

[tebica]

J’utilise WordPress depuis des décennies…
Je n’utilise qu’un minimum de plugins, mais malgré tout je reste toujours un peu inquiet.
Cela dit, c’est encore plus pratique que du statique, donc je n’ai pas envie de migrer !

[turastory]

On voit beaucoup de nouvelles ces temps-ci sur les attaques de la chaîne d’approvisionnement… :’(

[tangokorea]

C’est comme ça. Ça a brusquement augmenté.

[xguru]

WordPress, vraiment… les problèmes n’arrêtent pas. Si vous l’utilisez déjà, regardez des articles sur le sujet et des solutions comme EmDash.
Pour ma part, je l’ai déjà abandonné et je suis simplement passé à des pages statiques.

[colus001]

J’ai essayé EmDash, mais pour l’instant c’est beaucoup trop lent. Le TTFB est de base d’au moins 3 secondes, donc je me demande vraiment si c’est censé être utilisable.

[xguru]

Ah, d'accord. Alors je vais simplement me contenter du statique haha

[tangokorea]

Cela donne l’impression que l’IA pourrait remplacer les CMS recouverts de code legacy en gérant des pages statiques.

[GN⁺]

Réactions sur Hacker News

• Les réactions exagérées à propos de Mythos me font toujours rire
  La détection automatisée de vulnérabilités peut bien bouleverser l’industrie de la sécurité, mais ce n’est pas ça le vrai sujet d’inquiétude
  Les stacks techniques actuelles et la gouvernance d’entreprise sont déjà dépassées
  S’il faut désigner le principal responsable de l’aggravation de la situation, c’est la crypto. Elle a transformé le piratage en industrie de plusieurs milliards de dollars et a même attiré des États comme la Corée du Nord
  Nous vivons désormais dans une réalité où il suffit d’acheter des dépendances ou de payer des employés pour provoquer des « erreurs »
  Nous pouvons écrire des logiciels avec très peu de bugs, mais nous n’avons aucun plan pour garder les grandes entreprises en sécurité dans cet environnement
  Des agents LLM autonomes seront utilisés par des groupes de ransomware, mais ils n’auront même pas besoin d’exploits FreeBSD

  • Je doute de l’affirmation selon laquelle « on peut utiliser des logiciels avec très peu de bugs »
    En pratique, je tombe chaque semaine sur des bugs dans PrimeVue, Vue, Spring Boot, le driver Oracle, Ansible, les drivers Nvidia, etc.
    De façon réaliste, un code totalement sans défaut n’est sans doute possible que pour des avions ou des engins spatiaux
    La plupart des développeurs n’écrivent pas du code bogué non pas par manque de volonté, mais parce que les contraintes de l’environnement le rendent souvent impossible
  • Comme dans le cas de LAPSUS$, certains groupes de pirates ont obtenu un accès interne simplement en soudoyant des employés
    Ce n’est pas une théorie, c’est la réalité. Avec les moyens financiers d’un État, acheter des initiés devient encore plus facile
  • À mes yeux, c’est davantage un problème de culture d’organisation que de technologie
    Les projets OSS ont moins de bugs « WTF » que les logiciels de grandes entreprises
    Dans une organisation, on déploie tels quels des erreurs qu’on ne ferait jamais seul, à cause des processus d’approbation ou des habitudes
    Une culture dysfonctionnelle où personne ne peut demander « est-ce vraiment la meilleure solution ? » produit des bugs à la chaîne
    C’est facile à changer dans une petite équipe, mais coûteux dans une grande organisation
  • Si des attaquants peuvent mettre à jour des domaines C2 via des smart contracts Ethereum, faut-il alors que les pare-feu bloquent tous les endpoints Ethereum ?
  • Comme le dit l’article de The Register, il est rationnel pour des attaquants de traiter la supply chain comme un objet d’analyse coût-risque

• Dans les projets web, on commence toujours par « npm install », et des dizaines de bibliothèques s’installent automatiquement
  Souvent, même l’auteur ne sait pas quelles dépendances transitives sont incluses
  Dans une telle structure, il n’y a presque aucune chance de vérifier une attaque de supply chain

  • C’est pour cela que j’évite autant que possible les packages externes
    J’ai récemment écrit un outil de synchronisation météo uniquement avec la bibliothèque standard Python
    Je n’avais pas besoin de packages externes comme requests, et j’ai gagné la tranquillité d’esprit sans dépendances
  • On dit souvent qu’il ne faut pas « réinventer la roue », mais il faut un juste milieu
    Il ne faut pas implémenter soi-même des briques critiques comme la cryptographie, mais dépendre d’une bibliothèque pour des fonctions simples est excessif
  • Ce n’est pas un problème propre au web, c’est un problème commun à tous les écosystèmes, comme maven, Python, Ruby, etc.
  • Le lockfile aide plus qu’on ne le pense
    Si les versions sont figées, même si un package est revendu puis backdooré, on n’est pas affecté tant qu’on ne fait pas soi-même la mise à jour
    Ce qui fait encore plus peur, c’est quand Dependabot ouvre automatiquement une PR de « patch version » et introduit le risque
  • Pire encore, il y a l’habitude du sudo curl URL | bash

• Je pense que le vrai problème est l’idéologie même de la mise à jour logicielle
  Les mises à jour ont l’avantage des correctifs de sécurité, mais elles peuvent aussi imposer des changements non souhaités par le développeur ou devenir malveillantes
  Pour les extensions WordPress développées par des indépendants, il vaut mieux ne jamais autoriser les mises à jour automatiques
  La marketplace wordpress.org ne prend pas en charge ce type de fonctionnement, ce qui la rend risquée
  J’avais déjà écrit un commentaire sur les extensions Chrome, et si on remplace Chrome par WordPress, ça reste entièrement valable

• La surface d’attaque de supply chain des plugins WordPress est risquée depuis longtemps
  C’est dû à la structure de l’écosystème, qui pousse à installer en grand nombre de petits plugins créés par des développeurs individuels
  Racheter puis détourner un plugin qui a déjà gagné la confiance des utilisateurs est une méthode d’attaque extrêmement efficace
  Comme les « notifications de mise à jour » servent de signal de confiance, les utilisateurs ne remarquent même pas que l’auteur a changé
  Il faudrait des signatures de packages et un système de transparence, mais WordPress progresse lentement sur son infrastructure de sécurité

  • La plupart des utilisateurs ne veulent utiliser que des plugins gratuits, donc les sites finissent recouverts de plugins premium + publicité
    La page d’administration ressemblait presque à un mème de barres d’outils IE6
  • C’est aussi pour cela que j’ai arrêté de créer des sites WordPress pour des clients
    Beaucoup installaient juste la version gratuite de Securi ou Wordfence et s’attendaient à une sécurité complète sans même faire la configuration
  • wp.org est bien trop indulgent envers les acteurs malveillants
    Les malwares évidents sont bloqués, mais les bait-and-switch du type insertion de widgets publicitaires depuis des domaines tiers sont tolérés
    À ce niveau-là, on peut presque parler de choix de conception délibéré

• C’est dommage que le projet de gestionnaire de paquets FAIR n’ait pas réussi
  fair.pm propose une architecture décentralisée inspirée d’atproto, que n’importe qui peut opérer sans dépôt central
  Les paquets sont identifiés par des DID, et des organismes comme Socket peuvent attacher leurs résultats d’analyse sous forme de « labelers »
  Les utilisateurs peuvent bloquer les paquets portant certains labels, ou même exploiter eux-mêmes un labeler d’analyse de sécurité basé sur l’IA
  Ce n’est pas parfait, mais c’est une approche bien meilleure qu’un gestionnaire de paquets centralisé

  • Le projet n’a pas été abandonné, il s’est réorienté vers la technologie
    Il collabore actuellement avec la communauté Typo3 et s’étend à d’autres écosystèmes (l’auteur est coprésident de FAIR)
  • Cela pourrait devenir une plateforme intéressante comme alternative à npm
    La structure d’incitation y est meilleure que sur WordPress, mais peut-être pas encore suffisante
  • S’il est probable que de nombreux dépôts soient remplis de malwares SEO, il sera impossible de trouver un dépôt sûr à l’aide des seuls moteurs de recherche
    La décentralisation apporte de la liberté, mais du point de vue utilisateur, c’est très inconfortable
  • Je me demande si FAIR est réservé à WordPress

• Ce qui est intéressant dans cette affaire, c’est que les plugins ont été rachetés sur Flippa
  Flippa n’est pas une marketplace dédiée à WP, mais une plateforme générale d’achat-vente de logiciels
  C’est inquiétant, car même des apps ou extensions indé acquises de bonne foi peuvent ensuite être transformées en armes
  Pour ce type d’applications, elles ont parfois plus de valeur pour des attaquants que pour de vrais opérateurs

• Le plus effrayant, ce n’est pas le backdoor en lui-même, mais le fait que le rachat ait eu l’air tellement normal
  Acheter un plugin de confiance puis pousser une mise à jour ne se distingue pas d’une maintenance légitime
  Il n’y a aucun signal qui pousse l’utilisateur à se méfier

• Les fusions-acquisitions qui limitent la concurrence sur le marché doivent parfois être approuvées par l’État
  Dans ce cas, ne faudrait-il pas aussi une procédure d’approbation par la marketplace ou par les autorités pour les acquisitions ayant un impact majeur sur la sécurité ?
  Voir l’article Wikipédia sur les Mergers and acquisitions

• WordPress a été formidable grâce à ses plugins, mais aujourd’hui, cette architecture de plugins en fait un écosystème dangereux
  Je suis passé à Hugo, et je recommande aussi aux autres ce guide de migration

• Les entreprises ne semblent pas se rendre compte de l’ampleur du contrôle qu’elles ont perdu en pratiquant l’« externalisation IT »