Sécurité WordPress : panorama des risques et durcissement réel

11 300. C'est le nombre de vulnérabilités divulguées sur l'écosystème WordPress en 2025, selon les rapports croisés de Patchstack et Wordfence. Plus de 200 par semaine. 91% d'entre elles concernaient des extensions, le reste se répartissant entre les thèmes et le cœur du logiciel. La médiane du temps écoulé entre la divulgation publique d'une vulnérabilité et sa première exploitation enregistrée est désormais de cinq heures. Cinq heures pour patcher, isoler ou accepter le risque. Ces trois chiffres dessinent à eux seuls la photographie réelle de la sécurité WordPress en 2026 : un écosystème massivement dominant, structurellement exposé, et où le rythme des attaques dépasse celui des réponses individuelles.

L'objectif de cet article est de poser les choses sans dramatiser. Pourquoi WordPress concentre autant d'attaques, ce que les attaquants exploitent vraiment, pourquoi la marketplace officielle laisse passer autant de failles, et surtout quelles règles de base et quelles mesures de durcissement réduisent réellement le risque ? Nous ne traiterons pas ici les attaques d'avril 2026 contre Essential Plugin et Smart Slider 3 Pro, nous prenons ici le recul que l'actualité de courte durée empêche de prendre : ce que ces incidents nous disent du système, et ce qu'il faut tenir dans la durée pour qu'un site WordPress reste défendable.

La carte du risque WordPress en chiffres

WordPress fait tourner environ 43 % du web mondial selon les statistiques publiques de W3Techs, soit largement plus que tous les autres CMS réunis. Cette domination est aussi la première raison de l'attractivité de la plate-forme pour les attaquants. Une vulnérabilité exploitable sur un plugin populaire ouvre potentiellement la porte à des dizaines, parfois des centaines de milliers de sites en quelques heures. Le calcul d'effort par site infecté est imbattable, et l'écosystème offre par construction une longue traîne de cibles mal entretenues.

La distribution des vulnérabilités est très asymétrique. Le cœur de WordPress, audité par une équipe sécurité dédiée et bénéficiant de mises à jour automatiques poussées par WordPress.org, ne représente qu'une fraction marginale des failles divulguées. Les extensions concentrent la quasi-totalité du risque, et au sein des extensions, les plus exposées sont celles qui combinent une grande surface fonctionnelle (constructeurs de page, e-commerce, formulaires) et un historique de développement long sans audit externe. Les bulletins hebdomadaires publiés par Patchstack et Wordfence font régulièrement remonter les mêmes catégories d'extensions parmi les plus affectées par les divulgations.

Le délai d'exploitation s'est effondré ces dernières années. Là où une vulnérabilité critique laissait quelques jours ou quelques semaines pour patcher en 2018, les rapports d'observation publiés par Wordfence et Patchstack documentent une médiane désormais autour de cinq heures pour les failles classées critiques. Cette compression du temps de réaction signifie que la stratégie classique « on met à jour le mois prochain » ne tient plus pour les vulnérabilités de cette catégorie. Pour un site qui compte, la fenêtre entre la divulgation et le patch doit se mesurer en heures, pas en semaines.

Ce que les attaquants exploitent vraiment

Les attaques contre WordPress se distribuent sur quelques grandes catégories qui n'ont pas changé fondamentalement depuis dix ans, mais dont le poids relatif évolue.

Force brute et bourrage d'identifiants

En volume brut, les attaques par force brute sur les pages de connexion restent la première ligne de bruit que reçoit n'importe quel site WordPress. Les rapports d'opérateurs comme Sucuri ou Wordfence chiffrent les tentatives à plusieurs milliards par mois à l'échelle de l'écosystème. La cible privilégiée est le fichier wp-login.php, suivi de loin par le point d'entrée XML-RPC qui permet, via la méthode system.multicall, de tester des centaines de mots de passe en une seule requête HTTP. Les attaquants ne devinent plus au hasard, ils utilisent des bases de données de combinaisons identifiant/mot de passe issues d'anciennes fuites pour faire du bourrage d'identifiants, technique nettement plus efficace contre les utilisateurs qui réutilisent leurs mots de passe.

Cette catégorie d'attaque est paradoxalement la plus simple à neutraliser. Une politique de mots de passe corrects, l'authentification à deux facteurs sur les comptes administrateurs, la limitation des tentatives de connexion et la désactivation de XML-RPC quand il n'est pas utilisé bloquent l'écrasante majorité de ces tentatives. Le vrai sujet n'est pas qu'elles existent, c'est que beaucoup de sites n'ont toujours rien de tout cela en place et restent vulnérables à des attaques qui datent d'il y a quinze ans.

Vulnérabilités d'extension non patchées

C'est, en impact, le premier vecteur de compromission réussie. Une vulnérabilité critique divulguée sur un plugin populaire déclenche en quelques heures une vague de scans automatisés sur l'ensemble du web pour identifier les sites qui ne l'ont pas encore patchée. Les rapports d'incident publiés par Patchstack et Wordfence convergent sur un constat : une part importante des sites compromis tournaient avec une version d'extension affectée par une vulnérabilité divulguée depuis plusieurs semaines, parfois plusieurs mois. Le problème n'est presque jamais la sophistication de l'attaque. C'est le délai de patching qui transforme une vulnérabilité publique en compromission effective.

