Failles de sécurité des plugins WordPress : comment les repérer et vous protéger

En 2025, Patchstack a recensé 11 334 nouvelles failles de sécurité dans l’écosystème WordPress. 91 % dans des plugins, 9 % dans des thèmes, et six seulement dans le cœur, toutes jugées de faible priorité. Sur un site WordPress, le danger porte donc rarement le nom de WordPress…

Il porte le nom du plugin installé sans le regarder, gardé sans servir, jamais mis à jour. Ma règle, je la donne telle quelle : "Ce que je regarde au niveau des extensions en priorité, c’est la date de la dernière mise à jour et sa compatibilité avec WordPress. Ça, c’est la base. Généralement, je n’installe que des extensions qui ont fait leurs preuves."

Une faille de sécurité, ou vulnérabilité, est une erreur dans le code d’un plugin qui laisse quelqu’un faire ce qu’il ne devrait pas pouvoir faire : lire la base de données, se créer un compte administrateur, déposer un fichier exécutable. Le risque croise la probabilité qu’elle soit exploitée sur votre site et ce que vous y perdriez, l’incident désigne le jour où elle l’est.

La plupart des failles publiées reçoivent un identifiant CVE (par exemple CVE-2026-19513) et une note de gravité CVSS de 0 à 10. Selon l’échelle du FIRST, qui publie la norme, une note de 7,0 à 8,9 est "haute", de 9,0 à 10 "critique".

Pourquoi les plugins sont le maillon faible

Reprenons ces chiffres, parce qu’ils circulent souvent de travers : ce sont des failles découvertes, pas des failles exploitées, 42 % de plus qu’en 2024. Patchstack en a jugé 4 124 (36 %) assez sérieuses pour mériter une règle de protection, et 1 966 (17 %) susceptibles d’être exploitées dans des attaques automatisées de masse.

Pourquoi les plugins ? Le répertoire officiel en compte 69 796 au 29 septembre 2026, et chacun ajoute son code au vôtre. Les règles de wordpress.org le disent sans détour : "Security is the ultimate responsibility of the plugin developer". Le répertoire examine chaque extension avant de l’accepter, puis ferme celle qui présente une faille jusqu’à sa correction.

Entre les deux, tout repose sur l’éditeur, qui ne suit pas toujours. En 2025, 46 % des failles n’avaient reçu aucun correctif au moment de leur publication, d’où ce constat de Patchstack : les propriétaires de sites "can’t rely on plugin updates as a security measure". Le reste des données est dans mon décryptage du rapport Patchstack 2026.

Ajoutez la taille de la cible : WordPress fait tourner 40,2 % de tous les sites web selon W3Techs (relevé du 29 septembre 2026). Une faille de sécurité dans un plugin populaire expose d’un coup tous les sites qui l’utilisent, et le même script suffit à les balayer.

On présente volontiers l’IA comme la nouvelle menace. Mon avis, dans mes mots : "Une IA réellement pilotée avec des garde-fous n’est absolument pas dangereuse pour un WordPress. Il existe certaines extensions qui sont bien plus dangereuses que l’IA."

Quels types de failles de sécurité touchent les plugins WordPress ?

Derrière une faille de sécurité dans un plugin WordPress, il y a presque toujours une vérification oubliée par le développeur. Connaître les grandes familles ne fera pas de vous un auditeur de code, mais vous saurez lire une alerte et juger si elle vous concerne.

À noter : selon Patchstack, le contrôle d’accès défaillant a été le type de faille le plus exploité en 2025, et il est très difficile à bloquer avec un pare-feu classique, parce que ses attaques "look like normal authenticated traffic".

Injection SQL

Une injection SQL survient quand un plugin glisse une valeur venue de l’extérieur (un champ de formulaire, un paramètre d’URL) directement dans une requête SQL. L’attaquant y ajoute ses propres instructions et lit, modifie ou efface la base : comptes, adresses e-mail, commandes.

La parade existe depuis longtemps, la requête préparée avec $wpdb->prepare(). Le piège, relevé en août 2026 par une étude publiée sur le blog de Sucuri : croire que sanitize_text_field() suffit. Cette fonction nettoie du texte à afficher, elle "does not make a value safe to insert directly into an SQL query".

// Dangereux : le paramètre d'URL est collé dans la requête, sans guillemets à franchir
$resultats = $wpdb->get_results(
    "SELECT post_title FROM {$wpdb->posts} WHERE ID = " . $_GET['id']
);

// Correct : prepare() transmet la valeur à part et la force en entier (%d)
$id        = absint( $_GET['id'] ?? 0 );
$resultats = $wpdb->get_results(
    $wpdb->prepare( "SELECT post_title FROM {$wpdb->posts} WHERE ID = %d", $id )
);

