Sécuriser WordPress : les 10 mesures qui arrêtent vraiment les attaques

Le 17 juillet 2026, l’équipe de sécurité de WordPress publie la version 7.0.2 pour corriger une faille critique du cœur. Selon Patchstack, les premières tentatives d’exploitation arrivent sur ses capteurs environ quatre-vingt-dix minutes plus tard.

Ce délai est plus court que le temps qu’il faut à la plupart des responsables de site pour lire une alerte, ouvrir l’administration et cliquer sur « Mettre à jour ».

Cette histoire résume la sécurité de WordPress en 2026. Les attaques ne visent presque jamais un site en particulier : elles balaient le web à la recherche de failles connues, et elles le font plus vite que n’importe quel humain.

Les dix mesures qui suivent portent sur des pratiques et des réglages plutôt que sur des plugins. Elles sont classées selon notre lecture des attaques réellement observées, avec pour chacune la façon de la mettre en place et de vérifier qu’elle fonctionne.

Comment nous les avons classés

Aucun rapport ne classe ces mesures. L’ordre proposé ici est notre lecture des données publiées par deux des acteurs qui observent le plus d’attaques sur WordPress : le rapport annuel 2026 de Patchstack et les rapports de Wordfence (bilan 2024 et deuxième trimestre 2026).

Ces données disent trois choses. D’abord, l’immense majorité des failles se trouve dans les extensions : Patchstack attribue 91 % des vulnérabilités découvertes en 2025 aux plugins, le reste aux thèmes, et seulement six au cœur, toutes jugées peu prioritaires par Patchstack. Ensuite, les attaquants exploitent vite : environ la moitié des failles à fort impact sont exploitées dans les 24 heures.

Enfin, le correctif n’existe pas toujours : en 2025, 46 % des failles n’avaient reçu aucun correctif de leur éditeur au moment de leur publication. Notre article sur ce que disent vraiment les chiffres des vulnérabilités WordPress détaille ces rapports.

D’où notre ordre. Les mesures 1 à 3 agissent sur la voie d’entrée dominante, l’exploitation de failles connues. Les mesures 4 à 6 protègent les accès. Les mesures 7 et 8 limitent les dégâts d’une intrusion. Les mesures 9 et 10 n’empêchent rien : elles raccourcissent la détection et rendent la remise en état possible.

Une précaution s’impose : Patchstack et Wordfence vendent tous deux des protections, et leurs rapports recommandent ce qu’ils vendent. Leurs chiffres restent les meilleures observations disponibles, mais gardez ce biais en tête.

1. Mettre à jour automatiquement : fermer la porte la plus utilisée

Pourquoi c’est la priorité

Les failles les plus attaquées sont rarement nouvelles. Au deuxième trimestre 2026, la vulnérabilité la plus ciblée selon Wordfence restait une élévation de privilèges dans LiteSpeed Cache, corrigée en août 2024. Deux ans plus tard, près de 50 millions de requêtes la visaient encore au deuxième trimestre 2026, signe que les attaquants trouvent toujours des sites à exploiter.

Face à des attaques qui démarrent en quelques heures, une mise à jour manuelle hebdomadaire arrive toujours trop tard. La mise à jour automatique est ce qui se rapproche le plus du rythme des attaquants.

Comment faire

Laissez actives les mises à jour mineures du cœur, réglage par défaut de WordPress (constante WP_AUTO_UPDATE_CORE sur 'minor'). Activez les mises à jour automatiques des plugins depuis l’écran Extensions, un par un ou en masse, et celles des thèmes un par un, depuis Apparence, puis Thèmes. La fonction existe depuis WordPress 5.5.

Depuis WordPress 6.6, sorti en juillet 2024, une mise à jour automatique de plugin qui provoque une erreur fatale est annulée d’elle-même, et l’administrateur reçoit un e-mail. C’était l’argument principal contre l’automatisation : il a largement perdu de sa force.

Pour les plugins et thèmes premium, gardez les licences actives : une licence expirée bloque généralement les mises à jour. Patchstack relève que les composants premium ont présenté trois fois plus de failles activement exploitées que les composants gratuits en 2025.

Comment vérifier

WordPress lance ses mises à jour automatiques deux fois par jour, via son système de tâches planifiées. Si elles ne partent pas, l’outil Santé du site (Outils, puis Santé du site) le signale. Après chaque correctif de sécurité important, vérifiez le numéro de version installé, au lieu de supposer que la mise à jour a eu lieu. La commande wp core version et les autres commandes WP-CLI essentielles rendent ce contrôle immédiat sur plusieurs sites.

