WordPress 7.1.4 est disponible depuis le 28 octobre 2026. Cette nouvelle version du CMS corrige 22 vulnérabilités de sécurité, notamment plusieurs failles de type XSS stocké, des problèmes de permissions et une condition de concurrence dans le mécanisme de mise à jour pouvant mener à une exécution de code à distance (RCE). Si vous administrez un site WordPress, une boutique WooCommerce ou plusieurs installations clientes, cette mise à jour mérite une intervention prioritaire.
Il ne s’agit pas d’une version apportant de nouvelles fonctionnalités : l’objectif de WordPress 7.1.4 est de réduire la surface d’attaque du cœur WordPress. Le projet recommande officiellement de mettre à jour les sites immédiatement.
WordPress 7.1.4 : les informations essentielles
| Version | WordPress 7.1.4 |
|---|---|
| Date de sortie | 28 octobre 2026 |
| Type | Mise à jour de sécurité |
| Correctifs | 22 vulnérabilités recensées par WordPress |
| Priorité | Élevée : mise à jour recommandée immédiatement |
| Prochaine version majeure | WordPress 7.2, prévue en décembre 2026 |
Les détails proviennent de l’annonce officielle de WordPress et de la documentation de la version 7.1.4. Le décompte des vulnérabilités et leurs conditions d’exploitation sont également analysés par Patchstack.
Quelles failles de sécurité WordPress 7.1.4 corrige-t-il ?
Les problèmes corrigés touchent plusieurs composants distincts. Ils n’ont pas tous la même gravité ni les mêmes prérequis. Beaucoup exigent un compte WordPress disposant au moins du rôle Contributeur ; d’autres concernent la divulgation d’informations ou les permissions internes. Une faille liée aux mises à jour présente toutefois un scénario d’attaque nettement différent.
1. Exécution de code à distance pendant une mise à jour du cœur
Le correctif le plus préoccupant concerne une condition de concurrence (race condition) durant la mise à jour de WordPress. Dans certaines circonstances, cette faiblesse peut être exploitée pour exécuter du code à distance sans disposer d’un compte sur le site.
Il faut néanmoins préciser les conditions de l’attaque. Selon l’analyse de Patchstack, l’attaquant doit atteindre une fenêtre temporelle très courte, pendant l’exécution d’une mise à jour, et le répertoire wp-content/upgrade/ doit être accessible depuis le Web. Le scénario est donc contraint, mais son impact potentiel justifie pleinement le correctif.
La mise à jour ne remplace pas les précautions habituelles : droits d’accès minimaux, protection des répertoires temporaires et surveillance des modifications inattendues sur le système de fichiers. Évitez surtout de considérer le filtrage WAF comme un substitut au correctif du cœur.
2. Plusieurs failles XSS stocké dans l’éditeur de blocs
WordPress corrige des injections de scripts persistantes, notamment par des délimiteurs de blocs comportant des espaces inhabituels et par certains libellés de blocs. Une vulnérabilité XSS stockée permet de placer une charge malveillante dans une donnée enregistrée, puis de la faire exécuter dans le navigateur d’une personne qui consulte ou édite cette donnée.
Les blocs Categories, Comments Pagination et Post Navigation Link figurent parmi les éléments concernés. Pour plusieurs scénarios, l’attaquant doit posséder au moins les privilèges d’un Contributeur.
Sur les sites éditoriaux comptant plusieurs rédacteurs ou acceptant des contributions externes, le niveau de privilèges requis ne doit pas être sous-estimé : il suffit parfois d’un compte compromis ou d’un auteur insuffisamment fiable pour préparer une attaque contre une personne disposant de droits supérieurs.
3. L’Interactivity API concentre plusieurs correctifs
L’Interactivity API, qui permet de créer des interfaces WordPress interactives côté navigateur, fait l’objet de nombreux correctifs. Ils concernent notamment les liaisons de données (bindings), les gestionnaires d’événements, les espaces de noms du contexte et le routeur interactif.
Les problèmes signalés comprennent des XSS stockés, un déni de service stocké, des URL javascript: dangereuses dans certains bindings et des scénarios impliquant la pollution de prototype. La version corrige également un cas dans lequel du contenu d’article peut masquer des données de module JavaScript utilisant le même identifiant HTML.
Pour les développeurs de thèmes et d’extensions, c’est un rappel utile : une donnée introduite dans le balisage de blocs doit rester non fiable, même lorsqu’elle transite par une API officielle. L’échappement, la validation, l’attribution des capacités et les tests sur des contenus adversariaux restent indispensables.
4. Fuites d’informations et contrôles d’accès insuffisants
D’autres correctifs empêchent des visiteurs non authentifiés de découvrir certaines modifications non publiées du Customizer. Ils corrigent également l’accès aux notes attachées aux publications : des rôles personnalisés autorisés à modérer les commentaires pouvaient accéder à des notes sur des articles qu’ils ne pouvaient pourtant pas modifier.
Le cœur renforce par ailleurs la gestion des noms d’utilisateurs dans certaines interfaces du réseau multisite et corrige des problèmes de sécurité liés aux demandes d’effacement des données personnelles.
5. Blocs Image et Playlist, certificats racines
Des mesures de durcissement touchent les remplacements de chaînes effectués par preg_replace() dans les blocs Image et Playlist. La distribution actualise également ses certificats racines intégrés à la suite de la révocation d’eMudhra.
Ce dernier point n’est pas une vulnérabilité XSS supplémentaire : il relève de la confiance accordée aux certificats et de la sécurité des connexions TLS utilisant le magasin de certificats fourni avec WordPress.
Toutes les installations WordPress sont-elles vulnérables ?
La version exacte du cœur constitue le premier critère. WordPress précise que WordPress 7.0 et 6.9 étaient affectés par les 22 vulnérabilités, tandis que les branches plus anciennes n’étaient concernées que par une partie des problèmes, selon les fonctionnalités présentes et les changements introduits au fil des versions.
Des correctifs sont proposés pour plusieurs branches historiques. Par exemple, les versions 7.0.8, 6.9.11, 6.8.12 et 6.7.11 incluent les correctifs applicables à leurs branches respectives. Certaines branches remontent jusqu’à WordPress 4.7, mais WordPress 4.6 et les versions antérieures ne reçoivent plus de mises à jour de sécurité.
La disponibilité de rétroportages ne doit pas être confondue avec une maintenance complète : WordPress rappelle que seule la version la plus récente bénéficie d’un support actif. Si une installation ancienne ne peut pas migrer immédiatement, installez au minimum le correctif de sécurité correspondant à sa branche, puis planifiez la mise à niveau vers une version actuelle.
Comment mettre à jour WordPress 7.1.4 en sécurité ?
Sur un site simple, l’interface d’administration suffit : ouvrez Tableau de bord → Mises à jour et installez WordPress 7.1.4. Pour une boutique WooCommerce, un multisite ou un hébergement comportant de nombreuses installations, privilégiez une intervention traçable, avec sauvegarde et contrôles fonctionnels.
Mettre à jour avec WP-CLI
Depuis le répertoire de l’installation WordPress, contrôlez d’abord la version actuelle :
wp core version
wp core check-updateEffectuez ensuite une sauvegarde indépendante des fichiers et de la base de données. L’export SQL suivant peut compléter une stratégie de sauvegarde existante, mais ne remplace pas la sauvegarde des fichiers et des médias :
wp db export /chemin/securise/wordpress-avant-7.1.4.sqlLangage du code : JavaScript (javascript)Après avoir vérifié le chemin de sauvegarde et son espace disponible, lancez la mise à jour du cœur :
wp core update --version=7.1.4
wp core update-dbVérifiez enfin la version installée et l’intégrité des fichiers du cœur :
wp core version
wp core verify-checksumswp core verify-checksums vérifie les fichiers du cœur WordPress face aux empreintes officielles ; cette commande n’a pas pour objet d’auditer les extensions, le thème ou les fichiers envoyés par les utilisateurs.
Pour approfondir la gestion en ligne de commande, consultez notre guide pour installer WP-CLI sur un hébergement Infomaniak et notre tutoriel pour nettoyer et optimiser la base de données avec WP-CLI.
Quels contrôles effectuer après l’installation ?
- Confirmer que le site public et l’administration répondent correctement.
- Tester les connexions, les formulaires et les fonctionnalités dépendant des rôles utilisateurs.
- Contrôler l’éditeur de blocs, les blocs personnalisés et les interactions JavaScript du thème.
- Pour WooCommerce, vérifier le panier, le paiement, l’espace client et les commandes de test.
- Lire les journaux PHP et serveur, puis vérifier les tâches planifiées et la file Action Scheduler lorsque le site l’utilise.
- Purger les caches applicatifs, serveur et CDN uniquement lorsque cela s’avère nécessaire.
Les changements relatifs à l’Interactivity API justifient une attention particulière sur les thèmes blocs et les extensions qui utilisent des directives data-wp-*. Pour comprendre les enjeux d’une architecture de thème récente, consultez aussi notre guide de création d’un thème WordPress sans constructeur de pages.
Faut-il attendre pour éviter une régression ?
Sur un site critique, une sauvegarde vérifiée et un test de non-régression restent indispensables. Toutefois, repousser indéfiniment un correctif de sécurité expose davantage le site, notamment lorsque les vulnérabilités deviennent publiques et font l’objet d’analyses détaillées.
Sur une boutique en production, une approche raisonnable consiste à préparer la restauration, tester la mise à jour sur un environnement de préproduction, puis déployer rapidement en surveillant les parcours essentiels. Pour déléguer cette opération et les correctifs suivants, découvrez mon service de maintenance WordPress : mises à jour supervisées, sauvegardes et contrôles après intervention. Ne restaurez pas une version vulnérable comme solution permanente à un conflit de compatibilité : identifiez plutôt l’extension ou le thème concerné et corrigez la régression.
Cette publication intervient également une semaine après la divulgation de deux vulnérabilités critiques de PHP. Ces incidents sont distincts, mais ils rappellent que la sécurité WordPress dépend à la fois du cœur, des extensions, de PHP et de la configuration du serveur. Nous avons détaillé les correctifs PHP dans notre article PHP : deux failles critiques corrigées, mettez à jour.
WordPress 7.2 arrive en décembre 2026
WordPress 7.1.4 est une version corrective à cycle court. La prochaine version majeure, WordPress 7.2, est prévue en décembre 2026. Les correctifs de sécurité applicables sont également intégrés à sa branche bêta.
Ne confondez pas cette échéance avec la nécessité de mettre à jour aujourd’hui. Il n’est pas pertinent d’attendre WordPress 7.2 pour combler les failles corrigées par WordPress 7.1.4. Et, comme toujours, les versions bêta ne doivent pas être déployées sur des sites de production.
Notre avis : mettez WordPress à jour, mais vérifiez vos environnements
La diversité des failles corrigées dans WordPress 7.1.4 en fait une publication importante pour les administrateurs et les développeurs. La vulnérabilité potentiellement exploitable sans authentification pendant une mise à jour du cœur mérite une attention particulière. Les multiples problèmes de l’Interactivity API devraient également inciter les développeurs à tester leurs blocs interactifs.
Notre recommandation : déployez WordPress 7.1.4 sans délai inutile, sauvegardez avant l’opération et contrôlez les fonctionnalités essentielles après l’installation. Pour les agences et les freelances chargés de plusieurs sites, centralisez le suivi des versions afin de détecter rapidement les installations oubliées.
En complément, nous vous invitons à consulter nos articles sur l’optimisation des requêtes SQL des extensions WordPress et sur la protection des commentaires WordPress contre le spam. Sécurité, performance et maintenance restent indissociables sur un site correctement administré.
