Trente et une extensions rachetées, une porte dérobée dans chacune : votre site dépend de code que vous n'avez jamais choisi

Au printemps, WordPress.org a fermé définitivement trente et une extensions d'un même auteur. Elles contenaient toutes une porte dérobée. Personne ne s'était introduit chez le développeur, aucun mot de passe n'avait été volé et aucune faille n'avait été exploitée pour y arriver.

L'entreprise avait simplement été vendue.

C'est le genre d'incident qui ne cadre pas avec la façon dont on parle habituellement de sécurité web. On répète qu'il faut garder son site à jour. Ici, les sites compromis étaient à jour. C'est précisément ce qui les a compromis.

Voici ce qui s'est passé, et surtout ce que ça change dans la façon dont nous évaluons les dépendances d'un projet.

‍

Ce qui s'est passé

‍

Le portefeuille Essential Plugin, anciennement WP Online Support, regroupait une trentaine d'extensions WordPress développées depuis 2015. Rien d'exotique : des carrousels, des minuteries, des fenêtres modales. Le genre d'outils installés sur des dizaines de milliers de sites sans que personne n'y repense.

Après un recul de revenus de 35 à 45 %, le développeur original a mis l'entreprise en vente sur Flippa, une place de marché pour entreprises numériques. Un acheteur se présentant sous le nom de Kris a acquis l'ensemble du portefeuille pour un montant à six chiffres, au début de 2025. La transaction s'est déroulée normalement. Flippa en a même publié une étude de cas en juillet 2025.

En mai 2025, un nouveau compte WordPress.org a reçu les accès de publication pour les trente et une extensions.

Le 8 août 2025, un premier commit est arrivé. Version 2.6.7, avec un changelog annonçant une vérification de compatibilité avec WordPress 6.8.2. En réalité, cette mise à jour ajoutait 191 lignes de code PHP dissimulées dans le module d'analytique existant de l'extension, dont une porte dérobée par désérialisation.

Puis, plus rien. Pendant huit mois.

Les 5 et 6 avril 2026, la porte dérobée a été activée. Pendant environ six heures et quarante-cinq minutes, un serveur contrôlé par l'attaquant a distribué sa charge utile aux sites concernés. Le mécanisme injectait du contenu dans le fichier de configuration du site et servait du pourriel de référencement visible uniquement par le robot d'indexation de Google. Autrement dit, les propriétaires de sites ne voyaient absolument rien d'anormal en visitant leur propre site.

Le 7 avril, l'équipe des extensions de WordPress.org a fermé définitivement les trente et une extensions concernées.

‍

Pourquoi les mises à jour automatiques ont joué contre les sites

‍

C'est la partie inconfortable.

Habituellement, appliquer rapidement les mises à jour est la bonne décision, et les données le confirment. Selon le rapport annuel de Patchstack sur la sécurité de WordPress, publié en février, le délai médian pondéré entre la divulgation d'une vulnérabilité fortement exploitée et son exploitation de masse était de cinq heures en 2025. Cinq heures. Dans ce contexte, attendre une semaine avant de mettre à jour n'est pas une position prudente, c'est un pari.

Sauf que dans le cas d'Essential Plugin, le canal de distribution lui-même était compromis. Les sites qui avaient activé les mises à jour automatiques, c'est-à-dire ceux qui suivaient exactement la bonne pratique, ont reçu la version piégée sans intervention humaine et sans avertissement.

Il faut être clair sur la conclusion à en tirer, parce que la mauvaise conclusion est tentante : ce n'est pas une raison de désactiver les mises à jour automatiques. Le risque de ne pas mettre à jour reste largement supérieur.

C'est une raison de comprendre que la mise à jour est une condition nécessaire, mais qu'elle ne constitue pas à elle seule une stratégie de sécurité. Ce que vous mettez à jour compte autant que la vitesse à laquelle vous le faites.

‍

Trois incidents, trois mécanismes différents, la même leçon

‍

Essential Plugin n'est pas un cas isolé, et ce n'est pas non plus un problème propre à WordPress.

La même semaine, l'extension Smart Slider 3 Pro, avec plus de 800 000 installations actives, a été compromise séparément, cette fois par son infrastructure de mise à jour.

En mai, quatre bibliothèques de l'écosystème Laravel ont été détournées. L'attaquant n'a pas touché au code des dépôts officiels. Il a réécrit les références de centaines de versions déjà publiées pour les faire pointer vers du code malveillant, qui volait ensuite les clés et les mots de passe présents sur le serveur. Le point à retenir pour une équipe technique est celui-ci : figer une version précise ne protégeait pas, parce que c'est la référence vers cette version qui avait été modifiée.

