WordPress 7.1.1 est sorti le 17 septembre 2026, une version de maintenance et de sécurité. L’annonce officielle de WordPress.org porte une recommandation qu’on ne voit pas sur chaque version mineure : parce qu’il s’agit d’une version de sécurité, une mise à jour immédiate est recommandée. Cette fois, aucune faille unique ne fait la une, et aucun CVE n’est associé à un correctif. C’est différent de la chaîne de prise de contrôle pré-authentification derrière XSS2Shell, ou de la faille du cœur activement exploitée que nous avions couverte avec wp2shell. Cette version regroupe 11 correctifs de sécurité distincts, aux côtés de 17 correctifs du cœur et 19 correctifs de l’éditeur de blocs ; les correctifs de sécurité sont rétroportés jusqu’à la dernière branche encore éligible aux correctifs de sécurité, soit la branche 4.7. Allons voir ensemble ce que contient réellement ce lot.
Ce qui est sorti, et pourquoi une « version de sécurité » n’est pas une faille unique
D’après l’annonce officielle de WordPress.org, la 7.1.1 est une version de maintenance et de sécurité, pas une version de fonctionnalités : la 7.1 avait déjà livré ses nouveautés en août. Cette version mineure ne change donc aucun comportement visible, en dehors des correctifs eux-mêmes. Aucun des 11 correctifs de sécurité ne porte de numéro CVE ni de niveau de gravité publié, ce qui est habituel pour une version de sécurité WordPress de routine, à la différence de la faille unique, nommée et notée, qui avait fait la singularité de XSS2Shell ou de wp2shell. L’absence de CVE n’est pas un signe de correctifs mineurs : elle signifie simplement que WordPress.org considère la mise à jour elle-même comme l’information à retenir, plutôt qu’un score de gravité.
La portée du rétroportage compte plus que le nombre affiché en titre. Les correctifs de sécurité de la 7.1.1 remontent jusqu’à la branche 4.7, sortie pour la première fois en décembre 2016. N’importe quel site tournant encore sur une ancienne branche activement maintenue reçoit donc la même protection qu’un site sur la toute dernière version. Tout ce qui est antérieur à la 4.7 reste hors de ce filet de sécurité, sans recours officiel possible, puisque WordPress ne publie plus aucun correctif de sécurité pour ces branches.
Les 11 correctifs, regroupés selon ce qu’ils touchent réellement
Onze correctifs, cela peut sembler beaucoup pour une seule version. Ils se répartissent pourtant en quatre groupes distincts, et savoir à quel groupe appartient un correctif donné en dit plus long que le chiffre brut.
Trois touchent le cross-site scripting (injection de script). La fonction wpautop(), que WordPress utilise pour transformer les sauts de ligne en paragraphes, laissait un visiteur non authentifié injecter un script stocké via un commentaire en attente de modération, un bug crédité à Rafie Muhammad, d’Awesome Motive. Un bug voisin dans l’API HTML laissait des séquences forgées, refermées de façon abrupte, sortir des limites attendues d’un commentaire, signalé par Jeremy Felt, membre de la Security Team de WordPress, qui a également signalé le troisième : une XSS stockée accessible via certains thèmes prenant en charge les en-têtes personnalisés.
Deux sont des fuites d’information, à la portée plus étroite : un contrôle de capacité manquant exposait le titre d’un article parent privé via les métadonnées de l’écran d’administration, signalé par HDWSec, et une faille similaire permettait à un compte de niveau Contributeur de voir le slug d’un article en brouillon ou en attente qui ne lui appartenait pas, signalé par Jakub Herman.
Quatre sont des contournements d’autorisation, répartis entre le cœur, l’API REST et l’ancienne interface XML-RPC. Une faille de traversée de répertoires authentifiée dans le contrôleur de modèles de l’API REST, ainsi qu’un bug distinct permettant à un compte de niveau Contributeur d’écraser un article arbitraire, ont tous deux été signalés par Anthropic, un point que la section suivante détaille à part. Ben Bidner, membre de la Security Team de WordPress, a signalé une méthode permettant à XML-RPC de publier un article de type customize_changeset en contournant la vérification de la capacité edit_css qui aurait dû s’appliquer. Un quatrième bug, signalé par Justin Hart, de Viridis Security, permettait à tout utilisateur authentifié de changer le parent de commentaires qui ne lui appartenaient pas.
Les deux derniers sortent de ces catégories. Des URL spécialement forgées pouvaient déclencher l’installation et la prévisualisation automatiques d’un thème inactif, directement depuis WordPress.org, signalé par Paulos Yibelo et pwn.ai, le même chercheur et la même plateforme à l’origine de XSS2Shell. Et sur un réseau multisite, un administrateur de site pouvait activer, à l’échelle du réseau, une extension réservée au réseau qu’un administrateur ordinaire avait installée : une faille de permissions créditée à Jesse McNeil.
Le détail que la plupart des relais vont manquer : deux correctifs sur onze viennent d’Anthropic
Au-delà du simple journal des modifications, un détail se distingue, qu’un résumé « 11 correctifs de sécurité » ne fait pas apparaître : deux d’entre eux, la faille de traversée de répertoires de l’API REST et le bug d’écrasement d’article arbitraire, sont tous deux crédités à Anthropic, et non à un chercheur indépendant ou à un membre de la Security Team de WordPress. L’annonce de WordPress.org traite ce crédit exactement comme celui de n’importe quel autre nom de la liste : associé à un correctif, sans commentaire particulier.
Cela mérite d’être noté pour ce que c’est, sans en faire une histoire plus grande qu’elle ne l’est. Qu’un laboratoire d’IA audite un logiciel open source grand public à la recherche de failles de sécurité, puis signale ce qu’il trouve par le canal de divulgation habituel de WordPress plutôt que de l’annoncer séparément, est quelque chose de plus discret et de plus banal qu’un titre du genre « une IA trouve un piratage ». Ce constat rejoint la plateforme de recherche de pwn.ai, créditée ailleurs dans cette même version pour le bug de prévisualisation de thème, comme un second exemple de recherche automatisée ou assistée par IA apparaissant cette année dans le flux de sécurité ordinaire de WordPress. Deux crédits sur onze n’en font pas pour autant une version « sécurité IA » : les neuf autres viennent du mélange habituel de chercheurs indépendants et de la Security Team de WordPress elle-même, et c’est ce mélange qui fait toujours l’essentiel du travail.
Êtes-vous protégé ? La vérification pratique
Confirmer que vous êtes couvert prend moins de temps que la lecture de cette section. Ouvrez votre tableau de bord WordPress, puis Mises à jour, ou vérifiez le numéro de version affiché en bas de la plupart des écrans d’administration : 7.1.1 ou une version plus récente signifie que LE correctif est déjà appliqué. Si vous voyez un numéro plus ancien sans mise à jour en attente, les mises à jour automatiques en arrière-plan sont soit désactivées, soit en échec silencieux, ce qui mérite d’être vérifié directement plutôt que supposé.
Les mises à jour automatiques couvrent par défaut les versions de sécurité du cœur chez la plupart des hébergeurs, mais trois situations vous en excluent discrètement : une extension de sécurité ou un réglage côté hébergeur qui les désactive, un site figé sur une branche antérieure à la 4.7 que WordPress ne corrige plus du tout, et un hébergement géré où c’est l’hébergeur, pas WordPress, qui pilote le calendrier des mises à jour. Si l’une de ces situations correspond à votre cas, une mise à jour manuelle, depuis Tableau de bord, puis Mises à jour, puis Mettre à jour maintenant, prend moins d’une minute. Si vous gérez un site pour un client ou un employeur, c’est le bon moment pour confirmer par écrit que les mises à jour de sécurité automatiques sont réellement activées, et non simplement supposées l’être.
Notre avis
Une version de sécurité sans CVE ni niveau de gravité individuel peut donner l’impression d’un non-événement. Pour la plupart des sites tournant sur une branche activement maintenue, c’est en grande partie le cas : onze bugs disparates, corrigés de la même façon que WordPress en corrige des dizaines de semblables chaque année. Ce qui mérite d’être retenu n’est pas tel ou tel correctif pris isolément, mais la portée du rétroportage et la liste des rapporteurs. Une protection est ainsi étendue jusqu’à une branche datant de 2016, et deux crédits sur onze reviennent à un laboratoire d’IA qui fait le même travail de sécurité, peu glorieux et sans titre accrocheur, qui permet à une base de code vieille d’une décennie de rester aussi bien maintenue.
Voici ce que cela signifie concrètement, selon votre situation :
- Si votre tableau de bord affiche déjà la 7.1.1 ou une version plus récente, vous êtes couvert : aucune action nécessaire.
- Si vous voyez une version plus ancienne sans mise à jour en attente, mettez à jour à la main dès aujourd’hui, depuis Tableau de bord, puis Mises à jour, puis Mettre à jour maintenant.
- Si vous gérez un site pour un client ou un employeur, confirmez par écrit que les mises à jour de sécurité automatiques sont réellement activées, et pas seulement supposées l’être.
- Si votre site tourne encore sur une branche antérieure à la 4.7, prenez cette version comme le déclic pour enfin le faire évoluer : cette branche est désormais définitivement hors de la couverture de sécurité de WordPress.
Nous avions couvert la version que corrige cette mise à jour, WordPress 7.1, plus en détail, si vous n’avez pas encore franchi le pas. Mettez à jour, vérifiez que vous êtes réellement en 7.1.1, et reprenez la gestion de votre site.
