WordPress 7.1.1 - onze failles de sécurité corrigées, faut-il mettre à jour ?

WordPress 7.1.1 corrige onze failles de sécurité dans le coeur du CMS. Publiée le 17 septembre 2026, cette version de maintenance traite également 17 anomalies dans le coeur de WordPress et 21 dans l’éditeur de blocs.

L’équipe WordPress recommande de mettre les sites à jour immédiatement. La consigne est justifiée, mais elle ne doit pas être interprétée comme une invitation à cliquer sans préparation sur tous les environnements de production. Une mise à jour urgente reste une opération d’exploitation : elle doit être précédée d’une sauvegarde exploitable et suivie de contrôles techniques et fonctionnels.

Cette publication ne correspond pas à une vulnérabilité unique assortie d’un même niveau de gravité. Elle rassemble onze problèmes aux conditions d’exploitation différentes, depuis la divulgation limitée d’informations jusqu’à des injections de script persistantes.

WordPress 7.1.1 : ce que corrige réellement la mise à jour

Le bulletin officiel décrit onze corrections de sécurité :

• une URL spécialement construite pouvait provoquer l’installation et la prévisualisation d’un thème inactif provenant de WordPress.org ;
• certaines images d’en-tête personnalisées pouvaient conduire à une XSS persistante dans les thèmes compatibles ;
• le titre d’un article parent privé pouvait être divulgué ;
• une séquence de fermeture particulière permettait de sortir d’un commentaire traité par l’API HTML ;
• un administrateur de site multisite pouvait activer sur le réseau une extension réservée au réseau ;
• un contributeur pouvait écraser arbitrairement un article ;
• le contrôleur REST des modèles était exposé à une traversée de chemins pour un utilisateur authentifié ;
• tout utilisateur authentifié pouvait rattacher des commentaires, y compris des notes, à un autre contenu ;
• XML-RPC permettait de publier des changements de personnalisation sans respecter correctement la permission de modifier le CSS ;
• un contributeur pouvait découvrir les slugs d’articles en brouillon ou en attente ;
• le formatage des paragraphes pouvait permettre à un visiteur non authentifié d’enregistrer une XSS, sous réserve que son commentaire soit approuvé.

La dernière vulnérabilité retient naturellement l’attention puisqu’elle commence par un visiteur non authentifié. La condition de validation du commentaire reste néanmoins importante : il ne faut ni présenter la faille comme une compromission automatique de tous les sites WordPress, ni en déduire qu’elle peut être ignorée lorsque la modération est active.

Les autres problèmes nécessitent, selon les cas, un compte authentifié, un rôle particulier, une installation multisite ou une fonction précise. Cette diversité illustre pourquoi un bulletin contenant onze failles ne peut pas être résumé par un score unique.

Il ne s’agit pas d’une nouvelle faille WordPress critique de type WP2Shell

WordPress 7.1.1 est une mise à jour de sécurité importante, mais l’avis officiel ne décrit pas une exécution de code à distance sans authentification comparable à la chaîne de vulnérabilités WordPress WP2Shell.

La nuance compte. Exagérer systématiquement chaque correctif finit par rendre les véritables alertes critiques moins lisibles. À l’inverse, attendre une RCE publique avant de maintenir un site revient à accepter inutilement des risques d’injection de script, d’altération de contenu ou de contournement d’autorisations.

Une XSS persistante peut notamment permettre d’exécuter du JavaScript dans le navigateur d’un utilisateur qui consulte le contenu piégé. Les conséquences dépendent alors des droits de la victime, de la présence de protections complémentaires et du contexte de l’application.

Le bon message opérationnel est donc simple : la mise à jour doit être planifiée sans délai, avec une procédure proportionnée au rôle du site.

Quelles versions de WordPress faut-il corriger ?

Les quatre branches récentes WordPress 7.0, 6.9, 6.8 et 6.7 sont concernées par les onze vulnérabilités. Des versions plus anciennes sont touchées par une partie des problèmes. WordPress a publié des rétroportages jusqu’à la branche 4.7.