Les types de failles les plus fréquemment exploités dans cette catégorie sont les contournements d'authentification, les injections SQL, les téléversements de fichiers arbitraires et les exécutions de code à distance. Les noms changent, le pattern reste : un plugin reçoit une fonctionnalité, la fonctionnalité comporte une faille, la faille est divulguée, l'auteur publie un correctif, et la fenêtre entre ce correctif et l'application sur les sites en production est l'endroit où les attaquants travaillent.

Attaques sur la chaîne d'approvisionnement

Les compromissions par la chaîne d'approvisionnement, c'est-à-dire l'introduction de code malveillant directement dans une extension légitime via son canal de mise à jour officiel, étaient encore rares il y a cinq ans. Elles sont devenues un vecteur mature en 2025 et 2026. Nous traitons en détail dans un article séparé l'enchaînement Essential Plugin et Smart Slider 3 Pro d'avril 2026, qui a mis en danger plus de 820 000 installations actives en moins de 48 heures et illustre les deux variantes principales de cette catégorie : le rachat d'extensions existantes pour y injecter un backdoor à terme, et la compromission directe de l'infrastructure de mise à jour d'un éditeur.

Ce qui rend cette catégorie redoutable, c'est qu'elle contourne toutes les heuristiques classiques de choix d'extension. Le plugin est officiel, populaire, à jour, signé par un éditeur identifiable. Et il distribue pourtant une charge utile malveillante. Les défenses individuelles classiques (mise à jour rapide, scanner, choix d'éditeur réputé) sont peu opérantes face à ce vecteur, ce qui déplace la responsabilité vers les mécanismes structurels de la marketplace.

Injections, XSS et classiques persistants

Les attaques par injection SQL, par cross-site scripting stocké, par cross-site request forgery ou par inclusion de fichiers locaux n'ont rien de nouveau, mais elles continuent de représenter une part significative des vulnérabilités divulguées. Les XSS stockés dans les champs accessibles aux contributeurs ou aux abonnés sont particulièrement insidieux : ils peuvent permettre à un compte de niveau faible d'élever ses privilèges en piégeant un administrateur qui consulte la page concernée. Les rapports annuels de Patchstack et Wordfence montrent que les XSS sous toutes leurs formes restent, année après année, l'une des familles les plus représentées dans les vulnérabilités divulguées sur les extensions WordPress, aux côtés des contournements d'authentification et des injections SQL.

