WordPress 7.1.1 : 11 failles corrigées, quatrième mise à jour de sécurité du cœur en deux mois

WordPress 7.1.1 : ce que corrige la mise à jour du 17 septembre 2026

L'équipe WordPress a publié la version 7.1.1 le 17 septembre 2026. C'est une version de maintenance et de sécurité à cycle court : 17 corrections dans le cœur, 19 dans l'éditeur de blocs et 11 corrections de sécurité. La prochaine version majeure, la 7.2, est prévue en décembre. Comme pour toute version de sécurité, WordPress recommande de mettre à jour immédiatement ; les sites qui acceptent les mises à jour automatiques en arrière-plan se mettent à jour seuls.

Voici les 11 failles corrigées, telles que l'annonce officielle les décrit, avec le niveau d'accès nécessaire pour les exploiter. C'est ce dernier critère qui compte pour décider de l'urgence sur un site donné.

Faille corrigée dans la 7.1.1	Accès requis	Signalée par
XSS stocké dans wpautop() : un visiteur non connecté peut injecter un script, sous réserve d'approbation du commentaire	Aucun (commentaire à approuver)	Rafie Muhammad (Awesome Motive)
API HTML : set_modifiable_text() permet de sortir d'un commentaire HTML par une séquence de fermeture abrupte	Selon le contexte d'appel	Jeremy Felt (équipe sécurité WordPress)
XSS stocké dans certains thèmes qui gèrent les en-têtes personnalisés	Selon le thème	Jeremy Felt
Des URL spécialement construites peuvent installer et prévisualiser automatiquement un thème inactif depuis WordPress.org	Lien piégé	Paulos Yibelo et pwn.ai
Un administrateur de site peut activer sur tout le réseau une extension réservée au réseau (multisite)	Administrateur de site	Jesse McNeil
Traversée de répertoire authentifiée dans le contrôleur REST des modèles (templates)	Authentifié	Anthropic
XML-RPC permet de publier des customize_changeset qui contournent le contrôle edit_css	Authentifié, via XML-RPC	Ben Bidner (équipe sécurité WordPress)
Écrasement arbitraire d'articles par un contributeur ou plus	Contributeur	Anthropic
Contrôle read_post manquant dans attachment_submitbox_metadata() : fuite du titre d'un article parent privé	Authentifié	HDWSec
Autorisation manquante : divulgation du slug des brouillons et articles en attente à un contributeur	Contributeur	Jakub Herman
Les commentaires, notes comprises, peuvent être rattachés à un autre parent par tout utilisateur authentifié	Authentifié	Justin Hart (Viridis Security)

Aucune de ces failles n'est présentée comme exploitée, et aucune ne donne à un inconnu la main sur le site sans condition. Plusieurs concernent les sites qui ouvrent des comptes à des tiers (contributeurs, auteurs, membres) ou qui gardent XML-RPC actif. Le premier point de la liste mérite l'attention des sites à commentaires : l'injection passe par un commentaire, mais elle ne se déclenche qu'une fois le commentaire approuvé. Un modérateur qui approuve vite un commentaire d'apparence anodine peut donc activer le script.

Un été à quatre versions de sécurité : 7.0.2, 7.0.3, 7.0.4 puis 7.1.1

La 7.1.1 s'inscrit dans une séquence inhabituelle. Entre le 17 juillet et le 17 septembre 2026, le cœur de WordPress a reçu quatre versions de sécurité, dont une avec mise à jour forcée. Si vous gérez plusieurs sites, c'est la liste à vérifier.

