WordPress 7.1.4 : 22 failles corrigées, que faire sur votre site ?

WordPress 7.1.4 est sortie le 28 octobre 2026. Elle n’apporte aucune nouveauté : c’est une version de sécurité, et la documentation officielle recommande de l’installer immédiatement.

Si vos mises à jour automatiques fonctionnent, votre site l’a probablement déjà reçue. Cela vaut quand même la peine de le vérifier, et de regarder un point que la mise à jour seule ne règle pas : l’accès au dossier wp-content/upgrade/.

La faille la plus sérieuse se joue pendant la mise à jour

Pendant une mise à jour, WordPress extrait ses fichiers dans wp-content/upgrade/. Jusqu’ici, le nom du dossier d’extraction était prévisible, et le nettoyage retirait le fichier index.php qui empêche d’en lister le contenu. Une condition de concurrence pouvait alors mener à une exécution de code à distance, sans compte et sans action de votre part.

L’analyse de Patchstack nuance le risque : l’attaquant doit viser une fenêtre de quelques secondes, et le dossier doit être accessible depuis le web. Patchstack la juge donc difficile à exploiter en pratique. Deux détails méritent pourtant votre attention :

• cette fenêtre s’ouvre à chaque mise à jour, y compris les mises à jour automatiques ;
• un pare-feu installé comme extension ne protège pas ce cas, car la copie extraite se charge indépendamment de votre site.

La version 7.1.4 rend le nom du dossier aléatoire et conserve le fichier index.php.

Les autres failles visent surtout les sites à plusieurs comptes

La plupart des autres corrections concernent des failles XSS stockées : du code malveillant enregistré dans un contenu, puis exécuté quand une autre personne l’ouvre. Elles touchent notamment l’API Interactivity, le balisage de blocs, le Customizer et les blocs de pagination.

Elles exigent presque toujours un compte existant, souvent de niveau Contributeur. Le scénario type : un contributeur prépare un article piégé, et un éditeur ou un administrateur l’ouvre.

Votre site est donc plus exposé s’il compte plusieurs rédacteurs, ou d’anciens comptes de prestataires jamais supprimés. Deux autres corrections sortent de ce schéma :

• des modifications non publiées du Customizer étaient visibles par des visiteurs sans compte ;
• un déni de service pouvait figer l’onglet du navigateur d’un visiteur, sans viser le serveur.

Quelle version devez-vous avoir ?

Seule la version la plus récente est activement prise en charge, mais les correctifs ont été reportés sur les anciennes branches :

• Branche 7.1 : 7.1.4
• Branches 7.0 et 6.9 : 7.0.8 et 6.9.11, avec les 22 corrections
• Branches 6.8 à 6.4 : 6.8.12, 6.7.11, 6.6.11, 6.5.14 et 6.4.14
• Branches plus anciennes : des correctifs existent jusqu’à la 4.7.39
• Version 4.6 et antérieures : plus aucun correctif de sécurité

Rester sur une ancienne branche corrigée reste une solution d’attente. Si votre site est bloqué sur une vieille version, par une extension ou un thème, c’est ce blocage qu’il faut traiter.

Quatre contrôles à faire maintenant

1. Confirmez la version. Dans l’administration, ouvrez Tableau de bord, puis Mises à jour. Si la version attendue n’apparaît pas, ne supposez pas que la mise à jour automatique va suivre : installez-la après avoir vérifié votre sauvegarde.

2. Bloquez l’accès web à wp-content/upgrade/. C’est la mesure que recommande Patchstack, au niveau du serveur. Voici un exemple, à adapter avec votre hébergeur.

Pour Nginx :

location ^~ /wp-content/upgrade/ {
    deny all;
}

Pour Apache, dans le fichier .htaccess à la racine du site :

RedirectMatch 403 ^/wp-content/upgrade/

Ouvrez ensuite https://votre-site.fr/wp-content/upgrade/ dans un navigateur : vous devez obtenir un refus d’accès. Entre deux mises à jour, ce dossier ne doit contenir que son index.php.

3. Faites le tri dans les comptes. Supprimez les comptes qui ne servent plus et abaissez les droits trop larges. Ce contrôle réduit l’exposition aux failles de cette version comme aux suivantes.

4. Testez ce qui compte pour votre activité. Formulaires, réservation, paiement : une version de sécurité peut aussi avoir un effet sur une extension ou un thème modifié. Notre liste de contrôle avant une mise à jour WordPress détaille cette étape.

Si quelque chose vous semble anormal

Un compte administrateur inconnu, un fichier que personne n’a déposé ou une redirection étrange ne se règlent pas par une simple mise à jour, car celle-ci ne retire pas ce qu’un attaquant aurait déjà installé. Dans ce cas, évitez de tout effacer : les traces servent à comprendre ce qui s’est passé. Notre page sur la réponse aux incidents de cybersécurité explique comment nous intervenons.

Ne plus dépendre de ces alertes

WordPress publie régulièrement ce type de correctif. Le plus sûr reste d’organiser une routine : sauvegarde vérifiée, mises à jour suivies, comptes revus et contrôle après intervention. Cette routine doit aussi couvrir le serveur : la récente faille PHP2Shell visait PHP lui-même, et mettre à jour WordPress ne suffit pas à s’en protéger.

Pour la mettre en place, découvrez notre maintenance de site WordPress, notre accompagnement WordPress en Martinique ou notre expertise de freelance WordPress. Pour un examen plus large de votre site, consultez notre page cybersécurité.

Sources : documentation de WordPress 7.1.4, annonce officielle et analyse de Patchstack.