L'essentiel à retenir : l'immense majorité des piratages WordPress remontent à un petit ensemble de vulnérabilités bien connues — plugins et thèmes obsolètes, identifiants admin faibles, injection SQL dans du code vulnérable, cross-site scripting, et points d'accès XML-RPC exposés — chacune avec une solution précise et connue plutôt qu'une vague recommandation d'"améliorer la sécurité".
Pourquoi WordPress est une cible si courante
WordPress fait fonctionner une grande part de tous les sites web — W3Techs le suit constamment à plus de 40% de l'ensemble du web depuis plusieurs années. Cette échelle est exactement la raison pour laquelle il est ciblé : une seule vulnérabilité découverte dans un plugin populaire peut potentiellement être exploitée sur des dizaines de milliers de sites utilisant encore la version vulnérable, ce qui rend les attaques automatisées de scan massif rentables pour un attaquant d'une manière qu'un site sur mesure justifie rarement.
C'est un contexte important car cela recadre correctement le problème : le cœur de WordPress lui-même n'est pas le point faible dans la plupart des attaques. C'est l'écosystème de plugins et de thèmes autour de lui, ainsi que des choix de configuration basiques qui relèvent entièrement du contrôle du propriétaire du site.
Plugins et thèmes obsolètes
La recherche en sécurité constate systématiquement que les plugins et thèmes obsolètes avec des vulnérabilités publiquement divulguées constituent le plus grand vecteur d'attaque unique pour les compromissions WordPress — loin devant les vulnérabilités du cœur ou les attaques ciblées et sur mesure. Une fois qu'une vulnérabilité est divulguée publiquement (même quand un correctif est déjà publié), des scanners automatisés commencent à sonder le web à la recherche de sites utilisant encore la version vulnérable en quelques heures.
La solution est simple mais demande de la discipline : activez les mises à jour automatiques pour les plugins et thèmes quand c'est possible, supprimez tout plugin qui n'est plus activement maintenu (vérifiez sa date de "dernière mise à jour" dans l'annuaire de plugins WordPress), et vérifiez l'historique des vulnérabilités des nouveaux plugins avant de les installer via une base de données comme la base de vulnérabilités de WPScan.
Identifiants admin faibles ou réutilisés
Les tentatives de connexion par force brute contre wp-login.php constituent un bruit de fond constant sur le web — des bots automatisés essaient des combinaisons courantes de nom d'utilisateur/mot de passe contre chaque site WordPress qu'ils trouvent, et un mot de passe faible ou réutilisé transforme ce bruit de fond en une véritable intrusion.
La solution : imposez des mots de passe forts et uniques pour chaque compte admin, activez l'authentification à deux facteurs, renommez ou restreignez l'accès au nom d'utilisateur "admin" par défaut s'il est encore utilisé, et limitez les tentatives de connexion pour ralentir les outils de force brute automatisés.
Injection SQL dans des plugins vulnérables
L'injection SQL permet à un attaquant de manipuler une requête de base de données via le propre champ de saisie d'un plugin — un formulaire de contact, une barre de recherche, un paramètre d'URL — qui ne nettoie pas correctement ce qui y est saisi, exposant ou modifiant potentiellement toute la base de données WordPress, y compris les identifiants des utilisateurs.
La solution est largement la même que pour les plugins obsolètes : les vulnérabilités d'injection SQL se trouvent presque toujours dans des versions spécifiques de plugins et sont corrigées rapidement une fois signalées, donc rester à jour sur les mises à jour ferme la grande majorité de ces failles avant même qu'elles ne soient exploitées sur un site donné.
Cross-Site Scripting (XSS)
Le XSS permet à un attaquant d'injecter du JavaScript malveillant dans une page via un champ de saisie non nettoyé, qui s'exécute ensuite dans le navigateur de quiconque visite cette page — pouvant potentiellement voler les cookies de session admin ou rediriger les visiteurs vers un site malveillant. Les champs de commentaires, les formulaires de contact et les réglages de plugins qui n'échappent pas la saisie utilisateur sont les points d'entrée les plus courants.
La solution : la même discipline de mise à jour s'applique, car les vulnérabilités XSS sont typiquement spécifiques à un plugin et corrigées rapidement ; un pare-feu applicatif web (inclus dans de nombreux plugins de sécurité) ajoute une couche capable de bloquer des motifs d'injection XSS connus avant même qu'un correctif soit appliqué.
Abus de XML-RPC
L'interface XML-RPC de WordPress, conçue à l'origine pour des outils de publication à distance, est devenue un vecteur courant pour deux attaques spécifiques : les tentatives de connexion par force brute acheminées via la méthode pingback pour échapper à la limitation de débit normale, et l'utilisation du point d'accès XML-RPC d'un site comme amplificateur dans des attaques DDoS contre d'autres cibles.
La solution : désactivez entièrement XML-RPC sauf si le site dépend activement d'un plugin (le plus souvent Jetpack) ou d'une application mobile qui le nécessite — pour la plupart des sites, cela ferme une surface d'attaque sans inconvénient fonctionnel.
Permissions de fichiers non sécurisées
Des permissions de fichiers et dossiers trop permissives — souvent laissées à leur valeur par défaut ou assouplies pendant un dépannage puis jamais réinitialisées — permettent à un attaquant ayant obtenu un point d'ancrage sur le serveur de modifier les fichiers du cœur, d'installer une porte dérobée, ou de lire des données de configuration sensibles comme les identifiants de base de données dans wp-config.php.
La solution : la documentation officielle de WordPress recommande 644 pour les fichiers et 755 pour les répertoires comme base sécurisée, wp-config.php devant idéalement être encore plus verrouillé puisqu'il contient directement les identifiants de base de données.
Tableau de référence rapide
| Vulnérabilité | Point d'entrée courant | Solution principale |
|---|---|---|
| Plugins/thèmes obsolètes | CVE connues et divulguées | Activer les mises à jour auto, supprimer les plugins non maintenus |
| Identifiants admin faibles | Force brute sur wp-login.php | Mots de passe forts, 2FA, limitation des tentatives |
| Injection SQL | Champs de saisie de plugin non nettoyés | Maintenir les plugins à jour avec les versions corrigées |
| Cross-site scripting (XSS) | Champs de commentaire/formulaire de contact | Mettre à jour les plugins, utiliser un pare-feu applicatif web |
| Abus de XML-RPC | Force brute par pingback, relais DDoS | Désactiver XML-RPC si non activement nécessaire |
| Permissions de fichiers non sécurisées | Mauvaise configuration au niveau serveur | 644 pour les fichiers, 755 pour les répertoires |
Une checklist pratique de durcissement
- Mettre tout à jour selon un calendrier, pas de manière réactive — cœur de WordPress, chaque plugin et le thème actif, idéalement avec les mises à jour automatiques activées pour les versions mineures.
- Supprimer entièrement les plugins et thèmes inutilisés, pas seulement les désactiver — un plugin inactif mais installé avec une vulnérabilité connue peut toujours être exploité dans certaines chaînes d'attaque.
- Imposer l'authentification à deux facteurs pour chaque compte ayant un accès de publication ou d'administration, pas seulement le compte admin principal.
- Désactiver XML-RPC sauf si une intégration spécifique et activement utilisée le requiert.
- Tester les changements de sécurité d'abord sur une copie de staging, car des étapes de durcissement comme les changements de permissions ou la désactivation de fonctionnalités peuvent occasionnellement casser un plugin qui en dépend.
Rester informé des nouvelles vulnérabilités
Des bases de données de vulnérabilités comme WPScan et Patchstack suivent les vulnérabilités WordPress de plugins et thèmes nouvellement divulguées au fur et à mesure de leur publication, et de nombreux plugins de sécurité puisent dans ces mêmes sources pour alerter les propriétaires de sites quand un plugin installé a un problème connu. S'abonner à l'un de ces flux, plutôt que d'attendre de remarquer un problème après coup, fait la différence entre corriger dans les heures suivant la divulgation et corriger après qu'un scanner automatisé a déjà trouvé la faille.
Erreurs courantes menant à une compromission
- Supposer qu'un plugin de sécurité seul suffit, alors qu'il ne peut pas corriger rétroactivement une vulnérabilité connue dans un logiciel obsolète toujours actif sur le site.
- Désactiver plutôt que supprimer les plugins inutilisés, laissant du code connu comme vulnérable présent sur le serveur même s'il ne tourne pas activement.
- Réutiliser le même mot de passe admin sur plusieurs sites clients, transformant un seul identifiant divulgué en compromission multi-sites.
- Ignorer le durcissement des permissions de fichiers parce que c'est perçu comme une tâche de configuration ponctuelle plutôt qu'un élément de maintenance récurrent.
- Restaurer une ancienne sauvegarde sans vérifier si elle restaure aussi une vulnérabilité depuis corrigée, annulant une correction précédente sans s'en rendre compte.
En résumé
En bref, les vulnérabilités qui compromettent réellement les sites WordPress forment un ensemble bien documenté et prévisible — surtout les plugins et thèmes obsolètes, plus les identifiants faibles, l'injection SQL, le XSS, l'abus de XML-RPC et les permissions de fichiers laxistes — chacune avec une solution précise et connue plutôt qu'un vague appel à "être plus sécurisé". Des mises à jour cohérentes et une poignée d'étapes de durcissement concrètes ferment l'immense majorité des attaques réelles, exactement le travail de scan et de documentation que notre plugin Erdo CRA Compliance est conçu pour aider à suivre, aux côtés d'exigences de conformité européennes plus larges.