Cybersécurité
WordPress 7.1.4 : 22 failles corrigées, et un dossier à fermer à clé sur votre serveur
WordPress a publié le 28 octobre la version 7.1.4, une mise à jour de sécurité, et le CERT-FR l’a reprise le lendemain dans son avis CERTFR-2026-AVI-1420. Selon le décompte relayé par Patchstack, elle corrige 22 vulnérabilités réparties dans 17 bulletins, contre sept pour la version précédente. De quoi justifier un petit tour dans le tableau de bord, même un vendredi 🙂
Ce qui est corrigé
La faille la plus sérieuse sur le papier touche le processus de mise à jour lui-même. L’équipe WordPress explique qu’une faiblesse peut mener à une exécution de code à distance « pendant la fenêtre de mise à jour ». Patchstack précise qu’elle ne demande aucun compte, mais que l’attaquant doit viser une fenêtre de quelques secondes, pendant une mise à jour, alors que le dossier wp-content/upgrade/ est accessible depuis le web. Exploitation difficile, donc, mais pas nulle.
Le reste du lot :
- des XSS stockées dans plusieurs blocs (Catégories, Playlist, image, pagination des commentaires), dans la personnalisation et dans l’API Interactivity. La plupart demandent un compte Contributeur ou plus ;
- une fuite d’informations : des modifications non publiées du Customizer peuvent être découvertes sans être connecté ;
- un souci de droits sur les notes, lisibles ou modifiables par certains rôles qui n’ont pas accès à l’édition de l’article ;
- un déni de service lié à l’API Interactivity, qui fige l’onglet du visiteur et non le serveur.
Certains sites d’information ont parlé d’une faille « activement exploitée ». Ni l’annonce officielle de WordPress ni l’analyse de Patchstack ne mentionnent d’exploitation active : je reste donc prudent sur ce point.
Quelles versions mettre à jour
| Vous êtes sur… | Version corrigée |
|---|---|
| 7.1.x | 7.1.4 |
| 7.0.x | 7.0.8 |
| 6.9.x / 6.8.x | 6.9.11 / 6.8.12 |
| Branches plus anciennes | rétroportages jusqu’à 4.7.39 |
| 4.6 ou plus ancien | aucun correctif : il faut migrer |
Les sites qui acceptent les mises à jour automatiques en arrière-plan la recevront seuls. Les autres passent par Tableau de bord > Mises à jour. Rappel utile de WordPress : seule la dernière version est réellement maintenue, les rétroportages sont un filet de sécurité, pas une stratégie.
Mon regard d’intégrateur : un site web, c’est aussi un équipement à maintenir
Dans nos métiers, beaucoup d’installateurs, de bureaux d’études et de syndics ont un site WordPress, parfois avec un espace client, un formulaire de demande d’intervention ou une page de documentation. On passe nos journées à expliquer qu’une caméra ou un automate de GTB doit recevoir ses correctifs ; le site vitrine mérite le même traitement. Un site compromis, c’est une page de hameçonnage hébergée sous votre nom et envoyée à vos propres clients. Pas vraiment la carte de visite rêvée.
Ce que je vérifierais sur un WordPress auto-hébergé :
- La version affichée en bas du tableau de bord, et l’activation des mises à jour automatiques de sécurité.
- Le dossier
wp-content/upgrade/: comme le recommande Patchstack, bloquez-le au niveau du serveur web (Apache ou Nginx). Un pare-feu applicatif écrit en PHP ne voit pas passer cette requête. WordPress l’utilise en interne, pas par le web. - Les comptes : la plupart de ces failles partent d’un compte Contributeur ou plus. Un ancien stagiaire ou un prestataire qui n’intervient plus n’a rien à faire dans la liste des utilisateurs.
- Les extensions, qui restent la première source d’ennuis : profitez-en pour faire le ménage.
- La sauvegarde avant la mise à jour, et un test de restauration de temps en temps.
Au fond, c’est la même hygiène que pour un NVR ou une supervision : inventaire, mises à jour, comptes nominatifs et droits minimaux. Le web n’échappe pas à la règle. La prochaine version majeure, la 7.2, est annoncée pour le 8 décembre : bonne occasion de planifier dès maintenant votre fenêtre de maintenance.
Commentaires
Aucun commentaire pour l'instant : lancez la discussion.