Version	Date	Ce qu'elle corrige	Gravité pratique
7.0.2	17 juillet 2026	Une injection SQL « facilitée » dans WP_Query (CVE-2026-60137) et une confusion de routes dans le point de terminaison REST /batch/v1 (CVE-2026-63030). Chaînées, elles donnent une injection SQL sans authentification, que WordPress et le chercheur classent en exécution de code à distance	Critique. Mise à jour forcée par WordPress.org. Patchstack a vu des tentatives d'exploitation dans ses journaux
7.0.3	6 août 2026	12 correctifs : XSS réfléchi sur l'écran de connexion, sans authentification, « avec un potentiel d'exécution de code PHP » ; escalade de privilèges sur les réseaux multisite à inscription ouverte ; SSRF vers les plages link-local ; contournement de la confirmation d'adresse email ; plusieurs XSS stockés au niveau contributeur	Élevée, surtout pour les multisites et les sites à inscription ouverte
7.0.4	12 août 2026	Exécution de code à distance par un auteur ou plus, via l'envoi d'un fichier malveillant, sur les serveurs où ImageMagick est relié à Ghostscript (CVE-2026-65640)	Élevée pour les sites multi-auteurs ; présente dans le cœur depuis la 4.7
7.1.1	17 septembre 2026	11 correctifs, voir le tableau plus haut	Modérée à élevée selon les comptes ouverts et XML-RPC

Version 7.0.2 : la faille qui a justifié une mise à jour forcée

L'analyse de Patchstack, publiée le jour de la sortie, décrit une chaîne en deux étages. Le premier est une faille de WP_Query : quand le paramètre author__not_in arrive sous forme de chaîne et non de tableau, la conversion en entiers est sautée et la valeur brute est concaténée dans la clause SQL. Ce défaut existe depuis la 6.8 mais n'est normalement pas atteignable, car l'API REST valide author_exclude comme un tableau d'entiers. Le second étage, apparu avec la 6.9, est une désynchronisation d'index dans le traitement des requêtes groupées de /batch/v1 : une sous-requête invalide décale les correspondances, si bien qu'une requête est validée par un gestionnaire et exécutée par un autre. C'est ce décalage qui laisse passer une valeur non validée jusqu'à l'injection.

Patchstack a vérifié de son côté que la chaîne mène à la prise de contrôle complète du site, a vu des tentatives dans ses journaux, et a conseillé de « passer en revue les utilisateurs que vous ne reconnaissez pas ». La 7.0.2 a été poussée en mise à jour forcée sur les sites touchés ; les branches 6.9 et 6.8 ont reçu les 6.9.5 et 6.8.6. Les versions antérieures à la 6.8 ne sont pas concernées.

Version 7.0.4 : un PNG qui n'en est pas un

La 7.0.4 corrige une seule faille, CVE-2026-65640, signalée par l'équipe pwn.ai. Le mécanisme est ancien : ImageMagick identifie un fichier par son contenu, pas par son extension, et sait ouvrir du PostScript, qu'il confie à Ghostscript. Un fichier nommé .png mais contenant du PostScript passait les contrôles de WordPress, arrivait à Imagick, et Ghostscript l'exécutait comme un programme. Le contrôle habituel des types de fichiers aurait bloqué l'envoi depuis la médiathèque, mais deux chemins l'évitent, d'après l'analyse de Patchstack rapportée par webhosting.today : la méthode XML-RPC wp.uploadFile et l'extraction de la pochette des fichiers MP3. Il faut un compte auteur ou plus, et un serveur où ImageMagick est relié à Ghostscript. Sur un site de publication à plusieurs auteurs ou un site d'adhérents, ces deux conditions sont souvent réunies.

Que faire sur vos sites, dans l'ordre

Vérifier la version installée

Dans le tableau de bord, la version est indiquée en bas à droite et dans « Tableau de bord, Mises à jour ». En ligne de commande, sur chaque site :

wp core version
wp core check-update

Pour un parc, un relevé automatique évite d'oublier un site. Tout ce qui affiche 7.1.0, 7.0.x ou une branche 6.x sans les rétroportages du jour doit passer en 7.1.1. Notre guide pour mettre à jour WordPress sans casser le site détaille la sauvegarde préalable et le test.

Vérifier que les mises à jour automatiques fonctionnent

Un site qui est encore en 7.0.1 aujourd'hui n'a pas reçu la mise à jour forcée du 17 juillet : c'est le signe que le mécanisme est cassé, par une constante dans wp-config.php, un filtre dans une extension, un dossier non inscriptible ou une tâche cron qui ne tourne pas. Vérifiez :

grep -nE "AUTOMATIC_UPDATER_DISABLED|WP_AUTO_UPDATE_CORE|DISALLOW_FILE_MODS" wp-config.php
wp option get auto_update_core_minor
wp cron event list | grep -i update

