Extensions WordPress vulnérables : auditer, mettre à jour, remplacer

Le point faible d’un site WordPress est rarement WordPress lui-même. Pour maîtriser les vulnérabilités des extensions WordPress, quatre habitudes suffisent : savoir exactement ce qui est installé, mettre à jour rapidement, supprimer ce dont vous n’avez pas besoin et remplacer ce que plus personne ne maintient.

Ce guide explique comment prendre chacune de ces habitudes, comment reconnaître une extension abandonnée et que faire dans le cas délicat où une vulnérabilité est publique alors qu’aucun correctif n’existe encore. C’est l’un des points de notre checklist de sécurité WordPress, et pour la plupart des sites, le plus important.

Les vulnérabilités des extensions WordPress en chiffres

Les chiffres annuels détaillés proviennent du rapport de Patchstack State of WordPress Security in 2026, qui porte sur l’année 2025. Patchstack est un éditeur de sécurité qui vend des protections contre ces risques : voyez-y une source bien informée, pas une statistique officielle. Ses principaux constats :

• 11 334 nouvelles vulnérabilités dans l’écosystème WordPress en 2025, soit 42 % de plus qu’en 2024.
• 91 % concernaient des extensions et 9 % des thèmes. Le cœur de WordPress n’en comptait que six, toutes de faible priorité.
• 17 % (1 966) étaient de gravité élevée et susceptibles d’être exploitées dans des attaques automatisées de masse.
• 46 % n’avaient aucun correctif disponible auprès du développeur au moment de leur divulgation publique.
• Le contrôle d’accès défaillant (broken access control) était la catégorie la plus exploitée.

Autrement dit, votre liste d’extensions, c’est votre surface d’attaque. Chaque extension est du code écrit par une autre équipe, à laquelle vous confiez votre site et les données qu’il contient.

Pourquoi la vitesse de mise à jour compte

Les attaquants ne choisissent pas leurs cibles à la main. Ils scannent Internet à la recherche d’une version vulnérable d’une extension et exploitent automatiquement chaque site trouvé. D’après le même rapport, le délai médian pondéré avant exploitation de masse était de cinq heures pour les vulnérabilités massivement exploitées, et environ la moitié des vulnérabilités à fort impact ont été exploitées dans les 24 heures.

Une fenêtre de maintenance mensuelle est bien trop lente pour ces cas. Les mises à jour de sécurité doivent suivre une voie plus rapide que les nouveautés fonctionnelles. Appliquer les correctifs sans tarder fait d’ailleurs partie des mesures de sécurité « appropriées » qu’exige l’article 32 du RGPD, et la directive NIS 2 range le traitement des vulnérabilités parmi ses mesures minimales (article 21, paragraphe 2, point e) pour les organisations concernées.

Étape 1 : tenir un inventaire des extensions

On ne peut ni mettre à jour ni évaluer ce qu’on ne connaît pas. Un inventaire simple par site, même sous forme de tableur, devrait indiquer :

• le nom de l’extension, son slug et la version installée
• sa source : WordPress.org, un éditeur commercial ou du code sur mesure
• la raison de sa présence et la personne qui l’a demandée
• pour les extensions premium, l’état de la licence et sa date de renouvellement
• l’activation ou non des mises à jour automatiques

Avec WP-CLI, vous exportez l’essentiel en une seule commande :

wp plugin list --fields=name,status,version,update_version,auto_update

Les versions récentes de WP-CLI affichent aussi ce que WordPress.org sait de chaque extension, notamment si elle a été fermée :

wp plugin list --fields=name,version,wporg_status,wporg_last_updated

Les extensions qui ne sont pas hébergées sur WordPress.org affichent généralement des valeurs vides ici : vérifiez-les auprès de leur éditeur. Faites de même pour les thèmes avec wp theme list.

Étape 2 : supprimer les extensions inutilisées

