Le 28 octobre 2026, WordPress a publié sa version 7.1.4. Cette version de sécurité apporte douze corrections. L’une fermait une faille du processus de mise à jour lui-même. Pendant une mise à jour, un pirate pouvait exécuter son propre code sur le serveur.
Même le cœur du logiciel, le mieux surveillé, avait donc une porte à fermer. Sur les sites qui acceptent les mises à jour automatiques, elle s’est fermée sans que personne n’intervienne.
Les extensions de ces mêmes sites, elles, attendent souvent qu’une personne lance leur mise à jour. C’est pourtant là que se logent presque toutes les failles. Selon l’éditeur de sécurité Patchstack, 91 % de celles découvertes en 2025 se trouvaient dans des extensions.
Nous maintenons des sites WordPress, et nous en avons remis en état après un piratage. Une extension de sécurité ne suffit pas : c’est une alarme, et une alarme ne ferme aucune porte. Voici les portes que nous fermons d’abord, dans l’ordre, et ce que vous pouvez faire vous-même.
Le cœur de WordPress est verrouillé, ses annexes beaucoup moins
Le cœur de WordPress, c’est le logiciel lui-même, celui que l’on télécharge sur WordPress.org. En 2025, Patchstack n’y a relevé que six failles, toutes de faible gravité. Une équipe de sécurité le surveille. Et ses correctifs mineurs s’installent seuls depuis la version 3.7, sortie en 2013.
Les extensions et les thèmes viennent de milliers d’auteurs, qui travaillent chacun à leur rythme. Patchstack a recensé 11 334 failles en 2025 : environ 91 % touchaient des extensions et 9 % des thèmes. Près de la moitié n’avaient encore aucun correctif au moment d’être rendues publiques.
Nous avons vu ce que cela donne chez une PME qui vend du matériel médical. Un jour, ses clients ont été redirigés vers des sites pornographiques. Google a suspendu ses annonces et signalé un problème de sécurité. Le propriétaire, lui, ne voyait rien : le code malveillant épargnait les administrateurs.
La porte d’entrée était une extension d’administration de base de données, pas mise à jour depuis des années. Les pirates avaient ensuite créé quatre comptes administrateurs pour pouvoir revenir. Le site avait bien une extension de sécurité. Personne ne l’avait jamais réglée correctement.
La première porte à fermer est donc la plus simple : ce qui ne sert plus. Une extension désactivée reste installée, et ses fichiers restent sur le serveur. La documentation de WordPress est claire : une extension inutilisée se supprime.
Pour les autres, ouvrez leur fiche sur WordPress.org. La date de dernière mise à jour et la dernière version de WordPress testée disent si quelqu’un s’en occupe encore. Payer ne protège pas davantage. En 2025, 29 % des failles signalées à Patchstack touchaient des extensions ou des thèmes payants, ou en partie payants.
Et pour un usage précis, une extension écrite sur mesure ajoute moins de code tiers qu’un empilement d’extensions génériques.
Une faille publiée se joue en quelques heures
Quand une faille devient publique, la course commence. Patchstack a mesuré le délai avant les premières tentatives d’attaque sur les failles les plus visées de 2025. Il est de cinq heures, en médiane pondérée. Ce calcul donne plus de poids aux failles les plus attaquées.
Et environ la moitié des failles à fort impact sont exploitées dans les 24 heures. « Les 24 premières heures sont critiques quand une nouvelle faille exploitable est publiée », écrit Patchstack (notre traduction).
Les mises à jour automatiques servent à réduire ce délai. Depuis la version 5.5, WordPress peut mettre à jour seul chaque extension et chaque thème. Encore faut-il les activer, dans Extensions > Extensions installées. Dans la colonne « Mises à jour automatiques », cliquez sur « Activer les mises à jour auto ». Le menu « Actions groupées » le fait pour plusieurs extensions d’un coup.
Pour les thèmes, le même lien figure sur la fiche de chaque thème, dans Apparence > Thèmes. WordPress lance ensuite ces mises à jour deux fois par jour, et vous prévient par e-mail.
Elles ne règlent pas tout. Entre deux passages, jusqu’à douze heures peuvent s’écouler. Et WordPress attend une visite pour lancer ses tâches : sur un site peu fréquenté, l’attente s’allonge. Surtout, WordPress n’installe qu’un correctif publié. Or 46 % des failles n’en avaient pas au moment d’être rendues publiques.
Pour cette fenêtre, il faut un pare-feu applicatif : un filtre qui examine chaque requête avant qu’elle n’atteigne WordPress. C’est le vrai rôle d’une extension de sécurité, à condition de la régler.
Le pare-feu de l’hébergeur ne suffit pas toujours. Patchstack, qui vend sa propre protection, a testé les protections des hébergeurs. Leurs défenses habituelles n’ont bloqué que 12 % des attaques visant des failles WordPress. Sur un test élargi à des failles plus génériques, la part monte à 26 %.
Une réserve : sur une boutique, une mise à jour peut casser la page de commande. Nous testons alors chaque mise à jour sur une copie du site avant de l’appliquer. Sur un site vitrine, attendre coûte en général plus cher que le risque de casse.
Chaque compte administrateur est une clé de plus
Un compte administrateur peut tout faire : installer une extension, modifier un fichier, créer d’autres comptes. Chez notre client du matériel médical, ce sont ces comptes que les pirates avaient multipliés.
Ouvrez Comptes dans l’administration, puis filtrez sur le rôle « Administrateur/administratrice ». Chaque nom doit correspondre à une personne qui en a besoin aujourd’hui. L’ancien prestataire, le stagiaire parti, le compte de test : on les supprime. Pour rédiger des articles, un rôle d’auteur ou d’éditeur suffit.
Un bon mot de passe reste indispensable, mais il ne suffit plus. Il peut fuir, se deviner ou servir sur plusieurs sites. La documentation de WordPress recommande d’y ajouter une double authentification. Après le mot de passe, la connexion demande un code à usage unique, affiché par une application sur votre téléphone.
L’extension Two Factor, publiée par les contributeurs de WordPress.org, l’ajoute à votre site. Plus de 100 000 sites l’utilisent. Elle propose une application d’authentification, des codes envoyés par e-mail et des codes de récupération à garder hors ligne. Les robots qui essaient des milliers de mots de passe continuent de frapper à la porte. Mais le mot de passe seul ne suffit plus à entrer.
Une fois l’extension activée, la liste des comptes gagne une colonne « Two-Factor ». Elle compte, car la protection ne vaut que pour les comptes qui l’ont mise en place. Vous voyez d’un coup d’œil qui doit encore le faire.
Fermez aussi les portes de service
WordPress intègre un éditeur de fichiers. Avec un thème en blocs, il se trouve dans Outils, sinon dans Apparence et Extensions. Il modifie directement le code PHP des thèmes et des extensions. La documentation de WordPress y voit souvent le premier outil d’un pirate qui a réussi à se connecter.
Une ligne dans le fichier de configuration, wp-config.php, le fait disparaître : define( 'DISALLOW_FILE_EDIT', true );. Placez-la au-dessus de la ligne « C’est tout, ne touchez pas à ce qui suit ! ». La documentation prévient qu’elle n’empêche pas l’envoi de fichiers malveillants. C’est une porte de moins, pas un blindage.
Le serveur a lui aussi ses portes. La première est la version de PHP, le langage qui fait tourner WordPress. Une version qui ne reçoit plus de correctifs garde ses failles ouvertes. PHP 8.1 n’en reçoit plus, et la 8.2 cessera d’en recevoir le 31 décembre 2026.
WordPress recommande la 8.3 ou une version plus récente. Visez plutôt la 8.4 ou la 8.5. En octobre 2026, ce sont les deux seules qui reçoivent encore des corrections de bogues. La 8.3 n’a déjà plus que des correctifs de sécurité.
Outils > Santé du site affiche la version utilisée. Elle se change en général depuis l’espace client de l’hébergeur. S’il ne propose rien de récent, changez d’hébergeur. Dans tous les cas, testez vos extensions avant de changer de version.
Vous lirez ailleurs qu’il faut changer le préfixe des tables de la base de données. La documentation de WordPress range ce genre d’astuce dans la « sécurité par l’obscurité ». Utile en complément, elle reste peu solide comme stratégie principale. Cacher une porte ne la ferme pas.
Prévoyez le jour où c’est vous qui restez dehors
Une sauvegarde ne vaut que si elle se restaure. Notre client du matériel médical n’en avait aucune de récente qui fonctionne. Il en faut une automatique, quotidienne, stockée hors du serveur du site. Restaurez-la de temps en temps sur une copie, pour vérifier qu’elle marche.
Vérifiez aussi deux adresses e-mail. Celle de votre compte reçoit les liens de réinitialisation du mot de passe. Celle de l’administration du site se règle dans Réglages > Général. Depuis la version 5.2, WordPress y envoie un lien de secours quand une extension fait planter le site.
Notez enfin, hors du site, vos accès à l’hébergement : espace client, FTP (l’accès aux fichiers) et base de données. Si le mot de passe ne revient pas, ce sont eux qui vous font rentrer.
Avec un accès SSH, une connexion au serveur en ligne de commande, l’outil WP-CLI génère un nouveau mot de passe. La commande wp user reset-password admin --skip-email --porcelain l’affiche, sans rien envoyer par e-mail. Remplacez admin par votre identifiant.
Sans SSH, passez par phpMyAdmin, l’outil de gestion de base de données que proposent la plupart des hébergeurs. Dans la table des utilisateurs, souvent nommée wp_users, modifiez le champ user_pass. Saisissez le nouveau mot de passe avec la fonction MD5, un ancien calcul d’empreinte. WordPress l’accepte, puis le réenregistre dès la connexion sous une forme bien plus difficile à casser. Depuis la version 6.8, c’est l’algorithme bcrypt.
Gardez vos codes de récupération de double authentification au même endroit que ces accès. Si le site a déjà été piraté, changer les mots de passe ne suffit plus. Il faut trouver la porte d’entrée, nettoyer, puis demander un réexamen à Google.
Ce que vous pouvez vérifier vous-même cette semaine
Aucune de ces mesures ne rend un site invulnérable. La documentation de WordPress le dit elle-même : « la sécurité, c’est réduire le risque, pas l’éliminer » (notre traduction). Voici cinq contrôles pour le réduire, dans cet ordre.
Dans Outils > Santé du site, lisez les recommandations : version de PHP, HTTPS, thèmes inactifs, mises à jour en attente.
Dans Extensions > Extensions installées, supprimez ce qui est désactivé. Pour le reste, vérifiez la fiche de chaque extension. Puis activez les mises à jour automatiques là où personne ne les teste avant.
Dans Comptes, filtrez les administrateurs. Supprimez les inconnus et les anciens, puis activez la double authentification pour ceux qui restent.
Dans wp-config.php, ajoutez la ligne qui coupe l’éditeur de fichiers, ou demandez-le à la personne qui gère votre site.
Enfin, restaurez votre dernière sauvegarde sur une copie. Ouvrez aussi le rapport « Problèmes de sécurité » de la Search Console. Google y signale ce qu’il a détecté sur votre site.
Si ces contrôles révèlent du retard, c’est le quotidien de nos contrats de maintenance. Ils comprennent les mises à jour testées avant d’être appliquées, les sauvegardes quotidiennes hors serveur, le pare-feu et la surveillance. Le premier diagnostic est gratuit. Et si votre site a déjà été touché, écrivez-nous : nous intervenons aussi en urgence.
Commentaires