Limites

Une mise à jour ne sert à rien quand le correctif n’existe pas encore. Et le canal de mise à jour lui-même peut être détourné, comme l’a montré l’attaque de juin 2024 racontée à la mesure 4. Mettre à jour reste indispensable, mais c’est une relation de confiance qu’il faut doubler d’autres protections.

Le cas wp2shell : quatre-vingt-dix minutes entre le correctif et l’attaque

Pendant des années, le discours rassurant était le même : le cœur de WordPress est sûr, ce sont les plugins qui posent problème. L’été 2026 a nuancé ce discours, et l’affaire baptisée « wp2shell » illustre à elle seule la moitié des mesures de cette liste.

La faille

Le chercheur Adam Kues, de Searchlight Cyber, a découvert une confusion de routes dans le point d’accès « batch » de l’API REST, qui permet d’envoyer plusieurs requêtes en une seule. Combinée à une injection SQL dans la classe WP_Query, signalée par une autre équipe, elle conduisait à l’exécution de code à distance.

Selon Searchlight Cyber, l’attaque ne demandait aucun compte et fonctionnait sur une installation standard sans aucun plugin. Cloudflare a précisé une condition : le chemin vers l’exécution de code supposait l’absence de cache objet persistant. La chaîne complète touchait les versions 6.9.0 à 7.0.1 ; la branche 6.8 n’était exposée qu’à l’injection SQL.

Les premières heures

Le 17 juillet 2026, WordPress publie les versions 7.0.2, 6.9.5 et 6.8.6. Vu la gravité, WordPress.org active la mise à jour forcée, via le système de mises à jour automatiques, pour tous les sites concernés. Le même jour, Cloudflare déploie des règles de pare-feu pour tous ses clients, y compris en offre gratuite.

Patchstack, de son côté, voit arriver les premières tentatives d’exploitation environ quatre-vingt-dix minutes après la publication. Trois jours plus tard, la société Wiz publie ses mesures : parmi les organisations utilisant WordPress qu’elle observe, la part exposant un serveur vulnérable sur Internet était passée de 25 % à 10 % en vingt-quatre heures, à mesure que les correctifs s’installaient.

Le 21 juillet, l’agence américaine CISA inscrit les deux failles à son catalogue des vulnérabilités activement exploitées. Wiz décrit ce que faisaient les attaquants une fois entrés : collecte des identifiants et des adresses des administrateurs via l’API, accès à l’administration, tentatives de lecture de wp-config.php, puis installation de portes dérobées déguisées en plugins, par le formulaire d’envoi de plugin. Patchstack a vu de son côté trois adresses IP tenter de créer directement des comptes administrateurs.

Le contournement des pare-feu

Le même 21 juillet, Patchstack observe un changement de tactique. La plupart des règles publiées dans l’urgence cherchaient le chemin de l’API batch dans l’URL. Les attaquants l’ont simplement déplacé dans le corps de la requête. Les règles qui ne regardaient que l’adresse ne voyaient plus rien.

Patchstack publie le lendemain son analyse : plus de 65 000 tentatives bloquées venant de plus de 1 500 adresses IP, dont l’essentiel servait à repérer les sites vulnérables. La société précise honnêtement qu’il s’agit de tentatives bloquées, pas de compromissions réussies. Aucune source primaire n’a publié le nombre total de sites piratés.

Ce que l’affaire enseigne

Les sites dont les mises à jour automatiques fonctionnaient ont reçu le correctif sans intervention. Ceux dont les mises à jour étaient désactivées, bloquées par des droits de fichiers ou gérées par un déploiement maison ont dû agir à la main. Dans tous les cas, Patchstack recommandait de vérifier l’absence d’administrateurs ou de plugins inconnus, puisque l’exploitation avait commencé avant que tous les sites soient corrigés.

Le pare-feu a fait gagner du temps, mais les règles publiées dans l’urgence, presque toutes limitées à l’adresse, ont été contournées en quatre jours. Cloudflare l’a résumé lui-même : ces protections ne remplacent pas le correctif. Quant aux traces laissées par les intrus (nouveaux administrateurs, plugins inconnus, fichiers PHP dans le dossier des médias), seule une surveillance active permettait de les repérer vite.