Pour les versions les plus courantes, les correctifs sont disponibles dans :

Branche installée	Version corrective minimale
WordPress 7.1	7.1.1
WordPress 7.0	7.0.5
WordPress 6.9	6.9.8
WordPress 6.8	6.8.9
WordPress 6.7	6.7.8

Les branches 6.6 à 4.7 disposent également de versions corrigées pour les vulnérabilités qui les concernent. WordPress 4.6 et les versions antérieures ne reçoivent plus de mise à jour de sécurité.

Ces rétroportages sont utiles lorsqu’une incompatibilité empêche temporairement une montée de version majeure. Ils ne doivent pas devenir une stratégie permanente. WordPress rappelle que seule la version la plus récente est activement prise en charge. Un site durablement bloqué sur une branche ancienne accumule généralement une dette plus large : PHP obsolète, extensions abandonnées, thème difficile à faire évoluer et procédure de déploiement fragile.

Mettre à jour immédiatement ne veut pas dire mettre à jour sans filet

Une intervention propre peut être rapide sans être improvisée. Avant de lancer la mise à jour, il faut au minimum connaître :

• la version réellement exécutée sur chaque environnement ;
• les extensions et le thème actifs ;
• la version de PHP et les contraintes de compatibilité ;
• les fonctions critiques du site, comme les formulaires, le paiement, l’espace client ou la publication ;
• l’état de la dernière sauvegarde et la possibilité de la restaurer ;
• la personne responsable de la validation après déploiement.

La procédure raisonnable consiste ensuite à :

1. sauvegarder les fichiers, la base de données et la configuration utile ;
2. vérifier que la sauvegarde est lisible et qu’une procédure de restauration existe ;
3. reproduire la mise à jour sur un environnement de recette lorsque le site est critique ou fortement personnalisé ;
4. appliquer la version corrective adaptée, puis mettre à jour les composants compatibles ;
5. purger les caches applicatifs, serveur et CDN si nécessaire ;
6. tester l’administration, les pages principales, les formulaires, les comptes et les transactions importantes ;
7. contrôler les erreurs PHP, les réponses HTTP, les tâches planifiées et les journaux de sécurité ;
8. confirmer la version effectivement servie sur tous les noeuds lorsque le site est redondé.

Pour un site vitrine simple, ces contrôles peuvent tenir dans une intervention courte. Pour une boutique, un espace membre ou une plateforme fortement personnalisée, ils doivent être préparés comme un véritable changement de production.

Les mises à jour automatiques réduisent l’exposition, pas la responsabilité

WordPress peut installer automatiquement certaines versions mineures de sécurité. Cette fonction est utile : elle raccourcit le temps pendant lequel un site reste exposé après la publication d’un correctif.

Elle ne confirme cependant pas que :

• l’opération a abouti sur toutes les instances ;
• le cache ne sert pas encore un comportement ancien ou défectueux ;
• le thème et les extensions fonctionnent toujours correctement ;
• une tâche métier importante n’a pas été interrompue ;
• le site n’était pas déjà compromis avant la correction ;
• la sauvegarde disponible permet réellement de revenir à un état sain.

L’automatisation doit donc produire un résultat observable : version remontée dans l’inventaire, alerte en cas d’échec, test de disponibilité, contrôle fonctionnel et suivi des erreurs. Sans cela, elle remplace seulement une opération manuelle par une hypothèse.

Que vérifier si le site est resté exposé ?

Le bulletin WordPress n’indique pas que les onze vulnérabilités font déjà l’objet d’une exploitation active à grande échelle. Il n’est donc pas justifié de déclarer tous les sites non corrigés compromis.

Une exposition prolongée mérite malgré tout quelques vérifications, en particulier sur un site autorisant les commentaires ou comportant plusieurs comptes éditoriaux :

• commentaires récemment approuvés contenant un balisage inhabituel ;
• comptes, rôles ou sessions d’administration inexpliqués ;
• thèmes ou extensions installés, activés ou modifiés récemment ;
• articles écrasés, slugs inattendus ou changements de personnalisation ;
• fichiers du coeur différents des sommes de contrôle officielles ;
• erreurs, requêtes REST, appels XML-RPC ou événements WAF anormaux ;
• redirections, scripts injectés ou contenus invisibles apparus dans les pages.