Cross-site scripting (XSS)

Une faille XSS (cross-site scripting) apparaît quand un plugin affiche une donnée sans la neutraliser. L’attaquant y cache du JavaScript, qui s’exécute dans le navigateur de la personne qui ouvre la page, avec ses droits si c’est un administrateur connecté.

La parade porte un nom un peu barbare, l’échappement, et tient en une consigne de la documentation : "Escape as late as possible". esc_html() pour du texte, esc_attr() pour un attribut, esc_url() pour une adresse, wp_kses_post() quand un peu de HTML doit passer.

Falsification de requête (CSRF)

Une faille CSRF retourne votre propre session contre vous. Vous êtes connecté à votre administration, vous cliquez sur un lien piégé, et votre navigateur envoie la demande : supprimer un contenu, changer un réglage, ajouter un utilisateur. La parade, ce sont les nonces, des jetons contrôlés par wp_verify_nonce(), check_admin_referer() ou check_ajax_referer().

Attention au contresens : un nonce ne dit pas qui vous êtes. La documentation est formelle ("Nonces should never be relied on for authentication, authorization, or access control") et renvoie vers current_user_can(). L’étude Sucuri a pourtant trouvé des nonces affichés dans le HTML public, voire mis en commentaire dans le code livré.

// Une action d'administration protégée dans le bon ordre
if ( ! current_user_can( 'manage_options' ) ) {
    wp_die( 'Accès refusé.' );
}
check_admin_referer( 'wpf_vider_journal' );

Contrôle d’accès oublié et escalade de privilèges

Un abonné qui devient administrateur, un client qui lit la commande d’un autre : l’escalade de privilèges naît d’un plugin qui a oublié de vérifier les droits avant d’agir. Pour une route de l’API REST, WordPress réclame un permission_callback, et sa documentation conseille d’y tester une capacité avec current_user_can() plutôt que la simple connexion.

L’étude Sucuri range parmi les erreurs les plus courantes le contrôle par objet oublié : le plugin vérifie par exemple que l’utilisateur peut lire des cours, puis le laisse ouvrir le cours d’un autre sans regarder à qui il appartient.

Cas réel : Advanced Custom Fields: Extended, jusqu’à la version 0.9.2.1 (CVE-2025-14533, CVSS 9,8, publiée le 20 janvier 2026). Sa fonction d’inscription ne limitait pas les rôles, si bien qu’un visiteur anonyme pouvait s’inscrire comme administrateur, à condition que le rôle soit relié à un champ du formulaire.

Contournement d’authentification

Même famille, en plus radical : l’attaquant n’a besoin d’aucun compte, il se connecte directement à la place de quelqu’un. L’exemple le plus parlant concerne… un plugin de sécurité.

Really Simple Security, de la version 9.0.0 à 9.1.1.1 (CVE-2024-10924, CVSS 9,8, publiée le 15 novembre 2024), gérait mal une erreur dans les actions REST de sa double authentification. Un anonyme pouvait se connecter comme n’importe quel utilisateur existant, administrateur compris, dès lors que la double authentification était activée (elle ne l’est pas par défaut).

Sucuri relève une erreur voisine : des liens "secrets" fabriqués avec uniqid(), une fonction PHP "largely based on time", donc prévisible, là où il faudrait une source d’aléa cryptographique comme random_bytes().

Téléversement arbitraire de fichiers

Le téléversement arbitraire commence quand un plugin accepte un fichier sans vérifier ce qu’il est vraiment. Si l’attaquant dépose un fichier PHP (un webshell) dans un dossier public puis l’appelle, il exécute son propre code sur votre serveur. WordPress fournit wp_check_filetype_and_ext() et wp_handle_upload() pour contrôler et traiter l’envoi.

Le cas de l’été vaut le détour. Gravity Forms, extension commerciale estimée à plus d’un million d’installations actives, laissait jusqu’à sa version 3.0.2 un visiteur anonyme écrire un fichier au nom de son choix dans son dossier temporaire (CVE-2026-19513, CVSS 8,1). Condition : un formulaire public avec envoi de fichiers multiples. Correctif en 3.0.3, le 20 août 2026.

La suite dépend du serveur. Gravity Forms dépose en effet dans ce dossier un fichier .htaccess qui y bloque PHP sous Apache ; le fichier PHP est bien écrit mais ne s’exécute pas, et l’attaquant se rabat sur une page HTML, ce qui ouvre une XSS. Sous Nginx, le même envoi mène à l’exécution de code.