2. Supprimer les plugins abandonnés, fermés ou inutiles

Pourquoi c’est important

Un plugin désactivé reste sur le serveur, avec tous ses fichiers PHP. Un plugin abandonné ne recevra jamais de correctif. Et un plugin retiré du répertoire officiel pour une faille non corrigée apparaît, dans votre tableau de bord, exactement comme un plugin à jour.

Patchstack a compté 1 614 plugins et thèmes retirés du répertoire en 2024 pour des failles non corrigées. Le ticket qui demande à WordPress d’alerter l’administrateur dans ce cas est ouvert depuis des années, sans date de livraison.

Comment faire

Une fois par trimestre, supprimez tout plugin désactivé et tout thème inutilisé, en gardant un thème par défaut comme solution de secours. Pour chaque plugin restant, ouvrez sa fiche sur WordPress.org : un bandeau signale ceux qui n’ont pas été testés avec les trois dernières versions majeures, et une fiche fermée l’indique clairement.

Wordfence considère comme abandonné un logiciel qui n’a reçu aucune mise à jour depuis deux ans. Remplacez-le par une alternative maintenue, même s’il fonctionne encore.

Comment vérifier

Les scanners de vulnérabilités (Wordfence, Patchstack, WPScan) signalent les composants fermés ou non corrigés. Le nombre d’installations n’est pas un critère de sûreté en soi : un petit plugin mis à jour régulièrement vaut mieux qu’un plugin populaire laissé à l’abandon.

3. Un pare-feu qui connaît WordPress, en bordure et dans l’application

Pourquoi c’est important

Un pare-feu applicatif (WAF) bloque les requêtes d’attaque avant qu’elles n’atteignent le code vulnérable. C’est souvent la seule protection qui ne demande pas de retirer le composant vulnérable pendant la fenêtre où le correctif n’existe pas encore, ou n’est pas encore installé.

Tous les pare-feu ne se valent pas. Lors de tests d’intrusion menés en 2025 sur des configurations d’hébergeurs, Patchstack indique que les défenses classiques n’ont bloqué que 12 % des attaques propres à WordPress. Le chiffre vient d’un éditeur de solutions de protection, mais Wordfence fait le même constat : un pare-feu générique protège mal un site WordPress.

En bordure ou dans WordPress

Un pare-feu en bordure, comme celui de Cloudflare ou de Sucuri, filtre le trafic avant qu’il n’arrive au serveur. Il absorbe les attaques par force brute et les gros volumes, sans consommer les ressources du site. Mais il ignore tout de WordPress : quels plugins sont installés, en quelle version, quel utilisateur est connecté.

Un pare-feu applicatif, comme Wordfence ou Patchstack, s’exécute dans WordPress. Il connaît ce contexte et peut appliquer une règle à une version précise d’un plugin. En contrepartie, il consomme des ressources du serveur sous forte attaque, et il peut être modifié par un intrus qui a déjà pris pied. La combinaison des deux reste la réponse la plus solide.

Prix

Au moment où nous écrivons, en octobre 2026, Wordfence est gratuit avec un décalage de trente jours sur les nouvelles règles et signatures, et coûte 149 dollars par an en version Premium, sans décalage. Patchstack propose une offre Developer à 69 dollars par mois en facturation annuelle (828 dollars par an), 79 dollars en facturation mensuelle. L’offre gratuite de Cloudflare inclut un jeu de règles géré gratuit, les offres payantes des jeux plus complets. Notre comparatif des plugins de sécurité WordPress détaille ces outils.

Comment vérifier

Consultez les journaux du pare-feu : ils montrent les requêtes bloquées règle par règle. Après la publication d’une faille majeure, vérifiez qu’une règle existe et qu’elle inspecte le corps des requêtes, pas seulement l’adresse : c’est par là que les attaquants de wp2shell ont contourné les premières règles.

4. Double authentification et clés d’accès pour tous les comptes à privilèges

Pourquoi c’est important

Les attaques sur les mots de passe restent massives : Wordfence en a bloqué plus de 55 milliards en 2024, et encore 18,2 milliards au seul deuxième trimestre 2026. Un mot de passe réutilisé sur un autre service, puis divulgué lors d’une fuite, suffit à ouvrir un compte administrateur.

L’attaque de juin 2024