Au début de ce mois-ci, c'est la chaîne de compilation et de distribution d'un autre fournisseur d'extensions WordPress, ShapedPlugin, qui a été compromise. Les versions payantes distribuées par le canal du fournisseur contenaient une porte dérobée, alors que les versions gratuites publiées sur WordPress.org n'étaient pas touchées. La vulnérabilité a reçu un score de gravité de 9,8 sur 10.

Trois mécanismes complètement différents : un changement de propriétaire, une infrastructure de mise à jour, une chaîne de compilation. Et une constante.

Dans les trois cas, l'attaque n'a exploité aucune faille du code que l'organisation avait choisi au départ. Elle a exploité le canal par lequel ce code est livré et mis à jour. Ce qui a été compromis, c'est le lien de confiance entre vous et la personne qui vous livre ce code.

Un audit du code que vous avez installé aujourd'hui ne vous dit rien sur ce qui vous sera livré le mois prochain.

‍

La bonne question n'est pas « est-ce à jour », c'est « qui maintient ça »

‍

Les chiffres de l'écosystème WordPress éclairent bien l'enjeu.

Toujours selon le rapport de Patchstack, 11 334 nouvelles vulnérabilités ont été recensées dans l'écosystème WordPress en 2025, une hausse de 42 % en un an. Et 91 % d'entre elles se trouvaient dans des extensions, pas dans le cœur du logiciel. À titre de comparaison, l'équipe du cœur de WordPress a rapporté deux vulnérabilités pour l'ensemble de l'année 2025.

Une précision d'usage : Patchstack vend des services de protection contre les vulnérabilités WordPress, ce qui ne rend pas ses données fausses, mais explique qu'elles proviennent de son propre parc de sites surveillés. C'est une source à lire pour les ordres de grandeur plutôt que pour la décimale.

L'autre chiffre, celui qui compte le plus : 46 % des vulnérabilités divulguées n'étaient pas corrigées au moment où elles sont devenues publiques.

Ce n'est pas une question de rythme de mise à jour. C'est une question de maintenance. Quand une extension gratuite ne génère aucun revenu, corriger une faille de sécurité entre en concurrence directe avec du travail facturable. Beaucoup d'extensions ne sont pas abandonnées officiellement, elles sont simplement délaissées.

Et une extension délaissée peut rester parfaitement fonctionnelle pendant des années sur votre site. Elle affiche votre carrousel, votre formulaire, votre minuterie. Rien n'indique visuellement que plus personne ne surveille son code.

Être à jour et être maintenu sont deux choses différentes. Une extension dont la dernière version date de trois ans est « à jour » au sens où aucune mise à jour n'est disponible.

‍

Ce que nous regardons avant d'intégrer une dépendance

‍

C'est ici que le travail d'agence se joue, et c'est rarement visible dans un devis.

Quand nous choisissons une extension ou une bibliothèque pour un projet client, nous évaluons plusieurs choses en plus de la fonctionnalité recherchée.

La fréquence et la régularité des publications. Pas seulement la date de la dernière version, mais le rythme sur les deux ou trois dernières années.

Qui est derrière. Un développeur unique, une équipe, une entreprise. Aucun de ces profils n'est disqualifiant, mais ils ne présentent pas le même risque de continuité.

L'existence d'un canal de signalement de vulnérabilités. Un fournisseur qu'un chercheur en sécurité ne peut pas joindre est un fournisseur qui ne corrigera pas rapidement.

La possibilité de s'en passer. C'est le critère le plus sous-estimé. Chaque extension ajoutée est une dépendance permanente. Une fonctionnalité mineure obtenue en installant une extension supplémentaire est parfois plus coûteuse à long terme que la même fonctionnalité développée directement.

Le nombre total de dépendances. Une installation WordPress typique fonctionne avec vingt à trente extensions. Réduire ce nombre est la mesure de sécurité la moins spectaculaire qui existe, et elle réduit directement la surface à surveiller : moins de code tiers installé, c'est aussi moins de fournisseurs susceptibles de changer de mains sans vous avertir.

Ce dernier point mérite d'être dit franchement : il arrive que la réponse à un besoin client soit de retirer trois extensions plutôt que d'en ajouter une.

‍

Ce que vous pouvez demander dès maintenant

‍