Et la série ne s’arrête pas là. Le 18 septembre 2026, Wordfence publiait une nouvelle faille d’envoi de fichiers dans Gravity Forms, elle aussi exploitable sans compte : toutes les versions jusqu’à 3.1.0.4 sont touchées (CVE-2026-84434, CVSS 9,8), dès qu’un formulaire public contient un champ d’envoi de fichiers masqué. Correctif en 3.1.1 : un site resté en 3.0.3 était donc de nouveau exposé.

La documentation de WordPress pour Nginx propose la règle ci-dessous. Nginx testant les expressions régulières "in the order of their appearance in the configuration file" et s’arrêtant à la première qui correspond, elle doit précéder le bloc qui exécute PHP, sinon elle ne sert à rien.

# Refuse tout fichier .php dans le dossier des médias (à placer AVANT le bloc PHP)
location ~* /(?:uploads|files)/.*\.php$ {
    deny all;
}

Inclusion de fichier, injection d’objet PHP et SSRF

Des familles moins connues, tout aussi sérieuses. L’inclusion de fichier, avec sa cousine la traversée de chemin (les fameux ../), fait charger par PHP un fichier désigné par l’attaquant. validate_file() sert à refuser ces chemins, et le correctif de la faille du cœur de septembre (CVE-2026-87902) passe justement par cette fonction.

L’injection d’objet PHP naît d’un unserialize() appliqué à une donnée venue de l’extérieur. Le manuel PHP est clair ("Do not pass untrusted user input to unserialize()") et recommande JSON. La SSRF, elle, pousse votre serveur à interroger une adresse choisie par l’attaquant : wp_safe_remote_get() valide l’adresse et chaque redirection "to avoid Server Side Request Forgery attacks".

Quand six petites faiblesses font une faille critique

Toute typologie a ses limites, et l’affaire Avada les montre bien. Ce thème vendu à plus d’un million d’exemplaires cumulait, avec son plugin Fusion Builder, jusqu’aux versions 7.16 et 3.16, "six separate weaknesses, none sufficient on its own to produce code execution" (CVE-2026-18431, CVSS 9,8). Alignées dans le bon ordre, elles laissaient un anonyme exécuter du PHP.

L’agent Argus de Wordfence a trouvé et prouvé la chaîne en environ deux heures, et ThemeFusion a publié le correctif le 25 août 2026. Il fallait tout de même un certain contenu créé par un administrateur. Aucune des familles ci-dessus, prise seule, n’aurait donné l’alerte.

Voici le récapitulatif, avec pour chaque famille la protection attendue côté code et un cas réel vérifié.

Type de faille	Ce qu’elle permet à l’attaquant	Ce qui protège côté code	Cas réel
Injection SQL	Lire, modifier ou effacer la base	$wpdb->prepare()	Cœur de WordPress, corrigé en 7.0.2 le 17/07/2026 (CVE-2026-60137, maillon de wp2shell)
XSS	Exécuter du JavaScript dans le navigateur d’un visiteur ou d’un administrateur	esc_html(), esc_attr(), esc_url(), wp_kses_post()	LiteSpeed Cache 5.7 et antérieures, faille de 2024 la plus attaquée en 2025 selon Patchstack
CSRF	Faire exécuter une action par un administrateur connecté	wp_verify_nonce(), check_admin_referer()	Nonces exposés dans le HTML public (étude Sucuri, août 2026)
Contrôle d’accès, escalade de privilèges	Devenir administrateur, lire les données d’un autre	current_user_can(), permission_callback	Advanced Custom Fields: Extended 0.9.2.1 et antérieures (CVE-2025-14533, 9,8)
Contournement d’authentification	Se connecter comme n’importe quel utilisateur	Contrôle strict des erreurs, jetons tirés de random_bytes()	Really Simple Security 9.0.0 à 9.1.1.1 (CVE-2024-10924, 9,8)
Téléversement arbitraire	Déposer puis exécuter un fichier PHP	wp_check_filetype_and_ext(), wp_handle_upload()	Gravity Forms 3.0.2 et antérieures (CVE-2026-19513, 8,1)
Inclusion de fichier, traversée de chemin	Faire exécuter un fichier PHP présent sur le serveur	validate_file()	Cœur de WordPress, corrigé en 7.1.2 le 22/09/2026 (CVE-2026-87902)
Injection d’objet PHP	Déclencher du code au moment de la désérialisation	json_decode() plutôt que unserialize()	GiveWP 3.14.1 et antérieures, dans le top 10 Patchstack des failles les plus attaquées en 2025
Chaîne de faiblesses	Exécuter du code à partir de défauts mineurs	Revue de code complète, pas une case à cocher	Avada 7.16 et Fusion Builder 3.16 (CVE-2026-18431, 9,8)
Porte dérobée	Se connecter comme administrateur grâce à un code caché	Sécurité des comptes de l’éditeur, détection rapide	Advanced Responsive Video Embedder 10.8.7 et 10.8.8 (CVE-2026-18072, 9,8)

