WordPress : 30 plugins rachetés en silence pour y dissimuler une porte dérobée pendant 8 mois

Huit mois. C'est le temps qu'une porte dérobée a sommeillé dans trente extensions WordPress, téléchargées chaque jour par des milliers de sites, avant d'être déclenchée début avril 2026. Derrière cette attaque méticuleuse, pas d'exploit zero-day ni de faille de sécurité classique : juste un rachat d'entreprise, une signature SVN légitime et huit années de confiance instrumentalisées. L'affaire, révélée par Austin Ginder (Anchor Hosting) au terme d'une analyse forensique, est un cas d'école sur la fragilité de la supply chain open source.

Quand un rachat d'éditeur devient un cheval de Troie

À l'origine de l'affaire, un studio indien bien connu de la communauté : Minesh Shah, Anoop Ranawat et Pratik Jain, auteurs du portefeuille « Essential Plugin », lancé vers 2015. Une trentaine d'extensions utilitaires (compteurs, popups, analytics…), sans scandale, avec une base d'utilisateurs stable et des millions de téléchargements cumulés.

Fin 2024, les revenus publicitaires des auteurs s'effondrent de 35 à 45 %. Le portefeuille est alors mis en vente sur Flippa. L'acheteur se présente comme « Kim Schmidt », basé à Zurich, avec une adresse ProtonMail. Le montant du deal atteint un six chiffres en dollars. En coulisses, il s'agit en réalité d'un pseudonyme — « Kris » — déjà connu dans l'écosystème marketing gris (SEO black-hat, crypto, paris en ligne).

Le 12 mai 2025, un nouveau compte est créé sur WordPress.org et hérite de l'accès SVN à l'ensemble des plugins. Ni signature rouge, ni audit particulier : c'est exactement le comportement attendu après un rachat officiel.

Huit mois de silence avant le déclenchement

Le premier commit malveillant est daté du 8 août 2025, camouflé en mise à jour de compatibilité pour Countdown Timer Ultimate v2.6.7. Le code est introduit dans le composant wpos-analytics, via 191 lignes ajoutées à class-anylc-admin.php. Rien ne déclenche d'alerte : la modification ressemble à un module analytics maison.

La chaîne d'exploitation repose sur plusieurs ingrédients combinés :

• récupération d'une fonction distante via file_get_contents() ;
• désérialisation non sécurisée avec @unserialize() sur la réponse du serveur de commande ;
• exposition d'un endpoint REST non authentifié ;
• injection d'un code PHP arbitraire directement dans wp-config.php, le fichier le plus sensible de l'installation.

Le dispositif reste dormant pendant huit mois. Puis, entre le 5 et le 6 avril 2026, l'attaquant active la charge utile dans une fenêtre de six heures et quarante-quatre minutes. Durée volontairement courte pour limiter la visibilité dans les logs et compliquer la détection par les hébergeurs.

Une charge utile pensée pour le SEO, pas pour le rançongiciel

La particularité de l'attaque, c'est sa cible : pas de vol de données, pas de chiffrement, pas de minage de crypto. Le code récupère depuis un serveur C2 une liste de liens spam et de redirections qu'il injecte dans les pages servies… uniquement au bot Google. Pour le propriétaire du site, tout paraît normal. Pour le moteur de recherche, le site se transforme en hub de backlinks frauduleux au profit de sites de paris et de crypto.

Plus fort encore : la résolution de domaine du serveur de commande passe par un smart contract Ethereum. Concrètement, l'adresse du C2 n'est pas stockée en dur mais lue sur la blockchain, ce qui rend le blocage DNS ou le sinkholing quasi inopérants. Couper un nom de domaine ne suffit plus — il faudrait agir au niveau du contrat lui-même.

WordPress.org a réagi en fermant 31 extensions simultanément début avril 2026. Une purge d'ampleur, justifiée, mais qui laisse des milliers de sites bloqués sans alternative immédiate.

Que faire concrètement pour protéger vos sites ?

Cette affaire rappelle brutalement une évidence : dans l'open source, un plugin n'est pas seulement un bout de code, c'est aussi un mainteneur. Quelques réflexes réduisent sérieusement la surface d'attaque :

• Auditer régulièrement ses plugins : qui les maintient aujourd'hui ? Un changement d'éditeur récent est un signal à vérifier avant d'accepter une mise à jour automatique.
• Surveiller les diffs sur les plugins critiques : 191 lignes injectées dans un fichier admin auraient dû sauter aux yeux d'un code review, même rapide.
• Mettre en place une intégrité fichier (checksum sur wp-config.php, surveillance des écritures) pour détecter toute modification hors déploiement.
• Restreindre les endpoints REST non utilisés et s'assurer qu'aucune route publique n'appelle unserialize() sur une entrée distante.
• Journaliser les requêtes sortantes de PHP : un file_get_contents() vers un domaine inconnu doit pouvoir être repéré.
• Activer un WAF et une politique de mises à jour différées de 24-48h, le temps que la communauté valide les nouvelles versions.

Mon retour

J'interviens régulièrement sur des WordPress clients, et la discussion autour des plugins se limite souvent à « est-ce qu'il est à jour ? ». Ce n'est plus suffisant. Un plugin à jour peut être la porte d'entrée, précisément parce qu'il a été mis à jour par un éditeur racheté en silence. La confiance dans une chaîne d'approvisionnement ne se décrète pas : elle se vérifie. Cette attaque aura au moins eu un mérite, celui de relancer le débat sur la gouvernance des dépôts officiels et la traçabilité des cessions de maintenance.