Si vous faites gérer votre site par une équipe interne ou par un prestataire, il y a quelques questions qui donnent une bonne mesure de l'état réel des choses.

Combien d'extensions sont actuellement actives sur le site, et lesquelles ne servent plus?

Pour chacune, quelle est la date de la dernière mise à jour publiée par son auteur?

Y a-t-il eu des changements de propriétaire ou d'auteur parmi les extensions installées?

Existe-t-il une liste des dépendances du projet, quelque part, ailleurs que dans la tête de la personne qui l'a développé?

Et pour les sites qui contiennent des renseignements personnels : si un incident survenait par le biais d'une extension compromise, dans quel délai le sauriez-vous?

Cette dernière question n'est pas théorique. Dans le cas d'Essential Plugin, le pourriel était visible uniquement par Googlebot. Sans surveillance active, un site pouvait rester compromis pendant des semaines sans qu'aucun signe n'apparaisse à l'écran.

‍

Ce que nous en retenons

‍

L'écosystème des logiciels libres fonctionne parce qu'il repose sur la confiance. Des milliers de personnes maintiennent du code que des millions de sites utilisent gratuitement. Ce modèle a construit le web tel qu'on le connaît, et il n'y a pas de retour en arrière souhaitable.

Mais il faut être lucide sur un point : cette confiance est transférable. Elle se vend, elle s'hérite, elle change de mains sans que personne ne soit averti. Et rien, dans l'écosystème WordPress actuel, ne prévoit de vérification lors du transfert de propriété d'une extension, ni de signature du code livré lors d'une mise à jour.

Pour un site d'entreprise ou d'organisme, la conséquence pratique est simple. Appliquer les mises à jour reste indispensable. Mais l'entretien réel d'un site inclut aussi de savoir ce qui est installé, qui le maintient et à quel moment cette réponse a changé.

C'est du travail de surveillance continue, pas une intervention ponctuelle. Et cela pose une question de rythme d'intervention à laquelle nous reviendrons bientôt.

Vous ne savez pas exactement quelles extensions sont actives sur votre site ni qui les maintient? Écrivez-nous. Nous pouvons faire cet inventaire avec vous.

‍

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

‍

Sources

Article rédigé le 30 juillet 2026. Les versions, correctifs et scores de gravité mentionnés reflètent l'information disponible à cette date.

Essential Plugin (WordPress, avril 2026)

• Patchstack, analyse technique de la compromission (mécanisme de la porte dérobée, activation par charge sérialisée, entrées de vulnérabilité)
• Anchor Hosting, recherche originale d'Austin Ginder (chronologie détaillée, recul de revenus de 35 à 45 %, mise en vente sur Flippa, liste des extensions touchées)
• The Next Web, synthèse de l'affaire (montant à six chiffres, fermeture des 31 extensions le 7 avril 2026, compromission distincte de Smart Slider 3 Pro la même semaine, absence de vérification lors des transferts de propriété)
• mySites.guru, chronologie technique (accès de publication en mai 2025, commit du 8 août 2025, version 2.6.7, 191 lignes ajoutées, changelog de compatibilité, pourriel servi uniquement à Googlebot)

laravel-lang (Composer, mai 2026)

• Aikido Security, détection initiale (réécriture des étiquettes de version, exécution automatique par l'autoloader de Composer)
• Snyk, avis de sécurité et guide de vérification (fenêtre des 22 et 23 mai 2026, vérification des fichiers de dépendances, inefficacité des numéros de version seuls)
• The Hacker News, couverture de l'incident (plus de 700 versions identifiées, compromission du processus de publication de l'organisation)
• BleepingComputer, comptes des versions touchées (233 versions selon Aikido, environ 700 selon Socket, extensions non officielles de Laravel)

ShapedPlugin (WordPress, juillet 2026)

• The Hacker News, analyse de Wordfence (compromission de la chaîne de compilation et de distribution, versions payantes touchées, versions gratuites non touchées, score de gravité de 9,8)

Volume de vulnérabilités dans l'écosystème WordPress

• Patchstack, State of WordPress Security in 2026 (11 334 vulnérabilités en 2025, hausse de 42 %, 91 % dans les extensions, 46 % non corrigées à la divulgation, délai médian pondéré de cinq heures avant exploitation de masse, deux vulnérabilités dans le cœur de WordPress en 2025)
• Patchstack, State of WordPress Security in 2025 (contexte historique, extensions retirées du répertoire pour vulnérabilités non corrigées, difficulté à joindre les développeurs)

‍