Sécuriser WordPress : 272 sites publics mesurés, et le durcissement
qui compte

Le 6 octobre 2026 à 17 h UTC, wordpress.org annonce la 7.1.3, une version de sécurité. Une heure et vingt minutes plus tard, on relève la page d'accueil de 704 organisations (SBF 120, universités, communes, CHU) pour une autre étude. Sur les 103 sites WordPress dont la version se lit, 29 tournent déjà sur la 7.1.3, et 4 autres sur les correctifs rétroportés le même jour sur les branches précédentes. Sur les mêmes pages, 28 sites restent sur une version que wordpress.org marque "insecure", alors qu'un correctif de leur branche était disponible avant ce jour-là.

C'est le vrai visage de la sécurisation WordPress : pas un CMS fragile, mais deux populations. Celle qui laisse les mises à jour automatiques faire leur travail, et celle qui les a coupées, ou qui tourne sur un hébergement où personne ne regarde plus. Cet article part de cette mesure, puis repasse par un lab pour montrer ce qu'un WordPress raconte de lui-même, comment le faire taire, et pourquoi c'est dans les extensions que se joue l'essentiel.

La mesure : 272 WordPress parmi 636 pages d'accueil

Le panel compte 704 organisations figées avant la collecte : les entreprises du SBF 120, 65 universités, 488 communes de plus de 20 000 habitants et 32 CHU ou CHR. Chacune a reçu une seule visite de la page d'accueil de son site officiel, le 6 octobre entre 18 h 22 et 18 h 26 UTC, avec un User-Agent de robot déclaré. 636 pages ont un contenu exploitable, et 272 sont servies par WordPress (42,8 %), loin devant Drupal (140) et TYPO3 (77). Le CMS se reconnaît à ses chemins et à sa balise generator, sans rien demander d'autre que la page.

La version, elle, ne se lit que sur 103 de ces 272 sites (37,9 %), dans la balise generator ou le paramètre ?ver= des fichiers du coeur. Les deux sources concordent sur les 38 sites où elles coexistent. Les 103 versions sont reconnues par wordpress.org, et c'est sur ces 103 sites que portent les chiffres de version. Ce n'est donc pas un portrait de tout WordPress : un site qui masque sa version peut être parfaitement à jour, et "insecure" signale une version qui a reçu un correctif de sécurité, pas une faille exploitable démontrée sur le site.

Deux WordPress publics : celui qui se met à jour seul, celui qu'on a oublié

La première population est la plus nombreuse. 61 des 103 sites à version lisible (59,2 %) tournent sur la 7.1.2 ou plus récent, la dernière version publiée avant le jour de la mesure. Les 29 sites passés en 7.1.3 en moins d'une heure et demie racontent la même chose : c'est le rythme des mises à jour automatiques de fond, actives par défaut pour les versions mineures, ou d'outils d'hébergeur. Rien dans la mesure ne permet de le vérifier site par site, mais 29 organisations qui patchent toutes à la main dans la même heure et demie, ce serait une coïncidence remarquable.

La seconde est minoritaire et très en retard. 32 sites sur 103 sont sur une branche 6.x ou plus ancienne, et la distribution s'étire jusqu'à une 4.4. Pour les 42 sites qui ne sont pas à jour, la première version plus récente a été publiée il y a 308 jours en médiane, et jusqu'à 3 829 jours. Lisez-les comme des maximums : une balise figée par un cache peut retarder sur la version réellement installée, jamais l'avancer. Le plus ancien affiche une version dépassée depuis plus de dix ans.

Le même retard existe chez le voisin. Sur 140 sites Drupal, 21 tournent sur une version majeure qui n'est plus maintenue (7, 8 ou 9), dont 10 sur Drupal 7, sans support communautaire depuis le 5 janvier 2025 (des tiers vendent un support étendu payant). Quand la version exacte du coeur se lit, sur 31 sites, 18 ont manqué au moins un correctif de sécurité de leur branche. Ce n'est pas un problème de CMS, c'est un problème de maintenance.