En juin 2024, un attaquant a pris le contrôle de cinq comptes de développeurs de plugins sur WordPress.org. Il n’a rien piraté de sophistiqué : il a essayé des combinaisons d’identifiants déjà divulguées lors de fuites de données, et certaines fonctionnaient.

Avec ces accès, il a publié des mises à jour piégées de plusieurs plugins, dont Social Warfare. Le code malveillant lisait le fichier de configuration pour récupérer les identifiants de la base, créait un compte administrateur et injectait du spam dans les pages. Selon Wordfence, environ 35 000 sites auraient pu être touchés.

La réponse de WordPress.org a été directe : réinitialisation forcée des mots de passe des auteurs de plugins, puis double authentification obligatoire pour les auteurs de plugins et de thèmes et les comptes disposant des droits de publication, à partir du 1er octobre 2024. Le principe vaut pour vos propres comptes : un mot de passe divulgué ailleurs ne doit jamais suffire à entrer.

Comment faire

Imposez la double authentification au moins aux rôles Administrateur, Éditeur et Gestionnaire de boutique. Préférez une application de codes temporaires, une clé de sécurité ou une clé d’accès (passkey) à l’e-mail ou au SMS ; la documentation officielle précise que le SMS n’est pas un canal sûr. Gardez les codes de secours hors ligne.

Le cœur de WordPress ne propose toujours pas de double authentification. Le plugin Two Factor, maintenu par des contributeurs de WordPress, la fournit gratuitement. Wordfence propose les clés d’accès gratuitement depuis sa version 9.0, en août 2026 ; son ancien plugin séparé, Wordfence Login Security, a été fermé à la demande de son auteur le 17 août 2026, ses fonctions étant reprises par le plugin principal.

Limites

La double authentification ne protège ni contre une faille exploitable sans compte, comme wp2shell, ni contre le vol d’un cookie de session déjà ouvert. Les mots de passe d’application, conçus pour les intégrations, la contournent par construction : donnez-en un par service et révoquez-le dès qu’il ne sert plus.

Un plugin de double authentification peut lui-même contenir une faille : fin septembre 2026, la version 0.17.0 de Two Factor a corrigé un défaut qui laissait un simple mot de passe passer par l’API REST ou XML-RPC sans second facteur.

5. Le moindre privilège : le bon rôle pour chaque compte

Pourquoi c’est important

Selon Wordfence, le niveau d’accès le plus souvent requis pour exploiter les failles publiées en 2024 était celui de Contributeur. Autrement dit, chaque compte Contributeur de trop est un point d’appui pour une partie des attaques.

Les rôles par défaut ne sont pas anodins. Sur une installation non multisite, un Éditeur dispose de la capacité unfiltered_html, qui lui permet de publier du code arbitraire. Seuls les Administrateurs peuvent installer des plugins ou créer des utilisateurs.

Comment faire

Un compte nommé par personne, jamais de compte administrateur partagé. Le rôle le plus bas qui suffit : un rédacteur qui ne publie pas lui-même peut rester Contributeur. Les prestataires reçoivent des comptes temporaires, supprimés en fin de mission. Notre guide des rôles et capacités WordPress détaille chaque niveau.

Si personne n’a besoin de publier du HTML brut, la constante DISALLOW_UNFILTERED_HTML retire cette capacité à tous les utilisateurs, administrateurs compris.

Comment vérifier

La commande wp user list --role=administrator liste les administrateurs. Comparez avec la liste des personnes qui doivent l’être, chaque trimestre. Certains logiciels malveillants filtrent ces listes : Wordfence recommande de contrôler aussi la table des utilisateurs directement dans la base de données. Un journal d’activité indique en plus la dernière connexion de chacun.

6. XML-RPC et API REST : réduire ce qui est exposé

Pourquoi c’est important

La documentation officielle le dit sans détour : xmlrpc.php est une cible fréquente des attaques par force brute, notamment via la méthode system.multicall, qui teste de nombreux mots de passe en une seule requête. Si vous n’utilisez pas XML-RPC, désactivez-le.

L’API REST est un autre point d’entrée. wp2shell passait par son point d’accès batch, et plusieurs des failles de plugins les plus attaquées en 2026 passent par des routes REST mal protégées.

Comment faire