DISALLOW_FILE_MODS bloque aussi les mises à jour automatiques : si vous l'avez activée pour empêcher l'installation d'extensions depuis l'administration, vos mises à jour de sécurité doivent alors passer par votre propre processus de déploiement, sans exception.

Si un site est resté vulnérable cet été

Pour un site qui a tourné en 7.0.1 ou moins après le 17 juillet, ou en 7.0.3 ou moins avec ImageMagick et des comptes auteurs, la mise à jour ne suffit pas : il faut vérifier qu'il n'a pas été exploité entre-temps.

1. Listez les comptes et leurs rôles ; supprimez tout administrateur inconnu, voir notre article sur l'administrateur inconnu apparu dans WordPress.
2. Cherchez dans les journaux d'accès de juillet et août des requêtes vers /wp-json/batch/v1, en particulier des POST répétés.
3. Cherchez des fichiers PHP dans wp-content/uploads et des fichiers modifiés hors mise à jour, avec une surveillance d'intégrité des fichiers ou un simple find sur les dates.
4. Renouvelez les clés de sécurité de wp-config.php et les mots de passe administrateur.

grep -E "wp-json/batch/v1" /var/log/nginx/access.log* | awk '{print $1}' | sort | uniq -c | sort -rn | head
find wp-content/uploads -name "*.php" -newermt "2026-07-17"

Réduire la surface : XML-RPC et rôles

Deux des failles de cet été passent par XML-RPC (la publication de customize_changeset dans la 7.1.1, l'envoi de fichier wp.uploadFile dans la 7.0.4). Si rien sur le site n'utilise ce protocole, ni l'application mobile, ni Jetpack, ni un outil de publication à distance, désactivez-le : voir désactiver XML-RPC sur WordPress. De même, sept des onze failles de la 7.1.1 demandent un compte sur le site, du simple abonné au contributeur : la gestion des rôles et permissions reste la protection la plus efficace contre cette catégorie, en donnant à chaque personne le rôle minimal et en fermant les comptes inutilisés.

Ce que révèle la liste des chercheurs

Un détail de l'annonce mérite d'être relevé : parmi les personnes remerciées figurent des systèmes d'intelligence artificielle. Deux des onze failles de la 7.1.1 sont créditées à Anthropic, une troisième est signalée par Paulos Yibelo avec pwn.ai ; la 7.0.3 comptait déjà un signalement d'Anthropic et deux de pwn.ai, et la 7.0.4 vient entièrement de pwn.ai. Du côté des extensions, Wordfence attribue à son agent de recherche Argus les failles critiques récentes de The Events Calendar et de Tutor LMS.

Ce n'est pas anecdotique pour un propriétaire de site : ces outils relisent du code ancien à une vitesse que les chercheurs humains n'avaient pas. La faille de la 7.0.4 était présente depuis la 4.7, soit près de dix ans. Il faut s'attendre à ce que le rythme des versions de sécurité reste élevé dans les mois qui viennent, dans le cœur comme dans les extensions. La bonne réponse n'est pas de s'inquiéter à chaque annonce, mais d'avoir un processus qui absorbe une mise à jour de sécurité par semaine sans effort : sauvegarde automatique, mises à jour automatiques activées et contrôlées, relevé de version, et une liste de contrôle de sécurité revue à chaque trimestre.

Sources

• WordPress.org, Aaron Jorbin, « WordPress 7.1.1 Maintenance and Security Release », 17 septembre 2026, wordpress.org
• WordPress.org, John Blackbourn, « WordPress 7.0.4 Release », 12 août 2026, wordpress.org
• WordPress.org, John Blackbourn, « WordPress 7.0.3 release », 6 août 2026, wordpress.org
• WordPress.org, John Blackbourn, « WordPress 7.0.2 Release », 17 juillet 2026, wordpress.org
• Patchstack, Chazz Wolcott, « Unauthenticated SQL Injection in WordPress Core Fixed in 7.0.2 », 17 juillet 2026, patchstack.com
• webhosting.today, Natalia Nowak, « WordPress 7.0.4 Fixes a PNG That Runs Code. The Flaw Was Almost 10 Years Old. », 13 août 2026, webhosting.today