Votre site est-il passé à WordPress 7.1.3 ?

WordPress 7.1.3 est la version de maintenance et de sécurité publiée le 6 octobre 2026. Elle contient sept correctifs de sécurité et quatre corrections de bugs. La révision de base reste 61833, la même depuis WordPress 7.1 : cette mise à jour ne change pas le schéma. Le 19 octobre, le test utile est la version affichée dans le tableau de bord. La bêta 7.2, ouverte le 20 octobre, prépare la version du 8 décembre. Elle ne tient pas lieu de 7.1.3.

Lire la version au bon endroit

Le chiffre qui compte se trouve dans Tableau de bord, puis Mises à jour. En ligne de commande, là où WP-CLI est installé :

wp core version

Une balise generator est un indice fragile : beaucoup de thèmes la retirent. Interrogée pour une 7.1.2, l’API officielle propose 7.1.3, y compris en paquet partiel, et le tableau de bord s’en sert. Le fichier version.php de cette étiquette reprend les prérequis de la branche : PHP 7.4 et MySQL 5.5.5. En dessous, l’offre ne s’applique pas.

La branche supportée, et les autres

Seule la version la plus récente est activement supportée. Le 19 octobre 2026, c’est 7.1.3. Les correctifs de sécurité ont aussi été étiquetés le 6 octobre sur les branches éligibles, par courtoisie, jusqu’à 4.7.

• 7.1.3 : les sept correctifs de sécurité et les quatre corrections de bugs.
• 7.0.7 : les sept correctifs de sécurité de la branche 7.0.
• 6.9.10 pour la branche 6.9, et 6.8.11 pour la 6.8. Le dépôt source porte un commit « WordPress 6.8.11 » daté du 6 octobre.

Une mise à jour mineure automatique reste dans sa branche : un site en 7.0 reçoit 7.0.7. Il est couvert pour cette vague, hors de la branche supportée. Le garde-fou DOM est dans 7.1.3 et absent de image.php en 7.0.7. Les branches 4.6 et antérieures sont hors de cette fenêtre.

Sept correctifs, quatre situations

L’annonce du 6 octobre, signée Jake Spurlock, nomme les sept sujets sans mode d’exploitation. Le code de l’étiquette 7.1.3 montre ce que chaque correctif change.

Les commentaires d’un article non public

Ananda Dhakal (Patchstack) a signalé une divulgation sans compte : les commentaires d’articles privés ou non publiés. Dans WP_Query de 7.1.3, le flux d’un article unique ne les charge qu’après le contrôle de visibilité. La requête ne garde que les commentaires approuvés et exclut le type note. Le cas concret est une page membre ou une annonce retirée qui avait déjà une discussion. Un visiteur déconnecté ne doit plus la lire via ce flux. Si un cache de page sert encore l’ancienne réponse, on le vide et on recontrôle en navigation privée.

Épingler un article avec le rôle Auteur

Anthropic a signalé qu’un compte Auteur pouvait épingler ses articles. Sur les rôles par défaut, il faut edit_others_posts et publish_posts. L’Auteur n’a que la seconde, et l’écran classique cachait déjà le réglage. Le contrôle trop large était dans l’API REST.

Dans 7.1.3, créer un article épinglé est refusé s’il manque l’une des deux capacités. Sur un article existant, le contrôle ne porte que sur un changement de la valeur sticky. Un Auteur peut encore enregistrer un article qu’un Éditeur a épinglé, tant qu’il ne touche pas à cet épinglage. Le lien action-sticky n’est exposé que si les deux capacités sont présentes.

if (
    isset( $request['sticky'] )
    && is_sticky( $post->ID ) !== (bool) $request['sticky']
    && (
        ! current_user_can( $post_type->cap->edit_others_posts )
        || ! current_user_can( $post_type->cap->publish_posts )
    )
) {
    // Erreur rest_cannot_assign_sticky.
}

Les articles déjà en tête de la page d’accueil y restent : l’option sticky_posts n’est pas réécrite.

Un commentaire en attente dans l’administration

Trail of Bits, avec OpenAI, a signalé un XSS stocké sur l’écran Commentaires, via un commentaire en attente. Le fichier corrigé est wp-admin/js/common.js. L’effet décrit concerne le navigateur de la personne qui modère, pas le serveur, et pas le flux public. On recharge l’écran s’il était déjà ouvert. Une Content-Security-Policy limite un script injecté ; le correctif du cœur reste nécessaire, comme le précise la note sur le nonce et le cache de page.

Imgur, l’export, les URL et les hooks

Zhengyu Liu, Jingcheng Yang et Gavin Zhong ont signalé un XSS via les intégrations Imgur. Depuis WordPress 3.9, Imgur était un fournisseur oEmbed de confiance : son HTML était inséré tel quel, alors que les autres adresses sont réduites à une iframe isolée. L’étiquette 7.1.3 retire Imgur dans class-wp-oembed.php. Une nouvelle intégration n’est plus insérée sans filtre.

Deux signalements d’Anthropic supposent déjà un accès. Dans export.php, l’export WXR relisait _thumbnail_id. Ces valeurs passent maintenant par absint(), pour couper une injection SQL de second ordre portée par une méta déjà en base. Le chemin est celui de l’export filtré qui ajoute les images à la une, lancé par un administrateur. WP_Http::make_absolute_url() normalise une URL relative : dans 7.1.3, la boucle s’arrête si un passage ne remplace plus rien. L’annonce parle d’un déni de service, sans décrire la requête.