Comment lire un avis de sécurité sans être développeur ?

Une alerte tombe, dans un e-mail ou dans le tableau de bord de votre plugin de sécurité. Avant de paniquer (ou de hausser les épaules…), cinq minutes de lecture suffisent pour savoir si vous êtes concerné et à quelle vitesse agir. L’avis de Wordfence sur Gravity Forms, repris de sa base Wordfence Intelligence, fait un très bon support d’exercice.

Ma version est-elle touchée ? L’avis indique "Affected Version(s) <= 3.0.2" et "Patched Version 3.0.3" : toutes les versions jusqu’à 3.0.2 incluse sont concernées. Comparez avec le numéro affiché dans Extensions > Extensions installées. À partir de 3.0.3, vous êtes tranquille sur ce point.

Faut-il un compte pour l’exploiter ? "Unauthenticated" signifie que n’importe quel visiteur, donc n’importe quel robot, peut tenter sa chance. La mention "Contributor+", que l’on trouve par exemple dans la note de version de WordPress 7.1.1, réserve l’attaque à quelqu’un qui possède déjà un compte de contributeur ou plus. Le CVSS mesure cela avec son critère "Privileges Required".

Quelle est la vraie gravité ? Regardez le score, puis sa version. Pour CVE-2026-87902, WordPress affiche 9,2 en CVSS 4.0 quand Wordfence et la NVD, la base publique américaine des CVE, affichent 8,1 en CVSS 3.1. Même faille, deux thermomètres. Et le score décrit la faille dans l’absolu : il ignore tout de votre configuration.

D’où l’importance des conditions, souvent glissées en fin de description. Gravity Forms : un formulaire public avec envoi multiple. ACF Extended : un rôle relié à un champ. Really Simple Security : la double authentification activée. Si la condition ne s’applique pas chez vous, l’urgence baisse sans disparaître, et vous mettez à jour quand même.

Est-elle déjà exploitée ? Cherchez la mention "actively exploited", ou la CVE dans le catalogue KEV de l’agence américaine CISA, "the authoritative source of vulnerabilities that have been exploited in the wild". CVE-2026-87902 y est entrée le 25 septembre 2026, trois jours après son correctif. À ce stade, on ne planifie plus rien : on met à jour dans l’heure.

Un dernier signal se voit sans lire le moindre avis. La fiche fr.wordpress.org d’une extension fermée affiche "Cette extension est fermée depuis", suivi de la date, "et n’est pas disponible au téléchargement". La fermeture peut être temporaire ("en attente d’une revue complète", pour une fiche fermée le 31 juillet 2026) et n’est pas toujours liée à la sécurité.

Tant qu’elle dure, l’extension n’est plus téléchargeable, et Wordfence la signale dans son analyse ("when a plugin has been closed or abandoned"). Préparez un remplaçant.

Comment vérifier un plugin AVANT de l’installer

Ma base, vous la connaissez déjà : la date de la dernière mise à jour et la compatibilité avec WordPress. Si l’une des deux cloche, inutile d’aller plus loin. Si les deux passent, voici la grille complète en dix points, la base en tête, en commençant par ce que la fiche wordpress.org vous montre en deux minutes.

1. Regardez la date de la dernière mise à jour ("Dernière mise à jour" sur fr.wordpress.org). Mon vérificateur de plugins accorde tous ses points jusqu’à 60 jours, puis en retire progressivement, et plafonne à 35 sur 100 une extension restée plus de deux ans sans nouvelle version.
2. Comparez la compatibilité ("Testé jusqu’à") avec la version de WordPress en cours, 7.1.2 depuis le 22 septembre 2026. Au-delà de trois versions majeures de retard, fr.wordpress.org affiche lui-même un bandeau : "Cette extension n’a pas été testée avec plus de trois mises à jour majeures de WordPress".
3. Lisez les installations actives pour ce qu’elles sont : une mesure d’usage, pas un label de sécurité. J’ai cocréé WPS Hide Login, qui affiche plus de 2 millions d’installations actives sur wordpress.org, et ce chiffre mesure l’impact potentiel d’une faille, rien de plus. Sucuri le résume bien : "Maintenance history matters more than install count".
4. Ouvrez le forum de support et repérez la ligne "Demandes résolues ces deux derniers mois". Le 29 septembre 2026, celle de Wordfence affichait 149 sur 176. Un éditeur qui laisse les questions simples sans réponse a peu de chances de traiter vite un rapport de faille.
5. Parcourez le journal des modifications (Changelog). Un éditeur sérieux y écrit noir sur blanc qu’il corrige une faille, comme ce "Fixed Ajax Form security vulnerability" dans celui d’ACF Extended. Des versions régulières valent mieux qu’un long silence suivi d’une version fourre-tout.
6. Lisez les avis récents, surtout ceux à une étoile : ils racontent la relation entre l’éditeur et ses utilisateurs mieux que la note moyenne.