Pour poursuivre, on quitte les sites des autres pour un lab. J'ai monté une installation WordPress fraîche de la branche 7.1, sans le moindre plugin ni thème ajouté. Trois minutes après la fin de l'installeur, avec un simple curl et zéro exploit, ce site annonçait sa version à trois endroits et donnait le login de son unique compte. Je montre la sortie réelle, j'applique un durcissement, puis je relance les mêmes commandes pour mesurer l'écart.

Ce qu'un attaquant lit sur votre WordPress en trente secondes

Avant d'attaquer, on cartographie. Un WordPress exposé répond à une poignée de requêtes non authentifiées qui, mises bout à bout, dessinent une empreinte précise : version du coeur, comptes existants, endpoints ouverts. Rien de tout ça n'est une vulnérabilité en soi. C'est du renseignement, et c'est gratuit. La première brique, c'est la version, parce qu'elle conditionne tout le reste : une fois qu'un attaquant sait que vous tournez en 6.8.2, il n'a plus qu'à consulter les avis de sécurité publiés depuis.

Voici la lecture de version sur mon instance de test. La balise generator est la plus connue, mais elle n'est pas seule : le flux RSS embarque la même information dans une balise generator XML, et chaque feuille de style du coeur est servie avec un paramètre ?ver= qui trahit la version exacte.

$ curl -s http://127.0.0.1:8899/ | grep -i 'name="generator"'
<meta name="generator" content="WordPress 7.1" />

$ curl -s 'http://127.0.0.1:8899/?feed=rss2' | grep -io '<generator>[^<]*</generator>'
<generator>https://wordpress.org/?v=7.1</generator>

$ curl -s http://127.0.0.1:8899/wp-login.php | grep -o 'ver=[0-9.]*' | sort -u
ver=1.13.8
ver=7.1

Trois requêtes, une réponse cohérente : WordPress 7.1. Le paramètre ver=1.13.8 est encore plus intéressant, car il ne vient pas du coeur : c'est la version d'un composant chargé sur la page de connexion. Ce genre de numéro permet de fingerprinter une bibliothèque précise et de la confronter aux CVE connues, comme le fait un scanner de vulnérabilité par corrélation de bannière. La reconnaissance passive fournit déjà de quoi prioriser une attaque.

Énumération des comptes : le login offert par l'API REST

Le brute force sur WordPress a un préalable : connaître les noms d'utilisateur. Beaucoup pensent qu'un login n'est pas un secret, et c'est vrai, mais le divulguer à qui le demande divise par deux le travail de l'attaquant. Or l'API REST des utilisateurs de WordPress liste par défaut, sans authentification, tous les comptes qui ont publié. Sur mon lab, une requête suffit :

# Sur un site en permaliens jolis :
$ curl -s http://SITE/wp-json/wp/v2/users
# Sur mon lab en permaliens simples, la meme route via query string :
$ curl -s 'http://127.0.0.1:8899/?rest_route=/wp/v2/users' | jq -c '.[] | {id, slug, name}'
{"id":1,"slug":"editeur_demo","name":"editeur_demo"}

Le champ slug est le point sensible : il correspond très souvent au login réel du compte, celui qu'on tape dans wp-login.php. Ici, editeur_demo est à la fois le nom affiché et l'identifiant de connexion. La vieille technique /?author=1, qui redirige vers la page d'archive de l'auteur et révèle son slug dans l'URL, fait le même travail sur les installations qui n'ont pas fermé l'API REST. Une fuite de login est le premier maillon d'une chaîne ; les principes de gestion des fuites de secrets s'appliquent aussi aux identifiants exposés par une API trop bavarde.

xmlrpc.php : l'amplificateur de brute force qu'on oublie

xmlrpc.php est un vestige de l'époque où l'on publiait sur WordPress depuis un client de bureau. Il est toujours présent, toujours actif par défaut, et il pose deux problèmes concrets. Le premier, c'est system.multicall : cette méthode empile plusieurs appels dans une seule requête HTTP. Couplée à wp.getUsersBlogs, qui teste un couple login/mot de passe, elle transforme le brute force en une opération de masse. Au lieu d'une requête par tentative, un attaquant en teste des centaines par requête, sous le radar des limiteurs qui comptent les requêtes. Le second problème, c'est pingback.ping, détourné depuis des années pour lancer des attaques par rebond contre des tiers.

