WordPress a publié le 6 octobre 2026 la version 7.1.3, une mise à jour de maintenance et de sécurité qui corrige sept failles dans le cœur du CMS. C’est la troisième version de sécurité en moins de trois semaines. Si votre site ne se met pas à jour tout seul, c’est le moment de passer par le tableau de bord.
Plan de l'article
Que contient WordPress 7.1.3 ? #
L’annonce publiée sur WordPress.org est courte : la version apporte 7 correctifs de sécurité et 4 corrections de bugs. Parce qu’il s’agit d’une version de sécurité, l’équipe du projet écrit qu’il est recommandé de mettre à jour ses sites immédiatement.
À lire Anthropic (Claude) en route vers la Bourse : jusqu’à 2 000 milliards de dollars en jeu
Les sites qui acceptent les mises à jour automatiques en arrière-plan la reçoivent sans intervention. Pour les autres, la manipulation reste la même : menu « Mises à jour » du tableau de bord, puis « Mettre à jour maintenant ».
Cette version arrive après WordPress 7.1.1 du 17 septembre et WordPress 7.1.2 du 22 septembre. Le site allemand Dr. Web parle de la troisième version de sécurité en 19 jours, la 7.1.2 ayant été un correctif d’urgence.
Les sept failles corrigées, une par une #
WordPress.org liste les failles avec le nom de ceux qui les ont signalées. Patchstack, société spécialisée dans la sécurité WordPress, a publié le même jour une analyse détaillée qui précise, pour chacune, ce qu’il faut à un attaquant pour s’en servir. C’est ce point qui permet de juger le risque réel pour votre site.
Une XSS stockée dans l’écran des commentaires
Un commentaire en attente de modération pouvait contenir du code malveillant exécuté dans l’administration. D’après Patchstack, il faut qu’un modérateur, de niveau éditeur ou plus, clique sur un lien contenu dans ce commentaire. La faille a été signalée par Trail of Bits, en collaboration avec OpenAI selon WordPress.org.
Trois failles signalées par Anthropic
La première est un déni de service dans la fonction WP_Http::make_absolute_url(), qui demande un compte contributeur ou plus. La deuxième est une injection SQL « de second ordre » dans l’export WXR, l’outil qui exporte le contenu du site : elle ne se déclenche que si un administrateur lance un export et qu’une valeur piégée se trouve déjà en base. La troisième permettait à un auteur de mettre des articles en avant (« sticky »), ce qui est normalement réservé aux rôles supérieurs.
Des commentaires privés visibles sans connexion
C’est la seule faille qui ne demande rien à l’attaquant : un visiteur non connecté pouvait voir les commentaires d’articles privés ou non publiés. Elle a été signalée par Ananda Dhakal, de Patchstack.
Les intégrations Imgur et un hook trop permissif
Les intégrations d’images Imgur étaient vulnérables à une XSS, exploitable avec un compte contributeur. Enfin, des paramètres falsifiables passés au hook {status}_{type} pouvaient provoquer une collision de noms d’action. Patchstack précise que ce dernier cas dépend d’une extension qui transmet un statut ou un type de contenu brut à wp_insert_post().
Faut-il s’inquiéter ? #
Patchstack résume la situation sans dramatiser : cette version « n’est pas une urgence où il faut tout lâcher », mais il faut mettre à jour dès que possible. L’article ne fait état d’aucune exploitation constatée, et aucun identifiant CVE n’est attribué à ces sept correctifs.
Le vrai risque dépend de votre site. Un blog tenu par une seule personne, sans inscription ouverte, est peu exposé aux failles qui demandent un compte contributeur. Un site multi-auteurs, un média avec des rédacteurs invités ou un site qui accepte les inscriptions l’est davantage.
Ce qu’il faut faire après la mise à jour #
Patchstack donne deux conseils qui vont au-delà du simple clic sur « Mettre à jour ».
Vider le cache. Le correctif Imgur ne supprime pas les intégrations déjà mises en cache par WordPress. Un contenu piégé enregistré avant la mise à jour peut donc continuer à s’afficher tant que le cache n’est pas purgé. Pensez au cache de votre extension et, le cas échéant, à celui de votre hébergeur ou de votre CDN.
Faire le tri dans les comptes. Plusieurs failles concernent ce que peuvent faire les contributeurs et les auteurs. C’est l’occasion de passer en revue la liste des utilisateurs, de supprimer les comptes inactifs et de vérifier que chacun a le rôle le plus bas possible pour son travail.
Et les anciennes versions ?
WordPress.org indique que les correctifs sont reportés, quand c’est nécessaire, sur toutes les branches qui reçoivent encore des correctifs de sécurité, c’est-à-dire jusqu’à la 4.7. Ces reports sortent au fur et à mesure. Au moment de son analyse, Patchstack notait qu’ils étaient disponibles au moins jusqu’à la branche 6.6, et pas encore pour les branches 4.7 à 6.5. Le projet rappelle surtout que seule la dernière version est activement maintenue : rester sur une vieille branche n’est pas une stratégie.
Questions fréquentes #
Comment savoir si mon site est déjà en 7.1.3 ?
Le numéro de version s’affiche en bas à droite de chaque page de l’administration, et dans le menu « Tableau de bord », puis « Mises à jour ». Si vous voyez 7.1.3, le correctif est en place.
La mise à jour peut-elle casser mon site ?
Une version de maintenance comme celle-ci ne change pas de fonctionnalités, le risque est donc faible. Une sauvegarde avant de mettre à jour reste une bonne habitude, surtout si votre thème ou vos extensions modifient le fonctionnement des commentaires ou des intégrations.
Dois-je aussi mettre à jour mes extensions ?
Ces failles concernent le cœur de WordPress. Les extensions ont leurs propres mises à jour, à faire séparément depuis le même écran.