La suite demande de sortir de la fiche.

7. Cherchez l’historique de failles dans la base de Patchstack ou de WPScan. Quelques failles corrigées vite n’ont rien d’alarmant, une série au même endroit l’est davantage. Et l’absence de faille connue ne prouve rien : une extension abandonnée sans faille publiée "may simply be a plugin that has received little recent security research", note Sucuri.
8. Vérifiez que l’extension n’est pas fermée sur wordpress.org. Si c’est le cas, passez votre chemin.
9. Assurez-vous que l’éditeur est joignable : une page dédiée à la sécurité, un programme de divulgation des failles. Plus de 1 000 éditeurs ont fait de Patchstack leur point de contact sécurité, et les règles du répertoire imposent à tous des coordonnées à jour.
10. Contrôlez l’origine. La documentation officielle tranche : "Restrict yourself to the WordPress.org repository or well known companies." Jamais de version "nulled", ces copies piratées d’extensions payantes : vous n’avez aucun moyen de savoir ce qu’on y a ajouté.

Pour les extensions commerciales, le règlement européen sur la cyberrésilience (CRA) pousse dans le même sens que le point 9 : les fabricants doivent signaler les failles activement exploitées depuis le 11 septembre 2026, et ses principales obligations s’appliqueront le 11 décembre 2027.

Les points 1 à 4 et le point 7 se vérifient en quelques secondes avec le vérificateur de plugins que j’ai mis en ligne sur WPFormation. Il interroge wordpress.org et la base publique WPVulnerability, puis note l’extension sur 100 selon 13 critères (sécurité, maintenance, communauté, support), avec un grade de A à F et des alternatives.

Où trouver les failles connues d’un plugin WordPress ?

Vérifier avant d’installer ne suffit pas : un plugin sain aujourd’hui peut recevoir sa faille de sécurité demain. Il vous faut une source qui vous prévienne. Voici les principales, avec ce qu’elles couvrent et le moment où elles vous protègent, qui change selon que vous payez ou non.

Outil	Ce qu’il vérifie	Gratuit ou payant	Quand il vous protège
Patchstack Database	Failles des plugins, des thèmes et du cœur, recherche par nom	Consultation en ligne	Il vous informe, à vous d’agir
Extension Patchstack	Vos plugins, thèmes et cœur comparés à la base	Gratuite : alertes ; payante : correctifs virtuels	Gratuite : jusqu’à 48 h d’avance sur les failles de sa communauté ; payante : blocage sans attendre la mise à jour
WPScan	Base de failles WordPress, interrogeable par API	API gratuite limitée à 25 requêtes par jour	Il vous informe ; l’extension WPScan n’est plus maintenue hors entreprises
Wordfence Intelligence	Base publique des failles WordPress (cœur, plugins, thèmes), recherche par nom, API et webhooks	Gratuit, y compris pour un usage commercial	Il vous informe
Jetpack Protect	WordPress, plugins et thèmes, chaque jour, avec la base WPScan	Gratuit ; analyse des logiciels malveillants en payant	Il vous prévient
Wordfence Security	Pare-feu, fichiers modifiés, failles connues, extensions fermées ou abandonnées	Gratuit ou payant	Gratuit : règles 30 jours après les clients payants ; payant : en temps réel
NVD et catalogue KEV	Fiche officielle de chaque CVE, liste des failles exploitées	Gratuit	Ils vous informent
Sucuri SiteCheck	Votre site vu de l’extérieur : logiciels malveillants, liste noire, logiciels obsolètes	Gratuit	Constat ponctuel, sans garantie
Veille Sécurité WPFormation	Vos plugins et votre thème, chaque jour, sur les bases publiques	Gratuit, sans plugin à installer	Alerte par e-mail dans les 24 heures

Un mot sur WPScan. Sa base reste une référence, mais sa fiche wordpress.org prévient que le plugin "is no longer actively supported for non-enterprise customers" et renvoie vers Jetpack Protect.

Jetpack Protect, signé Automattic, analyse chaque jour la version de WordPress, vos extensions et vos thèmes, et vous prévient quand l’un d’eux figure dans la base de failles. L’analyse des logiciels malveillants demande la version payante.

SiteCheck, de son côté, ne voit que ce que voit un visiteur. Sucuri l’écrit en toutes lettres : "Remote scanners have limited access and results are not guaranteed". Un site propre vu de l’extérieur peut cacher une porte dérobée à l’intérieur.