La mise à jour ferme les vulnérabilités connues. Elle ne supprime pas une modification malveillante déjà enregistrée dans la base ou les fichiers. Lorsqu’un indicateur sérieux apparaît, il faut isoler le périmètre, conserver les éléments utiles à l’analyse et restaurer depuis une origine dont l’intégrité peut être démontrée.

WordPress 7.1.1 rappelle pourquoi la maintenance doit être continue

Cette publication arrive deux mois après WP2Shell et confirme un point moins spectaculaire, mais plus structurant : la sécurité WordPress repose sur une maintenance continue.

Un site ne devient pas correctement maintenu parce qu’il possède une extension de sécurité. Il faut suivre le coeur, les thèmes, les extensions, PHP, le serveur web, la base de données, les sauvegardes, le WAF et les accès d’administration. Chaque composant évolue selon son propre calendrier.

Notre article consacré à la maintenance WordPress en 2026 détaille cette organisation. WordPress 7.1.1 en fournit un exemple concret : le correctif est disponible rapidement, mais sa valeur dépend encore de la capacité à identifier les sites concernés, le déployer, vérifier le résultat et réagir en cas d’anomalie.

Ce qu’il faut retenir de WordPress 7.1.1

WordPress 7.1.1 corrige onze vulnérabilités aux impacts et conditions d’exploitation différents. Deux concernent des XSS persistantes, tandis que plusieurs autres touchent les autorisations, l’intégrité des contenus ou l’accès à certaines informations.

La priorité est de vérifier la version installée et d’appliquer la version corrective de la branche concernée. Pour un site de production, cette urgence doit s’accompagner d’une sauvegarde, de tests fonctionnels et d’un contrôle des journaux.

Forget About IT peut intégrer cette intervention dans une prise en charge plus complète : inventaire, veille sur les vulnérabilités, maintenance, sauvegardes externalisées, supervision, durcissement et réaction aux incidents.

• Découvrir notre offre d’infogérance Linux
• Comprendre pourquoi la maintenance WordPress est indispensable
• Lire notre analyse de la faille WordPress WP2Shell
• Nous contacter pour reprendre la maintenance d’un site WordPress

Sources

• WordPress - annonce de la version 7.1.1 de maintenance et de sécurité
• WordPress - documentation et liste détaillée des correctifs de la version 7.1.1
• WordPress - archive officielle des versions disponibles

FAQ : mise à jour de sécurité WordPress 7.1.1

WordPress 7.1.1 est-il une mise à jour de sécurité urgente ?

Oui. WordPress 7.1.1 corrige onze vulnérabilités et l’équipe WordPress recommande une mise à jour immédiate. L’urgence ne dispense pas de sauvegarder le site et de vérifier son fonctionnement après l’intervention.

Quelles versions de WordPress sont concernées par les onze failles ?

WordPress 7.0, 6.9, 6.8 et 6.7 sont affectés par les onze vulnérabilités. Des branches plus anciennes sont touchées par une partie d’entre elles et ont reçu des rétroportages jusqu’à WordPress 4.7.

La mise à jour WordPress 7.1.1 corrige-t-elle une exécution de code à distance ?

L’avis officiel ne présente pas cette publication comme la correction d’une exécution de code à distance. Il décrit notamment deux XSS persistantes, une traversée de chemins authentifiée et plusieurs défauts d’autorisation.

Une mise à jour automatique suffit-elle à sécuriser le site ?

Non. Elle réduit la durée d’exposition, mais il faut encore confirmer la version installée, contrôler les extensions et le thème, tester les fonctions critiques, vérifier les journaux et s’assurer qu’une restauration reste possible.

Forget About IT peut-il maintenir et sécuriser un site WordPress ?

Oui. Forget About IT peut prendre en charge les mises à jour, les sauvegardes, la supervision, le durcissement, la veille sur les vulnérabilités et la réaction aux incidents d’un site WordPress.