WordPress 7.1.4 est sortie le 28 octobre 2026 : c’est une version de sécurité qui corrige douze failles, dont deux signalées par Anthropic, l’éditeur de l’assistant IA Claude. Le lendemain matin, notre site WordPress de test a tenté de s’installer la mise à jour tout seul, et a échoué à mi-chemin : il est resté en 7.1.3, et WordPress ne retentera pas cette mise à jour de lui-même. Cette semaine, ouvrez Tableau de bord > Mises à jour et vérifiez que votre site affiche bien « Version actuelle : 7.1.4 ».
Ce qui a été annoncé
Le billet de WordPress.org du 28 octobre liste douze problèmes de sécurité corrigés :
- une faiblesse du processus de mise à jour qui peut mener à une exécution de code à distance pendant la mise à jour ;
- six entrées de XSS stockée (du code malveillant enregistré sur le site, puis exécuté dans le navigateur de ceux qui affichent la page), dans le balisage des blocs, l’Interactivity API, l’actualisation sélective de l’outil de personnalisation, les blocs Catégories, Playlist, Image et pagination des commentaires ;
- deux XSS stockées signalées par Anthropic : l’une passe par les demandes de suppression de données personnelles, l’autre par des identifiants d’utilisateur construits à cet effet ;
- un déni de service stocké dans l’Interactivity API ;
- des brouillons de l’outil de personnalisation trouvables sans être connecté, et des notes lisibles par des utilisateurs qui n’ont pas le droit de modifier l’article.
La version met aussi à jour les certificats racine embarqués, après la révocation de l’autorité eMudhra. Les correctifs sont reportés sur les anciennes branches encore maintenues, « jusqu’à la 4.7 » selon le billet, et WordPress 7.2 Beta 3 les contient.
Le billet crédite Anthropic, mais il ne dit pas comment les deux failles ont été trouvées. Nous n’écrirons donc pas qu’une IA les a découvertes : seul le nom du signaleur est public.
Ce que ça change pour un site WordPress
Plusieurs failles visent des écrans que tout site utilise : la liste des comptes, les demandes RGPD, les blocs d’image et de commentaires. Une boutique WooCommerce est concernée au premier chef, puisque ses clients créent eux-mêmes leur compte et donc leur identifiant.
Par défaut, WordPress installe seul les versions de maintenance et de sécurité. Beaucoup de responsables de site comptent donc sur ce mécanisme et ne vérifient plus rien. Notre test montre que cette confiance a une limite.
Notre test
Le 29 octobre 2026, nous avons ouvert notre site WordPress de test, une installation locale sous Windows (Laragon, Apache, PHP 8.3.30) qui ne sert qu’à nos essais. Avant toute manipulation, nous avons sauvegardé la base et les 3 880 fichiers du site, avec leur empreinte, pour pouvoir le remettre exactement dans son état d’origine.
Premier contrôle, la commande de vérification des fichiers du cœur :
wp core version
wp core verify-checksums
wp option get auto_core_update_failed --format=jsonElle a signalé un seul fichier modifié : wp-admin/includes/update-core.php. Il avait été remplacé le 29 octobre à 8 h 41, et son contenu était exactement celui de la version 7.1.4, alors que le site était toujours en 7.1.3. WordPress avait gardé la trace d’un échec : tentative vers 7.1.4, code d’erreur dirlist_failed_copy_dir, nouvel essai prévu false.
| Essai | Ce que nous avons observé |
|---|---|
| Vérification des fichiers du cœur avant mise à jour | 1 fichier différent : update-core.php, déjà en 7.1.4, site en 7.1.3 |
| Trace de l’échec automatique | dirlist_failed_copy_dir, retry à false, le 29/10 à 8 h 41 |
| Écran Tableau de bord > Mises à jour | Bandeau « a échoué en cours de route », bouton de mise à jour manuelle proposé |
| Clic sur « Mettre à jour vers la version 7.1.4–fr_FR » | Réussite en moins de 15 secondes, mode maintenance retiré |
| Vérification des fichiers après mise à jour | « WordPress installation verifies against checksums », trace d’échec effacée |
| Fichiers du cœur changés par la mise à jour | 50 modifiés, aucun ajouté ni supprimé |
| Site et API REST après mise à jour | Accueil et index REST en 200, capacités de l’Abilities API toujours présentes (3) |
Pourquoi le site ne se serait pas réparé seul ? Le code de WordPress l’explique. Pendant une mise à jour, WordPress copie d’abord le nouveau update-core.php, puis s’en sert pour copier le reste. Notre échec est survenu entre les deux. Ensuite, la classe Core_Upgrader refuse de relancer automatiquement la même mise à jour (de 7.1.3 vers 7.1.4) après un échec qui n’est pas classé comme passager. Seuls quatre codes d’erreur ont droit à un nouvel essai : download_failed, incompatible_archive, insane_distro et locked. dirlist_failed_copy_dir n’en fait pas partie. Le site serait donc resté en 7.1.3 jusqu’à la version suivante.
L’écran affichait pourtant « Mise à jour automatique planifiée dans 9 heures ». Ce message ne garantit rien : la tâche planifiée tourne, mais elle écarte cette version.
Les 50 fichiers modifiés correspondent aux zones citées par le billet : class-wp-interactivity-api.php, les blocs categories.php, playlist.php, image.php et comments-pagination-*.php, les listes de demandes de données personnelles, la liste des comptes et user-edit.php, customize-selective-refresh.js, le fichier de certificats ca-bundle.crt. Dans update-core.php, une seule ligne de code change : wp-config.php rejoint la liste des fichiers que la mise à jour ne doit jamais copier. Le billet ne détaille pas ses correctifs. Rattacher ce changement à la faille du processus de mise à jour est donc notre lecture, pas une information officielle.
Une fois les relevés faits, nous avons remis le site de test dans son état d’origine : la base et les 3 880 fichiers sont identiques à la sauvegarde, empreintes à l’appui. Le compte administrateur créé pour les captures n’existe plus.
Que faire cette semaine
- Vérifiez la version : Tableau de bord > Mises à jour doit afficher « Version actuelle : 7.1.4 ». Avec WP-CLI :
wp core version. Pour un site resté sur une ancienne branche, vérifiez qu’il a reçu la mise à jour de sécurité de cette branche. - Cherchez une trace d’échec : un bandeau « a échoué en cours de route » en haut de l’écran des mises à jour, ou
wp option get auto_core_update_failed. Si l’option existe et que la version n’a pas bougé, WordPress ne réessaiera pas seul. - Contrôlez les fichiers du cœur :
wp core verify-checksums. Un seul fichier différent,wp-admin/includes/update-core.php, signale une mise à jour interrompue. - Lancez la mise à jour à la main depuis Tableau de bord > Mises à jour, après une sauvegarde de la base et des fichiers. Sur une boutique WooCommerce, faites-le en dehors des heures de commande : le site passe quelques secondes en maintenance.
- Lisez l’adresse e-mail d’administration (Réglages > Général) : c’est là que WordPress envoie l’avis d’échec. Si cette boîte n’est pas lue, personne ne le voit.
Version stable publiée au 29 octobre 2026 : WordPress 7.1.4.
Limites et incertitudes
- Nous ne connaissons pas la cause de l’erreur
dirlist_failed_copy_dirsur notre installation. Elle peut tenir à notre environnement Windows local, qui n’est pas celui d’un hébergeur. Nous ne savons pas si d’autres sites ont connu le même échec. - Nous n’avons reproduit aucune des failles : nous avons vérifié la mise à jour, pas l’attaque.
- La durée de la mise à jour manuelle (moins de 15 secondes) est mesurée en local, sans trafic. Elle ne dit rien du temps de maintenance sur un hébergement réel.
- Le lien entre le changement de
update-core.phpet la faille du processus de mise à jour est notre déduction. - Le billet ne précise pas comment Anthropic a trouvé les deux failles qu’il a signalées.
Questions fréquentes
Mon site est-il à jour si je n’ai rien reçu ? Pas forcément. WordPress envoie l’avis d’échec une seule fois, à l’adresse d’administration ; notre site de test l’a noté comme envoyé. Si cette boîte n’est pas lue, il ne reste qu’un bandeau dans l’administration. Vérifiez la version affichée.
WordPress va-t-il réessayer tout seul ?
Pas pour la même version, sauf erreur passagère comme un téléchargement raté. C’est écrit dans class-core-upgrader.php.
Une IA a-t-elle trouvé ces failles ? Le billet indique seulement qu’Anthropic a signalé deux des douze failles. Il ne dit pas comment.
Comment cet article a été produit. Faits vérifiés dans le billet officiel de WordPress.org et dans le code source de WordPress ; test réalisé le 29 octobre 2026 sur notre installation locale de test (WordPress 7.1.3 vers 7.1.4, PHP 8.3.30), captures et sorties conservées, site remis à son état initial après le test. Rédigé avec l’aide de Claude (Anthropic), puis relu et validé par l’équipe Genisoft avant publication.
Sources
- WordPress.org, WordPress 7.1.4, 28 octobre 2026.
- WordPress.org, page de documentation de la version 7.1.4.
- Code source de WordPress,
update-core.phpen 7.1.4 etclass-core-upgrader.php. - Nos tests précédents sur le même site : l’Abilities API du cœur et MCP Adapter.