Sur mon lab, l'endpoint répond et se laisse énumérer :

$ curl -s -X POST -d '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
    http://127.0.0.1:8899/xmlrpc.php | grep -c '<string>'
81

$ curl -s -X POST -d '<methodCall><methodName>system.listMethods</methodName></methodCall>' \
    http://127.0.0.1:8899/xmlrpc.php | grep -oE 'system.multicall|wp.getUsersBlogs|pingback.ping'
pingback.ping
system.multicall
wp.getUsersBlogs

Quatre-vingt-une méthodes exposées, dont les trois qui comptent pour un attaquant. Le brute force amplifié par xmlrpc.php est un classique des rapports de test d'intrusion sur un WordPress d'entreprise : la page de login peut être protégée par un limiteur, l'attaquant passe par la porte de derrière. Si vous n'utilisez ni Jetpack, ni l'application mobile, ni les pingbacks, ce fichier ne vous sert à rien et vous coûte une surface d'attaque.

Extensions : 25 292 CVE au moins, contre 356 pour le coeur

Le coeur de WordPress est audité en permanence par une communauté énorme. Le danger est ailleurs, dans les dizaines de milliers d'extensions et de thèmes tiers que l'on empile sur une installation. Pour le chiffrer, on a recompté la NVD entière (instantané du 5 octobre 2026) : 356 CVE touchent le coeur WordPress depuis toujours, contre 25 292 à 38 425 CVE d'extensions selon le comptage. La fourchette vient de Patchstack, une autorité d'attribution de CVE qui publie surtout pour WordPress sans toujours le préciser dans ses descriptions : la plupart des CVE que seul le haut de la fourchette retient sont des extensions, et la valeur réelle est probablement proche du haut.

Les extensions affichent d'ailleurs volontiers leur version. Dans la mesure, 125 des 272 sites WordPress (46 %) annoncent la version d'au moins une extension dans une balise generator. Les plus bavardes sont WP Rocket (53 sites), Elementor (44), Site Kit by Google (20) et WPML (15). Ce n'est pas une faute en soi, c'est une carte : un attaquant qui suit les avis de sécurité d'une extension populaire sait en une requête quels sites sont en retard.

Le profil est celui d'un code écrit vite par beaucoup de mains : près d'une CVE d'extension sur deux est un XSS, puis viennent les CSRF (un formulaire d'administration qui ne vérifie pas le nonce WordPress) et les autorisations manquantes, ces fonctions AJAX qui oublient de vérifier qui les appelle. Le catalogue KEV de la CISA, qui recense les failles dont l'exploitation est confirmée, ne compte que 3 CVE d'extensions, toutes inscrites lors de sa création en novembre 2021, et 3 CVE du coeur ajoutées en 2026. N'en tirez pas de conclusion rassurante : le KEV retient des produits, avec un biais vers le parc fédéral américain, et l'absence d'une extension dans ce catalogue ne dit pas qu'elle n'est pas exploitée.

Cinq CVE d'extensions de 2025, pour fixer les idées

Lisez la colonne du milieu : aucune de ces failles n'est exotique. On retrouve les mêmes familles que dans l'OWASP Top 10 : un contrôle d'accès cassé qui laisse créer un administrateur (SureTriggers) ou prendre la main sur un compte existant (Post SMTP), une désérialisation non fiable qui ouvre l'exécution de code (GiveWP), une validation de chemin insuffisante qui permet de supprimer n'importe quel fichier (Forminator). Le thème Motors, noté 9.8, permettait à un anonyme de réécrire le mot de passe d'un compte existant. Un autre thème de 2025, Alone (CVE-2025-5394, CVSS 9.8), autorisait l'upload de fichiers arbitraires jusqu'à la prise de shell, faute d'un simple contrôle de capacité. Leur point commun : une fois le correctif publié, le diff montre à tout le monde où chercher, et seuls les sites qui ont mis à jour l'extension sont à l'abri.