Désactiver une extension empêche WordPress de la charger, mais ses fichiers restent sur le serveur. Certaines vulnérabilités peuvent être déclenchées en appelant directement les fichiers d’une extension, et les extensions inactives ont tendance à sortir des routines de mise à jour. L’écran Santé du site de WordPress (Outils → Santé du site) le rappelle d’ailleurs : les extensions inactives sont des cibles tentantes pour les attaquants.

Lorsqu’une extension n’est plus utile, faites une sauvegarde, puis désactivez-la et supprimez-la depuis l’écran Extensions. En ligne de commande :

wp plugin uninstall old-slider --deactivate

wp plugin uninstall exécute la routine de désinstallation propre à l’extension, qui peut aussi effacer ses réglages et ses données de la base, puis supprime les fichiers. wp plugin delete se contente de supprimer les fichiers. Exportez d’abord tout ce dont vous avez encore besoin.

Les candidats typiques : extensions de test oubliées après un projet, fonctions en double (deux extensions de cache ou de SEO), outils de migration à usage unique, et extensions dont le cœur de WordPress assure désormais la fonction.

Étape 3 : remplacer les extensions abandonnées et « nulled »

Une extension sans mainteneur actif ne recevra aucun correctif lorsque la prochaine vulnérabilité sera découverte.

Les signes d’une extension abandonnée

• Aucune mise à jour récente. Regardez la date de dernière mise à jour sur la page WordPress.org de l’extension. WordPress.org affiche aussi un avis lorsqu’une extension n’a pas été testée avec les 3 dernières versions majeures de WordPress.
• Fermée sur WordPress.org. Un avis rouge indique que l’extension a été fermée et n’est plus disponible au téléchargement. Au bout de 60 jours, le motif est ajouté, et « Security Issue » (problème de sécurité) figure parmi les motifs possibles. Quel que soit le motif, tant qu’une extension est fermée, aucune mise à jour ne vous parvient par WordPress.org.
• Des fils d’assistance sans réponse, surtout ceux qui évoquent des problèmes de sécurité.
• Des extensions premium dont l’éditeur ne donne plus signe de vie : plus aucune entrée dans le journal des modifications, renouvellements de licence qui échouent, support muet.

La documentation de WordPress.org sur les alertes et avertissements explique ces avis. Lorsque vous les voyez, planifiez un remplacement avant qu’une urgence ne vous l’impose.

N’utilisez jamais d’extensions « nulled »

Les extensions dites « nulled » sont des copies piratées d’extensions premium dont on a retiré la vérification de licence. Un tiers inconnu a modifié le code, et personne ne peut dire ce qu’il a changé d’autre. Les portes dérobées cachées sont un problème bien connu de ces copies. Elles ne reçoivent par ailleurs ni mises à jour ni assistance : impossible de les corriger quand la prochaine vulnérabilité apparaît.

Si vous en trouvez une sur un site, remplacez-la par une copie sous licence et considérez le site comme potentiellement compromis.

Étape 4 : mettre à jour vite, en automatique ou via une préproduction

Depuis WordPress 5.5, vous pouvez activer les mises à jour automatiques extension par extension, dans la colonne « Mises à jour automatiques » de l’écran Extensions. Par défaut, WordPress les lance deux fois par jour et vous envoie les résultats par e-mail (documentation WordPress.org). Avec WP-CLI : wp plugin auto-updates enable --all.

Vu la vitesse à laquelle les attaques suivent, les mises à jour automatiques sont le bon réglage par défaut pour la plupart des extensions. Une préproduction garde tout son sens là où une mise à jour ratée coûte vraiment de l’argent :

Quel que soit votre choix, conservez des sauvegardes que vous avez réellement restaurées au moins une fois, et assurez-vous que quelqu’un lit les e-mails de mise à jour.

Étape 5 : suivre les vulnérabilités et agir

Où trouver les vulnérabilités des extensions