Comment tester la sécurité de votre site WordPress ? Combinez un contrôle de l’intérieur et un de l’extérieur : un plugin qui compare vos versions installées aux bases de failles (Jetpack Protect, Patchstack ou Wordfence), puis SiteCheck pour ce qu’un visiteur voit. Le vérificateur de plugins, lui, juge une extension avant son installation.

La veille gratuite du tableau ne vous alerte que pour les plugins et le thème réellement installés chez vous, et je vous invite à lire comment fonctionne cette alerte gratuite par e-mail avant de vous inscrire.

Un plugin de sécurité, oui, mais lequel ?

Un seul. Deux pare-feu applicatifs qui inspectent chacun chaque requête, deux analyses programmées la nuit, deux jeux de règles de connexion qui se contredisent : empiler les plugins de sécurité ajoute de la charge et des faux positifs sans doubler la protection. Choisissez-en un et configurez-le vraiment.

Regardez surtout quand il vous protège. Chez Wordfence, les règles de pare-feu de la version gratuite arrivent après celles des offres payantes : pour Gravity Forms, les clients payants étaient couverts le 13 août 2026, les utilisateurs gratuits le 12 septembre.

Le plus riche en fonctions : pare-feu applicatif, analyse des fichiers comparés aux originaux de wordpress.org, protection de la connexion avec double authentification et clés d’accès.

L’ancienne iThemes Security, passée par le nom Solid Security. Son terrain : le durcissement et la connexion, avec double authentification (application, e-mail ou codes de secours), blocage de la force brute appuyé sur un réseau de près d’un million de sites et changement de l’adresse de connexion. L’intégration de Patchstack est réservée à la version Pro.

L’option française, rebaptisée SecuPress with Simple SSL. Son audit passe en revue 35 points de sécurité en cinq minutes et note votre site, et la version gratuite couvre la protection de la connexion et des fonctions de pare-feu. L’analyse des logiciels malveillants et la détection des extensions vulnérables sont réservées à la version Pro.

Patchstack joue un autre rôle, celui de gestionnaire de failles. La version gratuite compare vos extensions, vos thèmes et le cœur à sa base et vous alerte jusqu’à 48 heures avant la publication des failles trouvées par sa communauté. La version payante déploie des règles ciblées, uniquement quand une faille touche votre site, parmi plus de 12 000 correctifs virtuels.

Gardez la tête froide pour autant : un plugin de sécurité reste un plugin. Really Simple Security, qui affiche plus de 3 millions d’installations actives, a connu en 2024 le contournement d’authentification décrit plus haut… Moins de plugins veut aussi dire moins de code à surveiller, sécurité comprise.

Ce qu’aucun plugin de sécurité ne fera à votre place

Patchstack a testé en 2025 des défenses classiques (pare-feu applicatifs, Cloudflare…) contre des failles propres à WordPress : elles n’ont bloqué que 12 % des attaques. Une partie du travail se fait donc ailleurs, à commencer par PHP. La version 8.1 ne reçoit plus aucun correctif de sécurité depuis le 31 décembre 2025 et la 8.2 s’arrête le 31 décembre 2026 : visez 8.3, 8.4 ou 8.5.

D’autres points se règlent avec votre hébergeur : des comptes isolés les uns des autres sur un serveur partagé, des sauvegardes gardées hors du serveur et assez anciennes pour remonter avant une intrusion passée inaperçue, et, sous Nginx, la règle qui bloque PHP dans uploads.

Je vous invite aussi à couper l’éditeur de fichiers de l’administration dans wp-config.php. La documentation reste honnête sur sa portée : "This will not prevent an attacker from uploading malicious files to your site, but might stop some attacks."

define( 'DISALLOW_FILE_EDIT', true );

Ajoutez la double authentification sur les comptes administrateurs, qui rend un mot de passe volé insuffisant (tout est dans mon guide de la double authentification sur WordPress), puis déroulez la checklist pour sécuriser WordPress étape par étape pour le reste du durcissement.

La "dette de plugins" : le risque invisible

La dette de plugins s’accumule sans bruit. Un plugin installé "pour tester", un autre pour un besoin ponctuel, un autre encore remplacé mais jamais retiré… Sur les sites que j’audite en formation, je trouve régulièrement 15 à 20 plugins installés pour 6 à 8 réellement utilisés. Les autres sont autant de portes que personne ne surveille.

Désactiver ne suffit pas. Le code d’un plugin désactivé reste sur le serveur, et une faille qui passe par un fichier PHP appelé directement, sans charger WordPress, reste exploitable. La documentation officielle ne fait pas dans la nuance : "if you are not using a specific plugin, delete it from the system".

Alors désinstallez proprement chaque plugin inutile, au lieu de vous contenter du bouton Désactiver. Les plugins oubliés finissent aussi par ne plus être mis à jour, et Patchstack montre que les attaquants le savent : parmi les dix failles les plus attaquées en 2025, seules quatre avaient été publiées en 2025.