La conséquence est directe pour votre stratégie : la gestion des vulnérabilités d'un parc WordPress, c'est d'abord un inventaire des extensions et de leurs versions, confronté en continu aux flux de CVE. Un plugin abandonné par son auteur ne recevra jamais de correctif : il faut le remplacer, pas l'oublier.

Durcissement WordPress mesuré : avant et après

J'ai déposé un mu-plugin (un plugin chargé d'office, sans activation dans l'admin) qui fait quatre choses : retirer la version de partout, couper les méthodes d'authentification de xmlrpc.php, fermer l'énumération des utilisateurs par l'API REST, et poser des en-têtes de sécurité. C'est volontairement minimal et sans dépendance, pour que l'effet de chaque ligne soit mesurable.

<?php
// wp-content/mu-plugins/o2p-hardening.php
// 1. Ne plus divulguer la version (balise generator + flux + the_generator)
remove_action('wp_head', 'wp_generator');
add_filter('the_generator', '__return_empty_string');

// 2. Couper les methodes d'auth de XML-RPC (bloque le brute force amplifie)
add_filter('xmlrpc_enabled', '__return_false');

// 3. Refuser l'enumeration anonyme des utilisateurs via l'API REST
add_filter('rest_endpoints', function ($endpoints) {
    unset($endpoints['/wp/v2/users']);
    unset($endpoints['/wp/v2/users/(?P<id>[\d]+)']);
    return $endpoints;
});

// 4. En-tetes de securite (dont une Content-Security-Policy)
add_action('send_headers', function () {
    header('X-Content-Type-Options: nosniff');
    header('X-Frame-Options: SAMEORIGIN');
    header('Referrer-Policy: strict-origin-when-cross-origin');
    header("Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'self'");
});

J'ai ensuite relancé exactement les mêmes requêtes qu'au début. Le résultat :

Les en-têtes apparaissent, l'API REST des utilisateurs répond 404, la version disparaît des trois sources. Voici la vérification côté REST et en-têtes :

# API REST users, apres durcissement :
$ curl -s -o /dev/null -w '%{http_code}\n' 'http://127.0.0.1:8899/?rest_route=/wp/v2/users'
404

# En-tetes de securite, apres durcissement :
$ curl -sD - -o /dev/null http://127.0.0.1:8899/ | grep -iE 'content-security|x-frame|nosniff'
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: default-src 'self'; object-src 'none'; frame-ancestors 'self'

Masquer la version ou fermer une API ne corrige rien, ça retire du bruit et complique le travail de reconnaissance. C'est utile, mais la Content-Security-Policy et le blocage d'xmlrpc.php sont des mesures de défense en profondeur, pas des correctifs. La seule chose qui neutralise une CVE, c'est la mise à jour.

Les en-têtes, justement, sont la partie que les sites publics posent le moins bien. Sur les 272 pages WordPress de la mesure, 140 envoient HSTS (51,5 %), et une seule a une CSP qui bloquerait un script injecté, sans 'unsafe-inline' effectif ni joker sur les scripts. Ce n'est pas propre à WordPress : sur l'ensemble des 655 pages, on en compte 10. Mais un thème et ses extensions qui injectent du JavaScript inline partout rendent l'exercice difficile : la CSP du mu-plugin ci-dessus n'a pas de script-src restrictif pour cette raison. Commencez en Content-Security-Policy-Report-Only, recensez ce qui casserait, puis resserrez.

Le reste du durcissement WordPress : les fondamentaux

Le mu-plugin ci-dessus ferme la reconnaissance et le brute force amplifié. Il ne remplace pas les fondamentaux, qui sont moins spectaculaires mais bien plus déterminants pour ne pas se faire compromettre.