• Le journal des modifications (changelog) sur la page WordPress.org de l’extension ou sur le site de l’éditeur. Cherchez des mentions comme « security fix », mais attendez-vous à ce que certains éditeurs décrivent leurs correctifs en termes vagues.
• Les bases de données publiques de vulnérabilités, comme celles de WPScan et de Patchstack, que vous pouvez interroger par nom d’extension. Toutes deux sont exploitées par des entreprises qui vendent aussi des services de sécurité.
• Les bulletins et newsletters des éditeurs pour les extensions premium.

Vérifier des dizaines d’extensions à la main n’est pas tenable. Security Audit & Compliance, l’extension d’audit de secaudit.eu, signale d’emblée les extensions, thèmes et versions du cœur obsolètes. Si vous activez la vérification des vulnérabilités, elle compare aussi les versions installées à la base de vulnérabilités gratuite de secaudit.eu, générée chaque nuit à partir de la liste officielle des CVE ; la liste de vos extensions ne quitte jamais votre site.

Que faire quand aucun correctif n’existe encore

Près de la moitié des vulnérabilités (46 %) n’avaient aucun correctif au moment de leur divulgation. Si l’une d’elles touche une extension que vous utilisez :

1. Évaluez votre exposition. Les visiteurs anonymes peuvent-ils atteindre la fonction vulnérable, ou seulement les administrateurs connectés ?
2. Désactivez l’extension si vous pouvez vous en passer quelque temps, et supprimez-la si aucun correctif n’arrive.
3. Remplacez-la par une alternative maintenue si l’éditeur reste silencieux.
4. Recourez à un correctif virtuel (virtual patching) si l’extension est indispensable : certains pare-feu applicatifs web (WAF) et services de sécurité fournissent des règles qui bloquent les requêtes correspondant à l’exploit connu. Cela fait gagner du temps, mais ne corrige pas le code.
5. Recherchez une éventuelle compromission, surtout si la faille était publique depuis un moment avant que vous ne la remarquiez. Notre liste des signes d’un site WordPress piraté est un bon point de départ.

Si vous vendez des extensions : le Cyber Resilience Act

Pour les éditeurs, le traitement des vulnérabilités devient une obligation légale, et une partie de celle-ci s’applique déjà. Une extension ou un thème payant vendu à des clients de l’UE est un « produit comportant des éléments numériques » au sens du Cyber Resilience Act (CRA, règlement sur la cyberrésilience), et son vendeur en est le fabricant. Depuis le 11 septembre 2026, les fabricants doivent signaler les vulnérabilités activement exploitées de leurs produits via la plateforme unique de déclaration de l’ENISA : une alerte précoce dans les 24 heures, une notification dans les 72 heures et un rapport final au plus tard 14 jours après la mise à disposition d’une mesure corrective.

À partir du 11 décembre 2027 s’appliquent les principales obligations, dont les mises à jour de sécurité pendant la période d’assistance, un processus de traitement des vulnérabilités, une politique de divulgation coordonnée et une nomenclature logicielle (SBOM). Les extensions open source gratuites et non monétisées échappent en général à ce régime des fabricants. Tous les détails figurent dans notre guide du Cyber Resilience Act pour les vendeurs d’extensions.

FAQ

Une extension désactivée est-elle sans danger ?

Non. Ses fichiers restent sur le serveur et peuvent toujours contenir du code exploitable. Supprimez les extensions que vous n’utilisez pas.

Faut-il activer les mises à jour automatiques pour toutes les extensions ?

Pour la plupart, oui, à condition d’avoir des sauvegardes fiables. Testez d’abord en préproduction les extensions critiques pour votre activité, mais gardez ce délai aussi court que possible.

Que faire si une extension dont je dépends a été fermée sur WordPress.org ?

Considérez-la comme non maintenue tant qu’elle n’a pas été rouverte avec une version corrigée, et commencez dès maintenant à chercher une alternative.

Cet article est une information générale et ne constitue pas un conseil juridique.