La plus visée, une XSS stockée sans authentification dans LiteSpeed Cache (versions 5.7 et antérieures), datait de 2024. Les attaques visaient de vieilles versions restées en place sur des sites mal tenus à jour. J’ai consacré un article entier au danger des plugins WordPress abandonnés, et le sujet n’a pas vieilli.

Les plugins premium achetés puis oubliés ne valent pas mieux : Patchstack a trouvé dans les composants premium trois fois plus de failles activement exploitées que dans les gratuits, et 76 % des failles qu’il y a relevées étaient exploitables. Quant aux versions "nulled", elles cumulent tout, sans mise à jour officielle et avec un code que personne ne peut garantir.

Pour faire l’inventaire sans rien oublier, la méthode d’audit de sécurité que j’applique en mission consacre un axe entier aux extensions et au thème.

Quand la mise à jour elle-même est piégée

Reste un risque que personne ne voit venir, parce qu’il arrive par la voie officielle : l’attaque de la chaîne d’approvisionnement. En juillet 2026, Advanced Responsive Video Embedder, environ 20 000 installations actives, a reçu une version 10.8.7 piégée : une empreinte figée dans le code donnait à quiconque connaissait le jeton une connexion en tant qu’administrateur (CVE-2026-18072, CVSS 9,8).

Personne n’avait mal codé quoi que ce soit. Selon la NVD, la porte dérobée "was likely introduced by an attacker who gained commit access to the developers account". L’agent PRISM de Wordfence l’a repérée moins de deux heures après son introduction, et l’équipe de wordpress.org a confirmé que cette version n’avait pas encore été distribuée aux sites.

Une faille touche un plugin installé : que faire, dans quel ordre ?

L’alerte vous concerne. Voici l’ordre que je vous recommande, du plus urgent au plus long, avec un principe simple : on ferme la porte avant de chercher qui est entré.

1. Vérifiez que vous êtes concerné : version installée contre versions touchées, puis conditions d’exploitation.
2. Si un correctif existe, mettez à jour tout de suite, sans attendre le passage automatique, puis contrôlez le numéro de version réellement installé. Wordfence le rappelait dans son alerte du 22 septembre 2026 : "Do not assume an automatic background update succeeded on every site."
3. Si aucun correctif n’existe, désactivez le plugin, puis supprimez-le si sa fonction peut attendre. S’il est indispensable, couvrez-le par une règle dédiée (correctif virtuel de Patchstack ou règle de Wordfence, en version payante) le temps que l’éditeur réagisse. Avec 46 % de failles sans correctif le jour de leur publication en 2025, ce cas n’a rien de rare.
4. Si l’extension est fermée sur wordpress.org sans perspective de retour, remplacez-la, même si elle fonctionne encore.
5. Cherchez des traces : comptes administrateurs inconnus, fichiers modifiés (l’analyse de Wordfence compare le cœur, les thèmes et les extensions aux originaux de wordpress.org), redirections suspectes. Les 20 indices d’un WordPress à risque ou déjà piraté vous serviront de liste de contrôle.
6. En cas de doute sérieux, changez tous les mots de passe (administration, base de données, hébergement), régénérez les clés de wp-config.php avec le générateur officiel de WordPress (tous les utilisateurs devront se reconnecter) et restaurez une sauvegarde antérieure à l’intrusion.
7. Notez ce qui s’est passé et branchez une alerte sur cette extension pour la prochaine fois.

Reste la question qui fâche, celle des mises à jour automatiques. Ma position tient en une phrase : "Les mises à jour automatiques de sécurité, je les applique dans tous les cas de figure." Et c’est directement natif à WordPress : depuis la version 5.5, vous les activez plugin par plugin, avec deux passages par jour qui dépendent des tâches planifiées (WP-Cron).

Patchstack mesure qu’environ la moitié des failles à fort impact sont exploitées dans les 24 heures. Attendre le week-end pour mettre à jour, dans ces conditions… Le cœur n’y échappe plus : en 2026, wp2shell et CVE-2026-87902, deux failles critiques du cœur, ont été attaquées le jour même de leur correctif.

Toutefois, les réserves existent. Le cas ARVE montre qu’une mise à jour peut, en théorie, apporter le problème au lieu de le corriger, et une boutique mérite une préproduction pour ses mises à jour de fonctionnalités. Ni l’une ni l’autre ne justifie de retarder un correctif de sécurité de plusieurs jours. Le reste est dans mon guide pour mettre à jour WordPress.