Bloquez xmlrpc.php au niveau du serveur ou du pare-feu en bordure, plutôt que par un plugin. Attention aux exceptions : Jetpack exige un fichier XML-RPC accessible, comme certaines applications mobiles. Le filtre xmlrpc_enabled ne désactive que les méthodes authentifiées, pas l’ensemble du service.

Ne désactivez jamais l’API REST : la documentation précise que cela casse l’administration elle-même. Vous pouvez en revanche exiger une authentification pour les requêtes anonymes avec le filtre rest_authentication_errors, en testant ensuite les fonctions du site qui en dépendent.

Comment vérifier

Appelez /xmlrpc.php depuis l’extérieur : un blocage doit renvoyer une erreur 403 ou 404. Appelez /wp-json/wp/v2/users sans être connecté et regardez ce qui s’affiche.

7. Durcir wp-config.php : DISALLOW_FILE_EDIT, DISALLOW_FILE_MODS et le reste

Pourquoi c’est important

Le fichier wp-config.php contient les identifiants de la base de données. Le code malveillant de juin 2024 le lisait pour en extraire les identifiants de la base. Quelques constantes y limitent aussi ce qu’un intrus peut faire avec un compte administrateur volé.

Comment faire

Les réglages essentiels, vérifiés sur la documentation officielle :

define( 'DISALLOW_FILE_EDIT', true );  // retire l'éditeur de fichiers des thèmes et plugins
define( 'FORCE_SSL_ADMIN', true );     // connexion et administration toujours en HTTPS
define( 'WP_DEBUG', false );           // pas de mode débogage en production

Placez si possible wp-config.php un niveau au-dessus de la racine web, avec des permissions 440 ou 400. Pour la base de données, l’utilisateur courant n’a besoin que de lire, insérer, modifier et supprimer des lignes. Vérifiez aussi que l’affichage des erreurs est coupé au niveau de PHP (display_errors). Si vous activez le journal de débogage, sachez que wp-content/debug.log fait partie des fichiers que les robots cherchent.

Le cas de DISALLOW_FILE_MODS

La constante DISALLOW_FILE_MODS va plus loin : elle interdit toute installation ou mise à jour de plugin et de thème depuis l’administration. Elle aurait fermé le chemin utilisé par les attaquants de wp2shell pour installer leurs portes dérobées.

Mais elle désactive aussi les mises à jour automatiques, y compris les correctifs de sécurité forcés par WordPress.org. Ne l’utilisez que si vos mises à jour passent par un autre canal, comme un déploiement Git, ou en réautorisant explicitement le système de mise à jour automatique par le filtre file_mod_allowed.

Comment vérifier

Le menu Éditeur de fichiers du thème doit avoir disparu. Depuis l’extérieur, wp-config.php et wp-content/debug.log ne doivent renvoyer aucun contenu.

8. Permissions de fichiers et aucun PHP dans le dossier des médias

Pourquoi c’est important

Le dossier wp-content/uploads est accessible en écriture par conception. Les scripts malveillants déposés par un formulaire d’envoi vulnérable y atterrissent naturellement. Parmi les indices de compromission de wp2shell, Patchstack cite justement des fichiers PHP inattendus dans ce dossier.

Comment faire

La documentation officielle fixe les permissions : 755 ou 750 pour les dossiers, 644 ou 640 pour les fichiers, 440 ou 400 pour wp-config.php, et jamais 777, pas même pour le dossier des médias. Interdisez ensuite l’exécution de PHP dans les médias. Sous Nginx, la documentation propose :

location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

Sous Apache, un fichier .htaccess dans le dossier des médias fait l’affaire. Attention : Nginx l’ignore totalement, et OpenLiteSpeed ne lit dans un .htaccess que les règles de réécriture. Sur ces serveurs, la règle doit être posée dans la configuration du site.

Comment vérifier

Déposez un petit fichier PHP de test dans le dossier des médias et appelez-le : il ne doit pas s’exécuter. Supprimez-le ensuite.

9. Surveiller et journaliser : voir l’intrus avant vos clients

Pourquoi c’est important

La plupart des attaques décrites ici laissent des traces : un compte administrateur au nom étrange, un plugin inconnu, un fichier PHP dans le dossier des médias. Certaines les masquent. En septembre 2026, Wordfence a documenté un logiciel malveillant installé comme plugin « must-use », chargé à chaque requête, absent de l’écran Extensions habituel, et qui cachait son compte administrateur de l’écran Utilisateurs comme de l’API REST.

