Les trois failles de sécurité WordPress que je retrouve sur 9 sites repris sur 10

Quand je récupère un site WordPress pour en assurer la maintenance, je commence toujours par un scan de sécurité. C'est devenu un réflexe. Je fais d'ailleurs ce même scan quand je prospecte à froid une entreprise dont le site WordPress me semble à l'abandon : ça me donne un état des lieux factuel à partager, et ça ouvre souvent la conversation.

Pour donner un ordre d'idée, j'ai cumulé un peu plus de cent sites WordPress scannés en prospection ces derniers mois. Les chiffres anonymisés que j'en tire :

• Près d'un site sur deux tourne avec un page builder lourd (Elementor, Divi, WPBakery) dont la version installée date de trois à cinq ans, donc avec des vulnérabilités publiques connues.
• Plus d'un site sur dix mentionne au moins une CVE exploitable explicitement nommée dans le rapport de scan.
• Une poignée de sites tournent encore sur une version majeure de WordPress qui a deux ans ou plus de retard, dont un cas extrême à sept ans (WordPress 4.9), antérieur à Gutenberg.
• Quelques cas utilisent une version de PHP qui n'est plus supportée par la fondation PHP, donc qui ne reçoit plus de correctifs de sécurité.

Dans les deux contextes (reprise et prospection), à chaque fois ou presque, je retrouve les trois mêmes erreurs. Trois, pas un chiffre rond pour faire joli. Trois parce que ce sont vraiment celles qui reviennent le plus souvent, et qui exposent le plus le site.

Ce n'est pas un article pour pointer du doigt. C'est un article pour aider les propriétaires de sites à comprendre où regarder, et pour rassurer ceux qui se demandent si leur site est solide ou pas.

---

Erreur 1 — La page de connexion accessible à tout le monde

Par défaut, sur n'importe quel WordPress, on accède à l'administration via /wp-login.php ou /wp-admin. Tout le monde le sait. Les robots aussi.

Concrètement, ça veut dire que des scripts automatisés passent leur temps à essayer de deviner les identifiants administrateurs sur cette URL. Si un mot de passe est faible, c'est une question de jours avant que le site se fasse compromettre. Pas de semaines, de jours.

Ce que je mets en place

Trois couches successives, pas une seule.

D'abord renommer la page de connexion : l'URL d'admin ne ressemble plus à /wp-login.php, et les robots qui scannent au hasard ne trouvent rien. SecuPress et quelques autres plugins le font en deux clics.

Ensuite limiter les tentatives : au bout de quelques essais ratés, l'adresse IP est bloquée pour une durée donnée. Fini les attaques par force brute.

Enfin l'authentification à deux facteurs sur les comptes administrateurs. Même si un mot de passe fuite, un attaquant a besoin du code envoyé sur le téléphone du vrai propriétaire pour entrer.

Renommer seul ne suffit pas. Limiter seul ne suffit pas. Les trois ensemble rendent la page de connexion quasiment imprenable sans un effort très ciblé, qui n'a aucun intérêt sur un site TPE.

Encore faut-il qu'il n'y ait pas une erreur humaine derrière. Un mot de passe « azerty », « 12345 » ou le prénom du chien sur le compte admin, et tout l'empilage tombe : l'attaquant tape juste, du premier coup, et entre. Le triptyque ci-dessus renforce le système, mais il ne corrige pas une mauvaise hygiène de mot de passe. Un gestionnaire (Bitwarden, 1Password, KeePass, Dashlane) et un mot de passe aléatoire de 16 caractères minimum sur les comptes administrateurs, c'est la dernière brique, et c'est gratuit dans les offres de base.

---

Erreur 2 — Le compte administrateur s'appelle « admin »

Quand on crée un site WordPress aujourd'hui, on choisit librement le nom de l'administrateur. Mais jusqu'à WordPress 3.7 fin 2013, l'identifiant pré-rempli à l'installation était... « admin ». Et tous les sites créés avant cette époque qui n'ont jamais renommé leur compte d'origine traînent encore ce nom. Ça représente une bonne partie du parc que je reprends.

Pourquoi c'est un problème ? Parce qu'un attaquant qui veut tenter une attaque par force brute commence toujours par essayer les identifiants évidents : admin, administrator, le nom de domaine, le prénom du gérant. Si le compte s'appelle admin, il a déjà la moitié de la combinaison. Il ne lui reste qu'à trouver le mot de passe.

Ce que je fais

Le correctif n'est pas compliqué, mais il demande un accès à la base de données et un peu de méthode. Surtout, jamais de UPDATE en aveugle : on commence par identifier précisément l'ID du compte concerné, puis on met à jour en ciblant cet ID, pour éviter de renommer plusieurs comptes par mégarde si d'autres utilisateurs portaient le même identifiant.