Si vous ne deviez faire qu’une chose en refermant cette page, ouvrez Extensions > Extensions installées, affichez les extensions inactives et supprimez toutes celles que vous ne réactiverez pas cette semaine. N’hésitez pas à être sévère : un plugin supprimé ne peut plus vous trahir.

Et si vous préférez qu’un professionnel surveille vos plugins en continu et applique les correctifs à votre place, mes forfaits de maintenance WordPress sont faits pour cela, à partir de 590 € HT par mois.

Questions fréquentes

Les plugins WordPress sont-ils dangereux ?

Pas par nature. wordpress.org examine chaque plugin avant de l’accepter et ferme celui qui présente une faille, mais la sécurité reste "the ultimate responsibility of the plugin developer". Le risque vient des plugins non maintenus, jamais mis à jour ou téléchargés hors des sources officielles, comme les versions "nulled".

Combien de plugins peut-on installer sans risque ?

Il n’y a pas de nombre magique : chaque plugin ajoute du code, donc une surface d’attaque. Sur les sites que j’audite en formation, je trouve régulièrement 15 à 20 plugins installés pour 6 à 8 réellement utilisés. Gardez celles qui servent, supprimez les autres.

Comment savoir si un plugin a une faille connue ?

Cherchez son nom dans la base de Patchstack ou de WPScan, ou passez-le au vérificateur de plugins de WPFormation, qui croise wordpress.org et la base WPVulnerability. Pour être prévenu à l’avenir, installez Patchstack ou Jetpack Protect, ou inscrivez vos extensions à la veille sécurité gratuite de WPFormation.

Faut-il activer les mises à jour automatiques des plugins ?

Pour les correctifs de sécurité, oui : je les applique dans tous les cas de figure, car environ la moitié des failles à fort impact sont exploitées dans les 24 heures selon Patchstack. Vérifiez qu’elles passent réellement (elles dépendent de WP-Cron) et réservez la préproduction aux mises à jour de fonctionnalités d’un site critique.

Un plugin désactivé est-il toujours un risque ?

Oui. Ses fichiers restent sur le serveur, et une faille qui passe par un fichier PHP appelé directement reste exploitable. La documentation officielle de WordPress demande de supprimer tout plugin que vous n’utilisez pas.

Quel est le meilleur plugin de sécurité WordPress ?

Celui que vous configurerez vraiment, et un seul. Wordfence est le plus riche en fonctions, Kadence Security, l’ancienne iThemes Security, mise sur le durcissement et la connexion, SecuPress with Simple SSL est l’option française, et Patchstack se concentre sur la gestion des failles.

WordPress est-il moins sécurisé que les autres CMS ?

Son cœur, non : il n’a compté que six failles de faible priorité en 2025, quand 91 % des 11 334 failles de l’écosystème touchaient des plugins. Sa part de marché (40,2 % des sites selon W3Techs, 29 septembre 2026) en fait en revanche une cible de choix. Deux failles critiques du cœur ont toutefois été corrigées en juillet et en septembre 2026.

Sources

Sources primaires lues le 29 septembre 2026. Documentation officielle et règles de publication :

• Detailed Plugin Guidelines, developer.wordpress.org (mis à jour le 11/03/2026)
• Hardening WordPress, developer.wordpress.org (mis à jour le 07/01/2026)
• Security et Nonces, Common APIs Handbook (mis à jour le 23/07/2026)
• Adding Custom Endpoints, REST API Handbook, et fiches de référence des fonctions citées sur developer.wordpress.org
• Nginx, Advanced Administration Handbook, et documentation du module core de Nginx
• unserialize() et versions de PHP maintenues, php.net
• CVSS v3.1 et CVSS v4.0, spécifications du FIRST
• Cyber Resilience Act, Commission européenne (mis à jour le 07/09/2026)

Rapports, avis et bases de failles :

• State of WordPress Security in 2026, Patchstack (25/02/2026)
• The Illusion of a Lock, blog de Sucuri (14/08/2026)
• Wordfence : avis Gravity Forms (01/09/2026), avis Avada (25/08/2026), porte dérobée d’ARVE (28/07/2026), bilan de wp2shell (20/07/2026) , alerte sur WordPress 7.1.2 (22/09/2026), rapport hebdomadaire (24/09/2026) et Wordfence Intelligence
• Fiches NVD de CVE-2026-19513, CVE-2026-18431, CVE-2026-18072, CVE-2025-14533, CVE-2024-10924 et CVE-2026-87902
• Notes de version de WordPress 7.0.2, WordPress 7.1.1 et WordPress 7.1.2, et premières tentatives sur CVE-2026-87902, Patchstack (22/09/2026)
• Known Exploited Vulnerabilities, CISA, et W3Techs pour la part de marché
• Fiches wordpress.org et API officielle des extensions citées (versions, notes, avis, installations actives), relevées le 29/09/2026