Certaines infections montrent une page propre au propriétaire et aux scanners, et du spam aux moteurs de recherche. Sans surveillance, on les découvre quand un client se plaint.

Comment faire

Installez un journal d’activité, comme WP Activity Log ou Simple History, tous deux gratuits et maintenus. Configurez des alertes sur la création d’un administrateur, un changement de rôle, l’installation d’un plugin ou d’un thème, et toute modification du dossier mu-plugins. Programmez des analyses de logiciels malveillants et gardez les journaux du serveur assez longtemps pour enquêter.

Comment vérifier

Créez un utilisateur de test et assurez-vous que l’alerte arrive. Un journal stocké sur le serveur compromis peut être effacé : un envoi des journaux hors du serveur est plus solide.

10. Des sauvegardes testées, stockées ailleurs

Pourquoi c’est important

Une sauvegarde n’empêche aucune intrusion. Elle décide si une intrusion coûte un après-midi ou un désastre. Certaines familles de logiciels malveillants, actives dans la mémoire du serveur, réécrivent les fichiers dès qu’ils sont restaurés. Il faut donc un point de restauration antérieur à l’infection, mais aussi arrêter le processus malveillant et corriger la porte d’entrée avant de restaurer.

Comment faire

La documentation de WordPress recommande de conserver plusieurs sauvegardes récentes, de trois à cinq, dans des lieux différents, et d’en faire une avant chaque mise à jour importante. L’agence américaine CISA ajoute une exigence essentielle : au moins une copie hors ligne et chiffrée, car les attaquants cherchent à supprimer les sauvegardes accessibles.

Une sauvegarde rangée sur le même serveur, ou supprimable avec les identifiants du site, ne protège de rien. Notre comparatif des solutions de sauvegarde WordPress détaille les outils et leurs méthodes de restauration.

Comment vérifier

Une fois par trimestre, restaurez une sauvegarde sur une copie de test et chronométrez l’opération. Tant qu’une sauvegarde n’a jamais été restaurée, rien ne prouve qu’elle fonctionne.

Par où commencer

Toutes ces mesures ne demandent pas le même effort. Pour un blog ou un site vitrine, les mesures 1, 2, 4 et 10 couvrent l’essentiel en une heure de travail : mises à jour automatiques, ménage des plugins, double authentification, sauvegarde externe.

Pour une boutique WooCommerce, ajoutez sans attendre un pare-feu (mesure 3) et une surveillance (mesure 9) : l’enjeu financier justifie de détecter vite. Pour une agence qui gère de nombreux sites, la priorité est l’outillage : mises à jour vérifiées à distance, inventaire des plugins, alertes centralisées. Une checklist de maintenance WordPress aide à tenir ce rythme dans la durée.

Tableau récapitulatif

Mesure	Ce qu’elle arrête	Effort	Comment vérifier
1. Mises à jour automatiques	L’exploitation de failles connues	Faible	Version installée, Santé du site
2. Ménage des plugins	Les failles qui ne seront jamais corrigées	Faible	Fiches WordPress.org, scanner
3. Pare-feu WordPress	Les attaques avant le correctif	Moyen	Journaux de blocage
4. Double authentification	Les mots de passe volés ou devinés	Faible	Connexion sans second facteur refusée
5. Moindre privilège	Les failles qui exigent un compte	Faible	Revue trimestrielle des comptes
6. XML-RPC et API REST	La force brute, les routes exposées	Moyen	Appels externes de test
7. wp-config.php	L’usage abusif d’un compte volé	Faible	Éditeur absent, fichier illisible
8. Permissions, médias	L’exécution d’un script déposé	Moyen	Fichier PHP de test non exécuté
9. Surveillance	Rien, elle détecte	Moyen	Alerte reçue sur un compte de test
10. Sauvegardes	Rien, elles réparent	Moyen	Restauration trimestrielle chronométrée

Questions fréquentes

Le cœur de WordPress est-il sûr en 2026 ?

Il reste de loin la partie la mieux défendue de l’ensemble : six failles mineures seulement en 2025 selon Patchstack. Mais 2026 a montré qu’il n’est pas invulnérable, avec deux affaires inscrites au catalogue des failles exploitées de la CISA, en juillet puis en septembre. Les mises à jour automatiques du cœur doivent rester actives.

Ai-je besoin d’un plugin de sécurité si mon hébergeur a un pare-feu ?