Ces classiques restent efficaces parce qu'ils s'appuient sur des erreurs de programmation banales (oubli d'échappement, validation incorrecte, absence de vérification de capacité) que la diversité du parc d'extensions garantit. Un site moyen exécute du code venant d'une vingtaine d'auteurs différents, chacun avec son niveau de rigueur, et le maillon faible suffit pour ouvrir une brèche.

Pourquoi la marketplace WordPress.org laisse passer autant de failles ?

C'est la question que pose souvent un client qui découvre les chiffres : si les extensions viennent de la marketplace officielle WordPress.org, pourquoi y a-t-il autant de failles ? La réponse tient à la mécanique de cette marketplace, qui n'a pas été conçue pour offrir des garanties de sécurité au sens où nous les attendons d'un App Store ou d'une plate-forme commerciale moderne.

Une revue initiale par une équipe bénévole

Toute extension soumise à WordPress.org passe par une revue d'admission menée par le Plugin Review Team, équipe composée de bénévoles. Cette revue vérifie principalement la conformité aux directives de la plate-forme : licence GPL compatible, absence de code obfusqué non justifié, respect des conventions de nommage, documentation minimale. Elle ne constitue pas un audit de sécurité au sens technique. L'équipe ne dispose ni des ressources ni du mandat pour analyser en profondeur le comportement de chaque extension soumise. Les soumissions se chiffrent en milliers par an, l'équipe traite ce flux dans la durée, et la priorité est la conformité formelle plus que l'analyse de menaces.

Cette limite n'est pas une critique de l'équipe, qui fait un travail considérable bénévolement. Elle reflète simplement le fait que la marketplace n'a jamais été pensée comme un dispositif de garantie de sécurité, mais comme un point de distribution communautaire. Ce qui était cohérent avec l'esprit du logiciel libre dans les années 2000 montre ses limites dans un écosystème devenu critique pour 43 % du web mondial.

Aucune revue lors des mises à jour

Une fois une extension admise, ses mises à jour ne sont pas revues. L'auteur peut pousser une nouvelle version dans le dépôt SVN officiel et celle-ci sera distribuée immédiatement à toutes les installations existantes via les canaux automatiques de WordPress. C'est précisément la faille structurelle qu'a exploitée l'attaque Essential Plugin d'avril 2026 : le code malveillant a été introduit dans une mise à jour postérieure à la revue initiale, sans qu'aucun mécanisme ne déclenche une nouvelle analyse.

Comparativement, l'écosystème npm a déployé depuis 2022 plusieurs mécanismes de contrôle sur les paquets publiés, dont les attestations de provenance qui permettent de vérifier l'origine d'une version, et des analyses automatisées en arrière-plan sur les nouveaux paquets. PyPI a renforcé en 2023 et 2024 ses dispositifs de détection de paquets malveillants. WordPress.org n'a, à ce jour, rien d'équivalent en termes de contrôle systématique des mises à jour. Une nouvelle version d'extension est publiée, elle se diffuse immédiatement, et les éventuels problèmes ne sont identifiés qu'après-coup, par les rapports de chercheurs en sécurité ou par l'observation de comportements anormaux côté sites compromis.

Le transfert de propriété sans alerte

Quand l'auteur originel d'une extension la vend à un tiers, WordPress.org procède au transfert de la propriété du dépôt sans déclencher de revue spécifique, et sans alerter les sites qui ont l'extension installée. Le nouveau propriétaire hérite des accès, peut publier des mises à jour immédiatement, et rien n'est notifié aux 30 000 ou 100 000 sites qui font confiance à cette extension depuis des années. Cette absence de revue est précisément ce que les attaquants ont exploité dans le cas Essential Plugin, où un portefeuille de 31 extensions a été acheté sur Flippa et utilisé comme cheval de Troie huit mois plus tard.

Tant qu'aucun mécanisme de notification ou de revue déclenchée par un changement de propriétaire n'existe, le risque structurel que représente un transfert silencieux reste l'un des plus difficiles à mitiger côté propriétaire de site, parce qu'il échappe aux signaux extérieurs (note, fréquence des mises à jour, nombre d'installations) sur lesquels reposent les heuristiques de choix. Patchstack publie occasionnellement des analyses sur les portefeuilles d'extensions ayant changé de mains et qui méritent une vigilance particulière, ce qui reste à ce jour le seul filet pratique sur ce sujet.

Les extensions abandonnées qui restent en ligne

WordPress.org ferme certaines extensions quand elles posent un problème de sécurité actif, mais conserve dans le dépôt celles qui sont simplement abandonnées par leur auteur. Une extension peut rester téléchargeable et présente sur des dizaines de milliers de sites alors qu'elle n'a pas reçu de mise à jour depuis cinq ans, que son auteur ne répond plus, et qu'aucune vulnérabilité divulguée depuis n'a été corrigée. La marketplace affiche un avertissement « non testée avec votre version de WordPress » au-delà d'un certain délai, mais cet avertissement passe largement inaperçu.

Les analyses publiées par les acteurs de la sécurité WordPress (Patchstack, Wordfence, WPScan) recensent régulièrement plusieurs milliers d'extensions abandonnées encore présentes sur des sites en production, c'est-à-dire sans mise à jour depuis plus de deux ans et sans réponse de leur auteur. Pour un propriétaire de site, c'est l'une des plus grandes sources de risque silencieux. Une extension installée pour un usage ponctuel il y a quatre ans, oubliée depuis, qui a accumulé deux ou trois vulnérabilités non corrigées, devient une porte d'entrée stable que l'audit trimestriel évoqué plus loin permet de fermer.

Le retard structurel face à npm et PyPI

Les écosystèmes voisins ont rattrapé en quelques années des retards similaires à celui de WordPress, sous la pression d'incidents de chaîne d'approvisionnement qui ont marqué les esprits. Npm a introduit l'authentification à deux facteurs obligatoire pour les mainteneurs de paquets populaires en 2022, après plusieurs incidents de comptes compromis. PyPI a fait de même en 2023, avec en complément une politique de signature de paquets qui se généralise. Composer, l'équivalent de npm pour PHP, a renforcé sa vérification d'intégrité dès 2024.

WordPress.org accuse plusieurs années de retard sur chacun de ces points. L'authentification à deux facteurs pour les auteurs d'extensions est devenue obligatoire en octobre 2024, ce qui était une avancée mais relativement tardive. La signature de code n'existe toujours pas. La revue automatisée des mises à jour n'est pas en place. Le rachat de WPackagist par WP Engine en mars 2026, et le lancement quasi simultané de WP Packages comme alternative communautaire, ont remis ces questions sur le devant de la scène, mais aucun changement structurel majeur n'est attendu avant 2027 selon les annonces actuelles de la Fondation.

Les règles de base qui bloquent l'essentiel

Avant tout durcissement technique avancé, les règles de base sont celles qui bloquent l'écrasante majorité des compromissions. Les rapports d'incidents convergent sur un constat simple : la plupart des sites compromis l'ont été par des vecteurs que les fondamentaux de la sécurité auraient évités. Mises à jour rapides, choix de plugins défendables, hygiène des comptes administrateurs. Trois disciplines simples, peu coûteuses, et systématiquement sous-appliquées.

Les mises à jour, le levier le plus sous-estimé

Si la médiane d'exploitation d'une vulnérabilité critique est de cinq heures, la fenêtre dans laquelle un site doit appliquer un patch est en théorie inférieure à cette durée. En pratique, c'est rarement faisable manuellement. La conséquence est qu'une mise à jour automatique ou semi-automatique des correctifs de sécurité est plus protectrice qu'une revue manuelle hebdomadaire, malgré le risque résiduel de chaîne d'approvisionnement qu'elle introduit.

Le compromis raisonnable que nous appliquons chez MtoM Création pour les sites en maintenance consiste à activer les mises à jour automatiques sur le cœur de WordPress (qui est strictement audité et n'a jamais été le vecteur d'une compromission par mise à jour officielle à grande échelle) et à arbitrer plugin par plugin. Pour les extensions critiques, sécurité et e-commerce, mises à jour automatiques activées avec sauvegarde préalable. Pour les extensions secondaires, revue manuelle hebdomadaire avec test sur un environnement de préproduction avant déploiement. Cette différenciation par criticité permet de tenir le délai sur ce qui compte sans s'exposer à toutes les régressions possibles.

Une stratégie de mise à jour suppose une chaîne complète. Sauvegarde automatique avant chaque mise à jour, test de non-régression sur les fonctions critiques (paiement, formulaire de contact, connexion), procédure de rollback documentée si une mise à jour casse une fonctionnalité. Sans cette chaîne, les propriétaires de site désactivent les mises à jour automatiques après un incident et reviennent à un rythme manuel qui ne tient pas la cadence des divulgations. Le bon réflexe est de construire la chaîne, pas de désactiver l'automatisme.

Le choix des plugins, du point de vue sécurité

La sélection d'une extension au moment de son installation est le premier filtre de sécurité, et probablement le plus efficace. Nous traitons l'hygiène opérationnelle des plugins (audit trimestriel, désinstallation des extensions inutiles, tests du mainteneur disparu) dans notre article dédié aux attaques d'avril 2026. Nous focalisons ici sur les critères de sécurité au moment du choix initial.

Le premier critère est l'identification de l'équipe qui développe l'extension. Une équipe dont les membres sont publics, avec un site d'entreprise lisible, un blog technique actif et une politique de divulgation responsable documentée, présente une surface de vérification beaucoup plus large qu'un pseudonyme ou une entité anonyme. Le deuxième est la transparence du code : une extension dont le code source est consultable sur un dépôt public (GitHub, GitLab) en plus de WordPress.org permet à des tiers de l'auditer, ce qui est un facteur de pression positive sur la qualité. Le troisième est la fréquence et la régularité des mises à jour : une extension qui n'a pas été mise à jour depuis plus de six mois ou qui n'a pas répondu aux dernières vulnérabilités divulguées sur sa famille technique mérite un soupçon. Le quatrième, plus avancé, est la présence de l'extension dans les bases de vulnérabilités publiques (Patchstack, Wordfence, WPScan) : voir qu'une extension a déjà été affectée par des vulnérabilités est en soi neutre, c'est le délai de patching et la qualité de la communication post-incident qui font la différence.

Ces critères ne disqualifient pas mécaniquement les jeunes extensions ou les éditeurs solo, qui peuvent être excellents. Ils imposent simplement, pour ces cas, un niveau d'audit préalable plus élevé : lecture rapide du code principal, test sur un environnement isolé, vérification de ce que l'extension envoie en réseau au démarrage. Un proxy comme Burp Suite ou OWASP ZAP, ou un capture de trafic avec Wireshark sur l'interface réseau du serveur de test, permettent à un développeur de faire ce contrôle en moins de trente minutes pour une extension simple.

L'hygiène des comptes administrateurs

Le compte administrateur d'un site WordPress est la cible privilégiée des attaques par force brute et par phishing. Trois règles de base réduisent drastiquement le risque associé.

Réduire le nombre de comptes administrateurs au strict minimum est la première. Beaucoup de sites traînent trois, quatre, parfois huit comptes admin hérités d'anciens prestataires, d'agences précédentes, de freelances qui sont passés. Chacun est une porte d'entrée, et le compte qui n'est plus surveillé est celui qui sera compromis. La règle simple est d'avoir un compte administrateur actif par personne qui en a vraiment besoin, et de basculer tous les autres en rôle inférieur (éditeur, contributeur) ou de les supprimer.

Le principe du moindre privilège est la deuxième règle. WordPress propose nativement plusieurs rôles (administrateur, éditeur, auteur, contributeur, abonné) avec des capacités différenciées. Un rédacteur n'a pas besoin du rôle administrateur pour publier des articles, le rôle éditeur ou auteur suffit. Cette discipline s'applique aussi aux comptes techniques utilisés par des intégrations tierces : un plugin de connexion à un service externe qui demande un compte administrateur quand un compte éditeur suffirait est un signal qu'il faut interroger.

L'authentification à deux facteurs sur les comptes administrateurs est la troisième. Elle est aujourd'hui supportée nativement par la plupart des plugins de sécurité (Wordfence, iThemes Security, Two-Factor de l'équipe WordPress.org), avec des méthodes variées : application TOTP, clé physique de type YubiKey, courriel ou SMS en repli. La méthode TOTP avec une application comme Aegis ou Authy est le bon compromis entre sécurité et accessibilité. Le SMS reste meilleur que rien mais expose au SIM swapping, qui n'est pas anecdotique. Une fois activée, l'authentification à deux facteurs neutralise pratiquement la totalité des attaques par force brute et par bourrage d'identifiants, qui sont rappelons-le le premier vecteur en volume.

Le Cyber Resilience Act change la donne en Europe

Le Cyber Resilience Act, règlement européen 2024/2847 adopté en octobre 2024, est entré en vigueur en décembre 2024. Il impose un cadre de cybersécurité contraignant à tous les fabricants de produits comportant des éléments numériques mis sur le marché européen. Sa portée pour l'écosystème WordPress dépend du modèle économique : les extensions et thèmes commerciaux sont clairement assujettis, tandis que les logiciels libres distribués sans activité commerciale bénéficient d'exemptions encadrées par le règlement, ce qui place beaucoup d'extensions gratuites de WordPress.org dans une zone qui reste à clarifier au cas par cas. Les obligations se déploient en deux temps : les obligations de gestion et de signalement des vulnérabilités s'appliquent depuis septembre 2026, et l'ensemble des exigences de conformité (évaluation, marquage CE, documentation technique) s'appliquera à partir de décembre 2027.

Pour un auteur d'extension qui distribue dans l'Union européenne, cela signifie plusieurs obligations concrètes. La mise en place d'un processus documenté de gestion des vulnérabilités, avec un point de contact public pour les signalements responsables. La notification de toute vulnérabilité activement exploitée à l'ENISA dans un délai de 24 heures. Le maintien de mises à jour de sécurité pendant toute la durée d'utilisation prévisible du produit, avec un minimum de cinq ans dans la plupart des cas. La fourniture d'une documentation technique permettant aux autorités de vérifier la conformité. Les sanctions pour non-conformité peuvent aller jusqu'à 15 millions d'euros ou 2,5 % du chiffre d'affaires mondial.

Pour un propriétaire de site WordPress en Europe, le CRA change la donne indirectement. Les éditeurs commerciaux d'extensions vont devoir investir dans des processus de sécurité qu'ils n'avaient pas jusqu'ici, ce qui devrait améliorer la qualité moyenne de l'écosystème commercial. Côté propriétaire, l'arbitrage à venir sera de privilégier les extensions dont les éditeurs publient une déclaration de conformité CRA et un point de contact sécurité dédié, et de regarder avec plus de prudence celles qui n'ont visiblement pas l'intention de se mettre en conformité.

Au Canada et au Québec, il n'existe pas d'équivalent direct au CRA en 2026. La Loi 25 (loi sur la protection des renseignements personnels) couvre les conséquences en cas de violation de données mais n'impose pas d'obligations préventives sur la chaîne d'approvisionnement logicielle. La Loi C-26 fédérale, en cours de discussion, pourrait introduire un cadre proche pour certains secteurs critiques, mais son périmètre exact et son calendrier restent en débat. Les entreprises canadiennes qui distribuent dans l'Union européenne sont en revanche assujetties au CRA pour ce périmètre, ce qui crée un effet d'extraterritorialité comparable à celui du RGPD. Pour un éditeur d'extension WordPress basé au Québec mais avec des clients européens, la conformité CRA devient un pré-requis commercial.

Le durcissement technique au-delà des fondamentaux

Une fois les règles de base en place, le durcissement technique vient ajouter des couches de défense qui réduisent la surface d'attaque résiduelle. Les mesures qui suivent sont celles que nous appliquons chez MtoM Création sur les sites que nous maintenons, dans l'ordre approximatif où elles apportent le plus de valeur par rapport à leur coût d'implémentation.

Hardening de wp-config.php

Le fichier wp-config.php est le centre nerveux d'une installation WordPress. Plusieurs constantes définies à cet endroit modifient le comportement de la plate-forme dans un sens plus sûr. Les configurations suivantes sont celles que nous activons par défaut sur les sites en production.

// Désactiver l'éditeur de fichiers dans l'administration WordPress
define( 'DISALLOW_FILE_EDIT', true );

// Forcer la connexion administrateur en HTTPS
define( 'FORCE_SSL_ADMIN', true );

// Limiter le nombre de révisions stockées en base
define( 'WP_POST_REVISIONS', 5 );

// Mises à jour automatiques pour les versions mineures du cœur uniquement
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Désactiver l'affichage des erreurs PHP en production
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

// Cookies préfixés et clés de salage uniques (à régénérer régulièrement)
// https://api.wordpress.org/secret-key/1.1/salt/

DISALLOW_FILE_EDIT empêche un attaquant qui aurait obtenu un accès administrateur d'éditer du code PHP directement depuis l'interface, ce qui est l'un des premiers réflexes pour installer un backdoor persistant. FORCE_SSL_ADMIN empêche l'envoi des cookies de session en clair sur des connexions non chiffrées. La régénération régulière (annuelle) des huit clés et sels de salage (AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY et leurs équivalents _SALT) invalide automatiquement les sessions actives, ce qui est utile en cas de soupçon de compromission.

Pour les sites où vous gérez vous-même les mises à jour de plugins via SSH ou WP-CLI, ajouter define('DISALLOW_FILE_MODS', true); empêche complètement l'installation et la mise à jour d'extensions depuis l'interface d'administration. C'est une mesure plus radicale, qui durcit considérablement le site mais demande une discipline opérationnelle pour gérer les mises à jour autrement.

Permissions fichiers et désactivations à la racine

Les permissions fichiers sur le serveur sont une couche de défense souvent négligée. Les conventions sécurisées pour une installation WordPress sont 644 pour les fichiers (lecture/écriture pour le propriétaire, lecture seule pour les autres) et 755 pour les répertoires (lecture/écriture/exécution pour le propriétaire, lecture/exécution pour les autres). Le fichier wp-config.php mérite une permission plus restrictive de 600 ou 640, qui empêche les autres comptes du serveur de le lire.

# Permissions par défaut pour une installation WordPress
find /var/www/html -type d -exec chmod 755 {} \;
find /var/www/html -type f -exec chmod 644 {} \;

# Permission renforcée pour wp-config.php
chmod 640 /var/www/html/wp-config.php

À la racine de l'installation, plusieurs fichiers et répertoires peuvent être bloqués en lecture publique sans casser le fonctionnement du site. Le fichier readme.html divulgue la version exacte de WordPress installée. Le répertoire wp-includes/ ne devrait jamais être accessible directement. Le fichier xmlrpc.php, lorsqu'il n'est pas utilisé (ce qui est le cas pour la majorité des sites en 2026), peut être bloqué entièrement.

Désactivation de XML-RPC et endpoints REST sensibles

XML-RPC est un protocole hérité qui était utilisé par les anciennes applications mobiles WordPress et par les éditeurs de bureau. Il est aujourd'hui largement remplacé par l'API REST native de WordPress et reste actif principalement parce qu'il l'a toujours été. Pour les sites qui ne l'utilisent pas, le bloquer entièrement supprime l'un des principaux vecteurs d'attaques par force brute amplifiée.

# .htaccess - Apache - Bloquer xmlrpc.php
<Files xmlrpc.php>
    Require all denied
</Files>

# nginx - Bloquer xmlrpc.php
location = /xmlrpc.php {
    deny all;
    return 403;
}

Côté API REST, certains endpoints divulguent par défaut des informations utiles à un attaquant en phase de reconnaissance, en particulier /wp-json/wp/v2/users qui expose la liste des auteurs publics avec leur slug, qui correspond souvent au nom de connexion lorsqu'il n'a pas été modifié. Restreindre cet endpoint aux utilisateurs authentifiés ou le désactiver pour les visiteurs non connectés réduit la surface d'énumération. Ce comportement peut être configuré via un petit plugin ou via un filtre dans le fichier functions.php du thème.

Headers de sécurité et WAF

Les en-têtes HTTP de sécurité sont une défense passive très peu coûteuse à mettre en place et qui bloquent toute une classe d'attaques côté navigateur. Les principaux en-têtes à activer sur un site WordPress en production sont les suivants.

# .htaccess - Apache - Headers de sécurité
<IfModule mod_headers.c>
    Header set X-Content-Type-Options "nosniff"
    Header set X-Frame-Options "SAMEORIGIN"
    Header set Referrer-Policy "strict-origin-when-cross-origin"
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    Header set Permissions-Policy "geolocation=(), microphone=(), camera=()"
    Header set Cross-Origin-Opener-Policy "same-origin"
</IfModule>

X-Content-Type-Options: nosniff empêche le navigateur de deviner le type d'un fichier servi, ce qui bloque certaines attaques par téléversement de fichier malveillant. X-Frame-Options empêche votre site d'être encadré dans un iframe par un autre domaine, ce qui bloque les attaques de clickjacking. Strict-Transport-Security force le navigateur à toujours utiliser HTTPS pour vos visiteurs, même si l'utilisateur tape http:// dans la barre d'adresse. Permissions-Policy désactive l'accès aux APIs sensibles du navigateur quand elles ne sont pas utilisées par votre site.

Au-delà des headers, un pare-feu applicatif web (WAF) placé devant l'origine apporte une couche de défense active. Cloudflare, Sucuri, et les WAF intégrés aux hébergeurs WordPress infogérés (O2Switch, WPServeur ou Kinsta côté France ; WPCloud.ca, WHC ou Astral Internet côté Québec) offrent des règles préconfigurées pour les attaques WordPress courantes : tentatives de force brute, exploitation de vulnérabilités connues, scans automatisés, scrapers agressifs. Le WAF n'élimine pas le risque, mais il filtre l'écrasante majorité du bruit et donne du temps pour réagir aux attaques ciblées.

Surveillance d'intégrité et logs

La dernière couche est la détection : savoir, idéalement en quelques minutes, qu'une compromission a eu lieu. Trois mécanismes se complètent.

La surveillance d'intégrité fichiers compare l'état actuel des fichiers de WordPress avec un état de référence connu propre. Tout changement non attendu (nouveau fichier PHP, modification du cœur, ajout dans le dossier d'un plugin) déclenche une alerte. Wordfence, Sucuri et iThemes Security proposent ce mécanisme nativement, avec des alertes par courriel ou dans un tableau de bord. Pour un site critique, cette surveillance peut aussi être implémentée côté serveur avec des outils comme AIDE ou Tripwire, qui sont plus robustes et indépendants de WordPress.

La centralisation et la rétention des logs serveur est la deuxième brique. Les logs Apache ou nginx, les logs PHP, les logs WordPress (avec un plugin comme WP Activity Log) doivent être conservés au moins 90 jours et idéalement 180 jours. En cas d'incident, c'est la trace d'audit qui permet de reconstituer le déroulement de l'attaque, d'identifier le point d'entrée et de mesurer l'étendue de la compromission. Sans logs, vous savez que vous avez été piraté mais pas comment, ce qui rend le nettoyage approximatif et la prévention illusoire.

La supervision active, enfin, consiste à monitorer les indicateurs en continu : présence du site, temps de réponse, présence de mots-clés de compromission dans les pages publiques (via des services comme UptimeRobot ou Better Stack configurés avec des règles de contenu), changements dans les résultats Google Search Console qui peuvent signaler du cloaking. Ces signaux ne remplacent pas la surveillance d'intégrité, ils la complètent en captant les compromissions qui se manifestent par leurs effets visibles avant que la surveillance fichiers ne les détecte.

La limite des plugins de sécurité

Wordfence, Sucuri Security, iThemes Security, All-In-One Security (AIOS) : les plugins de sécurité WordPress sont devenus un standard de fait, et chacun apporte une combinaison de fonctionnalités utiles (pare-feu applicatif, scan de fichiers, limitation des tentatives de connexion, surveillance d'intégrité, alertes). Ils ont tous leur place, mais leurs limites méritent d'être nommées explicitement parce qu'elles entretiennent une fausse sécurité courante chez les propriétaires de site.

Premièrement, un plugin de sécurité ne remplace pas le durcissement de la plate-forme. Beaucoup de propriétaires installent Wordfence ou Sucuri en pensant que cela suffit, et négligent les mesures de fond évoquées plus haut (mises à jour, choix de plugins, hygiène des comptes, hardening de wp-config). Le plugin de sécurité est utile en complément, pas en substitution. Deuxièmement, le pare-feu applicatif d'un plugin tourne dans le contexte de WordPress lui-même, ce qui signifie qu'une attaque qui exploite une vulnérabilité dans WordPress avant que les filtres du plugin ne s'exécutent peut le contourner entièrement. Les pare-feu hébergés en amont, comme Cloudflare ou Sucuri Cloud, n'ont pas cette limite parce qu'ils filtrent avant que la requête n'atteigne le serveur. Troisièmement, un plugin de sécurité est lui-même du code exécuté à chaque requête, avec ses propres vulnérabilités potentielles. Des vulnérabilités ont été divulguées ces dernières années dans des extensions populaires de la catégorie sécurité elle-même, ce qui rappelle qu'aucune brique n'est immunisée et que la défense en profondeur ne repose jamais sur un seul produit.

L'utilisation que nous recommandons : un plugin de sécurité pour la surveillance d'intégrité, le scan, la limitation des tentatives de connexion et l'authentification à deux facteurs, complété par un WAF en amont (Cloudflare ou hébergeur infogéré) pour le filtrage en bordure, et complété par les mesures de durcissement plate-forme qui ne dépendent d'aucun plugin. Cette combinaison crée trois couches qui tombent rarement ensemble, ce qui est précisément l'objectif de la défense en profondeur.

La gouvernance WordPress.org en mouvement

La marketplace WordPress.org n'est pas figée. Sous la pression cumulée des incidents de chaîne d'approvisionnement, du Cyber Resilience Act européen et de la concurrence des écosystèmes voisins qui ont rattrapé leur retard, plusieurs évolutions ont été engagées par la Fondation WordPress depuis 2024. L'authentification à deux facteurs est devenue obligatoire pour tous les auteurs d'extensions en octobre 2024, ce qui a déjà empêché plusieurs tentatives de compromission de comptes par phishing. La question de la signature de code et celle de la revue automatisée des mises à jour ont été remises à l'agenda public à plusieurs reprises depuis 2025, sans calendrier ferme communiqué à ce jour.

Ce qui manque encore, pour rattraper le niveau de garantie qu'offrent npm ou PyPI, est connu et documenté. Une signature cryptographique des paquets, qui permettrait de vérifier mathématiquement qu'une extension téléchargée correspond bien à celle publiée par son auteur. Une revue automatisée comportementale des nouvelles versions, qui détecterait les divergences brutales entre une version et la précédente (apparition de code obfusqué, ajout de communications réseau, modification de fonctions sensibles). Une revue déclenchée systématiquement lors des changements de propriétaire d'une extension. Un mécanisme d'alerte aux propriétaires de site quand une extension installée change de mains, même sans incident immédiat.

Le rachat de WPackagist par WP Engine en mars 2026 et l'émergence de WP Packages comme alternative communautaire ont fragmenté le débat. Certains acteurs poussent pour une consolidation derrière la Fondation, d'autres préfèrent multiplier les canaux de distribution avec des règles différentes. Pour un propriétaire de site, cette fragmentation est plutôt une mauvaise nouvelle : suivre la sécurité de plusieurs canaux est plus coûteux que suivre celle d'un seul. La règle pratique que nous appliquons est de rester sur WordPress.org pour les extensions gratuites tant qu'aucune alternative ne démontre un meilleur niveau de garantie, et d'éviter les marketplaces tierces (Envato, ThemeForest pour les thèmes commerciaux, certaines plates-formes spécialisées) qui cumulent souvent les points faibles : revue minimale, absence de mécanisme de signalement, fragmentation des canaux de mise à jour.

WordPress reste une plateforme fiable pour qui s'en occupe

Les chiffres et les vecteurs d'attaque détaillés dans cet article peuvent donner le sentiment que WordPress est une plate-forme exposée au point d'être hasardeuse. Cette lecture serait à la fois injuste et imprudente. Injuste, parce qu'elle occulte tout ce que la plate-forme apporte par ailleurs : un cœur logiciel maintenu par une communauté de plusieurs centaines de contributeurs réguliers, un cycle de mise à jour discipliné depuis plus de vingt ans, une transparence du code que les CMS commerciaux ne peuvent égaler, et une maturité d'écosystème qu'aucune alternative ne propose dans le même registre. Imprudente, parce qu'elle pousse à chercher ailleurs des garanties qui n'existent pas davantage. Les CMS commerciaux fermés, les développements sur mesure non audités, les solutions propriétaires de niche ont tous leur part de vulnérabilités, simplement moins visibles parce que moins documentées et moins exposées au regard public.

Les 11 300 vulnérabilités divulguées en 2025 sont aussi le revers d'une force : un écosystème qui expose publiquement ses propres faiblesses, dans des bases de données accessibles, avec des chercheurs en sécurité dédiés (Patchstack, Wordfence, WPScan) qui scrutent en permanence le parc d'extensions et qui publient les correctifs avec un degré de transparence rare. Un CMS fermé qui ne publierait pas son nombre de vulnérabilités annuelles ne serait pas plus sûr, simplement plus opaque. La transparence est ici un atout structurel, à condition d'avoir les outils pour la lire et d'en tirer des conséquences opérationnelles.

L'expérience que nous accumulons chez MtoM Création sur les sites WordPress que nous mettons en production et que nous maintenons converge sur un constat simple. Un site qui applique les règles de base décrites plus haut, qui tient ses mises à jour, qui choisit ses extensions avec discernement et qui surveille son intégrité, traverse les années sans incident sérieux. Les sites qui se font compromettre sont presque toujours ceux qui ont laissé filer un ou plusieurs de ces fondamentaux : extensions abandonnées qui traînent, mots de passe administrateurs faibles, absence de 2FA, version du cœur en retard de plusieurs mois. La plate-forme n'est pas le problème, c'est le niveau d'attention qui lui est consacré.

Pour une PME qui hésite à choisir WordPress au regard des chiffres présentés, le bon arbitrage n'est pas de se détourner de la plate-forme, c'est de prévoir dès le départ le budget et la discipline d'attention que sa mise en production raisonnée demande. WordPress reste un choix solide pour la majorité des projets web standards, à condition d'intégrer la sécurité dans le cycle de vie du site plutôt que de la traiter comme une option qu'il faudra activer plus tard.

La sécurité comme processus, pas comme produit

Aucun plugin, aucun hébergeur, aucune mesure technique ne suffit à elle seule à sécuriser un site WordPress. Les chiffres de 2025 et les incidents d'avril 2026 le rappellent avec une netteté inhabituelle : la sécurité n'est pas un état que nous atteignons, c'est un processus que nous tenons. Mises à jour rapides, choix défendables, hygiène des comptes, durcissement de la plate-forme, surveillance d'intégrité, veille hebdomadaire. Ces six disciplines mobilisées ensemble réduisent le risque résiduel à un niveau gérable. Aucune mobilisée seule ne suffit.

Pour une PME propriétaire d'un site WordPress, deux trajectoires sont raisonnables. Déléguer ce processus à une équipe qui le tient comme service, avec un contrat de maintenance qui couvre la veille, les mises à jour, les audits trimestriels et l'intervention en cas d'incident. Ou s'en charger en interne avec une discipline réelle, en acceptant le coût en temps que cela représente. Entre ces deux trajectoires, l'intermédiaire « on s'en occupe quand on y pense » est précisément celui que les attaquants ciblent en priorité, parce qu'il garantit une fenêtre de patching longue et une attention faible.

Chez MtoM Création, nous intégrons ces six disciplines dans nos contrats d'accompagnement WordPress. Nous appliquons les mesures de durcissement décrites ici à chaque site que nous mettons en production, nous faisons les audits trimestriels, nous suivons la veille Patchstack et Wordfence, et nous intervenons immédiatement quand une vulnérabilité touche une extension installée chez un client. Cette approche n'élimine pas le risque, elle le ramène à un niveau où une attaque réussie devient un incident gérable plutôt qu'une crise existentielle. C'est l'objectif réaliste que la photographie actuelle de l'écosystème WordPress permet d'atteindre.