Alex Concha, de l’équipe sécurité, a signalé une collision sur le hook {status}_{type}. wp_transition_post_status() fabrique des noms comme publish_post à partir du statut et du type. Dans 7.1.3, ces hooks ne partent que si les deux sont enregistrés. Une extension qui envoyait une chaîne libre à wp_insert_post() se reteste à la publication, à la dépublication et à la mise à la corbeille.

Quatre corrections qui ne sont pas des failles

• L’icône du site dans la barre d’administration, ajoutée en 7.1, pouvait prendre la taille du fichier si un thème forçait les images. Le sélecteur img.site-icon impose 20 pixels de côté, et 28 pixels sous 782 pixels de large.
• wp_get_image_alttext(), ajoutée en 7.0, appelait DOMDocument sans tester l’extension. Dans 7.1.3, l’absence de la classe renvoie un texte vide et le téléversement continue. Ce garde-fou n’est pas dans 7.0.7. L’extension DOM reste recommandée : Santé du site signale les modules recommandés manquants.
• ReverbNation pointe vers legacy.reverbnation.com. Someecards et some.ly, en panne, sont retirés : ces liens restent des liens.

Ce que la mise à jour laisse en cache

Retirer Imgur ne vide pas le HTML déjà stocké. WP_Embed le garde dans la méta _oembed_ suivie d’une empreinte, avec l’heure dans _oembed_time_. Le filtre oembed_ttl vaut par défaut un jour. Pendant ce délai, WordPress ressert le cache. Le type oembed_cache et un cache de page peuvent aller plus loin. On réenregistre l’article, ou on attend le délai, puis on purge. Une image Imgur rangée dans la médiathèque n’est pas un oEmbed.

WordPress 7.1.3 retire Imgur des fournisseurs de confiance. Il ne réécrit pas les métas _oembed_ déjà enregistrées. Le délai par défaut est d’un jour, et un cache de page peut le dépasser.

Pourquoi un site affiche encore 7.1.2

Depuis WordPress 3.7, les mises à jour mineures de sécurité sont actives par défaut. Une 7.1.2 encore affichée le 19 octobre a une cause locale.

• WP_AUTO_UPDATE_CORE vaut false, ou AUTOMATIC_UPDATER_DISABLED vaut true.
• Le filtre allow_minor_auto_core_updates renvoie faux.
• DISALLOW_FILE_MODS interdit l’écriture, ou les fichiers ne sont pas inscriptibles.
• Un dépôt Git ou SVN à la racine désactive l’arrière-plan, sauf filtre contraire.
• DISABLE_WP_CRON est défini et aucun cron système n’appelle wp-cron.php.
• PHP est inférieur à 7.4.

Santé du site nomme la constante ou le filtre qui bloque les mises à jour mineures. Un hébergeur peut appliquer le paquet plus tard : on lit le tableau de bord.

Le 20 octobre ouvre la bêta 7.2

Le calendrier de make.wordpress.org place la bêta 1 au 20 octobre 2026, la RC1 au 17 novembre et la finale au 8 décembre. Justin Tadlock, le 14 octobre, demande de rattraper les mises à jour de sécurité avant ce test. Le thème prévu s’appelle Ipsum. L’édition collaborative n’est pas au programme, et React 19 a peu de chances d’entrer dans la finale. La bêta s’essaie sur une copie. Le site public reste sur 7.1.3.

Questions fréquentes

7.0.7 suffit-elle le 19 octobre 2026 ?

Elle porte les sept correctifs de sécurité de la branche 7.0, pas le garde-fou DOM, et elle n’est pas la version supportée. Passer à 7.1.3 est une mise à jour majeure : sauvegarde, copie d’essai, puis mise à jour.

Faut-il migrer la base ?

Non. $wp_db_version vaut 61833 de 7.1 à 7.1.3. L’étape de base affichée par l’écran Mises à jour ne change pas le schéma. Une sauvegarde reste utile si l’on met à jour à la main.

Un embed Imgur disparaît-il dès la mise à jour ?

Le HTML en cache peut rester un jour, davantage si une extension allonge oembed_ttl ou si un cache de page sert l’ancienne page. On réenregistre, puis on purge. Le fichier de la médiathèque n’est pas concerné.

Un Auteur peut-il encore modifier un article épinglé ?

Oui, s’il en est l’auteur et s’il ne change pas l’épinglage. Le refus rest_cannot_assign_sticky porte sur ce changement. Le retirer demande les deux capacités : Éditeur ou Administrateur, sur les rôles par défaut.

La bêta du 20 octobre contient-elle déjà ces correctifs ?

La branche de développement les contient. Un site public se met à jour vers 7.1.3. La bêta se teste sur une copie, avec les extensions réellement utilisées.

Santé du site bloque les mises à jour mineures. Que faire ?

On lit la constante ou le filtre cités. Le bouton du tableau de bord fonctionne encore si les fichiers sont inscriptibles et si PHP est au moins en 7.4, même quand l’arrière-plan est coupé.

Le HTML, le CSS et Sass se travaillent pas à pas dans la section Apprentissage. Les notes ponctuelles, comme celle-ci, restent sur le blog. Pour un site WordPress, la page Me contacter est le bon point d’entrée.