-- 1. Repérer l'ID du compte
SELECT ID, user_login, user_nicename FROM wp_users WHERE user_login = 'admin';

-- 2. Mettre à jour la table principale (remplacer 1 par l'ID retourné)
UPDATE wp_users
   SET user_login = 'identifiant-non-devinable',
       user_nicename = 'identifiant-non-devinable'
 WHERE ID = 1;

-- 3. Synchroniser le surnom visible dans le profil
UPDATE wp_usermeta
   SET meta_value = 'identifiant-non-devinable'
 WHERE user_id = 1 AND meta_key = 'nickname';

Sur une installation multisite, la table wp_sitemeta est aussi concernée. Et un backup avant manipulation reste obligatoire.

Ça prend une minute pour un développeur. Pour un client, mieux vaut demander à un prestataire de le faire correctement, parce qu'une fausse manipulation en base peut casser le site.

Variante plus simple côté interface : créer un nouveau compte administrateur avec un identifiant non devinable, lui réaffecter le contenu de l'ancien, puis supprimer le compte admin. C'est plus long, mais ça ne demande pas de toucher à la base.

---

Erreur 3 — Des plugins qui n'ont pas été mis à jour depuis dix-huit mois

La troisième est la plus répandue, et la plus dangereuse.

Sur les sites repris, je trouve régulièrement des plugins dont la dernière mise à jour remonte à plus d'un an. Parfois trois ans. Parfois jamais.

Le problème n'est pas tellement que le plugin soit « vieux ». Le problème est que pendant ces dix-huit mois, des failles de sécurité ont été découvertes publiquement. Elles sont référencées dans des bases comme WPScan ou Patchstack, avec un identifiant CVE, une description précise, et un niveau de risque coté. Dans de nombreux cas, un exploit fonctionnel finit aussi par circuler sur des dépôts spécialisés (Exploit-DB, GitHub).

Concrètement : un attaquant n'a plus besoin de chercher la faille, elle est documentée. Il lui suffit de scanner internet à la recherche de sites WordPress utilisant cette version vulnérable, et d'envoyer la charge. C'est entièrement automatisé.

Selon le rapport annuel de Patchstack sur la sécurité WordPress (édition 2025, portant sur l'année 2024), 96 % des vulnérabilités découvertes concernaient des plugins tiers, et non le cœur de WordPress. Wordfence arrive au même chiffre dans son propre rapport 2024. Et 35 % des vulnérabilités divulguées en 2024 n'avaient toujours pas reçu de correctif au moment de la publication du rapport Wordfence au printemps 2025, faute de mise à jour appliquée sur les sites concernés.

Autrement dit : ce n'est pas WordPress qui est dangereux. Ce sont les plugins laissés à l'abandon.

Ce que je fais

Pour chaque plugin actif sur le site, je vérifie qu'il est encore activement maintenu (date de dernière mise à jour sur le répertoire WordPress), je liste les vulnérabilités connues sur sa version actuelle via WPScan, je mets à jour vers la dernière version stable. Si le plugin est abandonné par son auteur, je lui trouve un remplaçant et je fais la bascule proprement.

C'est exactement le travail qu'une TMA récurrente fait chaque mois. Sans contrat de maintenance, ces vérifications n'arrivent pas, et la dette de sécurité s'accumule mois après mois.

---

Et après ?

Ces trois erreurs sont la majorité de ce que je rencontre. Il y en a d'autres, plus rares ou plus subtiles (permissions de fichiers mal réglées, identifiants de connexion à la base laissés en clair, options de débogage activées en production, etc.). Mais sur un site TPE, ces trois-là couvrent l'essentiel du risque.

Si vous voulez savoir où en est votre site WordPress sans engagement, je propose un audit de sécurité gratuit : je scanne votre site, je liste les vulnérabilités connues sur les plugins installés, je vous dis honnêtement si la situation est urgente ou pas, et je vous transmets le rapport.

Si le résultat montre qu'une remise à niveau s'impose, on peut enchaîner sur un contrat de maintenance WordPress mensuel : mises à jour testées avant déploiement, sauvegardes vérifiées, alertes en cas de nouvelle vulnérabilité publiée sur un plugin que vous utilisez. Le tarif dépend de la criticité du site et du nombre de plugins, le chiffrage est détaillé dans un autre article.

Pas pour faire peur. Juste qu'un site WordPress laissé sans surveillance pendant un an a de très grandes chances de s'être fait compromettre sans que personne ne s'en aperçoive. Et le constat arrive en général quand c'est déjà trop tard.

Vous voulez savoir où en est votre site WordPress ? Écrivez-moi en quelques lignes avec l'URL de votre site, je vous renvoie un rapport de scan gratuit sous quelques jours.