Souvent, oui. Un pare-feu d’hébergeur générique bloque mal les attaques propres à WordPress. Demandez à votre hébergeur s’il applique des règles spécifiques aux plugins (correctifs virtuels). Sinon, un pare-feu applicatif complète utilement sa protection.

Faut-il désactiver XML-RPC ?

Oui, si rien ne l’utilise. Vérifiez d’abord Jetpack, les applications mobiles et les outils de publication à distance. Bloquez-le au niveau du serveur plutôt qu’avec le filtre xmlrpc_enabled, qui laisse une partie du service active.

Les clés d’accès valent-elles mieux que la double authentification ?

Elles résistent mieux à l’hameçonnage, car elles sont liées au site et ne se recopient pas. Elles peuvent même remplacer le mot de passe. Pour un compte administrateur, une clé d’accès ou une clé de sécurité est aujourd’hui le meilleur choix, une application de codes temporaires restant une très bonne option.

À quelle fréquence tester une restauration ?

Au moins une fois par trimestre, et après chaque changement important d’hébergement ou d’outil de sauvegarde. Le test doit aller jusqu’au bout : site restauré, navigable, connexion fonctionnelle.

Conclusion

La sécurité de WordPress tient moins à un outil miracle qu’à une hygiène : des mises à jour qui partent seules, un inventaire de plugins tenu, des accès réduits et protégés, et la capacité de voir puis de réparer.

L’affaire wp2shell l’a montré en conditions réelles : les sites qui se mettaient à jour automatiquement ont reçu le correctif sans intervention, les autres ont dû agir à la main alors que la faille était déjà exploitée. Dans les deux cas, la vérification des comptes et des plugins restait nécessaire.

Sources

• Patchstack (février 2026). State of WordPress Security in 2026
• Wordfence (avril 2025). 2024 Annual WordPress Vulnerability and Threat Report
• Wordfence (29 septembre 2026). Quarterly WordPress Threat Intelligence Report, Q2 2026
• WordPress.org (17 juillet 2026). WordPress 7.0.2 Release
• Patchstack, Dave Jong (22 juillet 2026). Ninety minutes: watching attackers weaponize the WordPress core RCE
• Cloudflare (17 juillet 2026). Cloudflare WAF protects WordPress applications from two high-severity vulnerabilities
• Wiz (20 juillet 2026). Exploitation in the Wild of wp2shell
• Searchlight Cyber, Adam Kues (juillet 2026). wp2shell: Pre Authentication RCE in WordPress Core
• CISA. Known Exploited Vulnerabilities Catalog
• Wordfence (26 juin 2024). Developer Accounts Compromised Due to Credential Reuse in WordPress.org Supply Chain Attack
• Make WordPress Plugins (1er octobre 2024). Plugin Check and 2FA Now Mandatory For New Plugin Submissions
• WordPress.org (16 juillet 2024). WordPress 6.6 « Dorsey »
• WordPress Developer Resources (2026). Hardening WordPress
• WordPress Developer Resources (2026). Editing wp-config.php
• WordPress Developer Resources (2026). Brute Force Attacks
• WordPress Developer Resources (2025). Changing File Permissions
• WordPress REST API Handbook. Frequently Asked Questions
• Wordfence (22 septembre 2026). Inside a Malicious, Stealthy WordPress Must Use Plugin
• CISA (septembre 2023). #StopRansomware Guide
• Patchstack (mars 2025). State of WordPress Security in 2025
• Patchstack (octobre 2024). Security implications of WordPress repository access restrictions and plugin closures
• Wordfence (27 juin 2024). An Inside Look at The Malware and Techniques Used in the WordPress.org Supply Chain Attack
• Make WordPress Plugins (29 juin 2024). Password Reset Required for Plugin Authors
• Make WordPress Plugins (4 septembre 2024). Upcoming Security Changes for Plugin and Theme Authors on WordPress.org
• Wordfence (15 septembre 2026). Free Passkeys by Wordfence
• Wordfence (octobre 2026). Pricing
• Patchstack (octobre 2026). Pricing
• WordPress Developer Resources (2026). Two Step Authentication
• WordPress Developer Resources (2025). Nginx
• WordPress Developer Resources (2026). Backups

---

LaFactory conçoit, développe et maintient des sites WordPress et WooCommerce, mises à jour et sécurité comprises, et développe ses propres plugins. Parlons de votre projet WordPress.