• Mettre à jour, coeur et extensions : les mises à jour automatiques du coeur sont actives par défaut, gardez-les. Pour les plugins et thèmes, activez l'auto-update ou tenez un rythme hebdomadaire. Les 29 sites passés en 7.1.3 dans l'heure et demie montrent que ça marche ; les 28 sites restés sur une version insecure montrent ce qui se passe quand on coupe. Une faille comme wp2shell, la RCE pré-authentifiée du coeur de WordPress rappelle que même le coeur exige une réactivité de mise à jour.
• Réduire la surface : chaque plugin désactivé mais présent reste du code sur le disque, parfois joignable directement. Supprimez ce que vous n'utilisez pas, thèmes par défaut compris. Moins de composants, moins de CVE à suivre.
• Authentification robuste : mots de passe longs et uniques, double authentification sur les comptes administrateurs, et un limiteur de tentatives sur wp-login.php. Le principe du moindre privilège vaut aussi ici : un rédacteur n'a pas besoin d'un rôle administrateur.
• Verrouiller les fichiers sensibles : posez define('DISALLOW_FILE_EDIT', true); dans wp-config.php pour couper l'éditeur de thème et de plugin intégré, une porte royale vers l'exécution de code une fois un compte admin compromis. Protégez l'accès direct à wp-config.php et interdisez l'exécution de PHP dans wp-content/uploads : c'est ce répertoire que visent les failles d'upload arbitraire comme celle du thème Alone.
• Sauvegardes testées : une sauvegarde qu'on n'a jamais restaurée est une hypothèse, pas un filet. Externalisez-la, hors du serveur web, et vérifiez la restauration.

Un plugin de sécurité (pare-feu applicatif, surveillance d'intégrité, limitation de login) peut orchestrer une partie de tout ça, à condition de ne pas le prendre pour une dispense de mise à jour : un pare-feu applicatif filtre le bruit et les scanners, pas une extension vulnérable. Avec 356 CVE pour le coeur et des dizaines de milliers pour les extensions, c'est l'inventaire des extensions et leur rythme de mise à jour qui décident du risque.

Vérifier en continu, pas une seule fois

Le durcissement d'aujourd'hui ne dit rien de l'état de demain. Une extension mise à jour peut réintroduire une régression, un développeur peut installer un thème documenté nulle part, une CVE peut sortir la nuit sur un plugin que vous jugiez sûr. Suivre ces changements, c'est le rôle d'une gestion de la surface d'attaque externe (EASM) : recenser en continu vos sites publics, lire leur version, et signaler ceux qui portent une faille connue.

C'est ce que fait notre plateforme d'External Attack Surface Management : elle découvre les WordPress exposés d'une organisation, les fingerprinte et corrèle leur version aux CVE publiées, y compris via un vérificateur dédié à la faille wp2shell du coeur. Pour un site à logique métier (paiement, espace client, plugins sur mesure), un scan ne suffit plus : c'est le terrain d'un pentest web en boîte noire, où un humain cherche les contournements d'autorisation et les injections que l'automatisme laisse passer.

À retenir

• Deux WordPress publics. Sur 103 sites à version lisible, 29 avaient la 7.1.3 moins d'une heure et demie après sa sortie, 28 restaient sur une version insecure malgré un correctif disponible, et 32 sur une branche 6.x ou plus ancienne. Laissez les mises à jour automatiques actives.
• Un WordPress par défaut divulgue sa version dans la balise generator, le flux RSS et les paramètres ?ver=, et livre le login de ses comptes via /wp-json/wp/v2/users. Mesuré en réel sur une instance de test.
• xmlrpc.php amplifie le brute force via system.multicall ; le filtre xmlrpc_enabled bloque l'auth mais ne ferme pas l'endpoint, à couper au reverse-proxy.
• La vraie surface d'attaque, ce sont les extensions : au moins 25 292 CVE contre 356 pour le coeur, dont 43,5 % de XSS et 12,3 % de CSRF, et 46 % des sites mesurés affichent la version d'une extension.
• Masquer la version et fermer une API réduit la reconnaissance mais ne corrige rien : seule la mise à jour neutralise une CVE.
• Le durcissement mesurable (en-têtes, CSP, REST fermée) tient en un mu-plugin de vingt lignes ; une CSP stricte reste rare (1 page WordPress sur 272) et se construit en report-only d'abord. Les fondamentaux (mise à jour, moindre privilège, 2FA, sauvegardes testées) font le reste.

Si vous voulez savoir combien de WordPress votre organisation expose et lesquels portent une faille connue, la plateforme EASM d'own2pwn les cartographie en continu ; pour un audit manuel d'un site sensible, parlons de votre périmètre.

Questions fréquentes sur la sécurisation WordPress