Une version de sécurité, pas une mise à jour de routine
L'annonce officielle de WordPress 7.1.4 date du 28 octobre 2026 et la présente comme une version de sécurité : elle recommande de mettre à jour immédiatement, et les sites en mise à jour automatique en arrière-plan s'y rangent d'eux-mêmes. Selon Patchstack, WordPress compte 22 vulnérabilités sur 17 avis, contre 7 pour la 7.1.3 publiée trois semaines plus tôt. Sept avis sur dix-sept touchent l'API Interactivity, et la plupart des autres sont des XSS stockées qui supposent au moins un compte Contributeur. Il y a aussi une fuite des révisions de personnalisation non publiées pour un visiteur anonyme, et une faiblesse dans le processus de mise à jour. Ni l'annonce officielle ni Patchstack ne rapportent d'exploitation : cet article n'en affirme aucune.
La course critique à la mise à jour, et pourquoi ne pas attendre
Avant la 7.1.4, le dossier d'extraction créé sous wp-content/upgrade/ avait un nom prévisible pour les paquets envoyés depuis l'administration, et le nettoyage supprimait tout son contenu, y compris le fichier index.php qui bloque le listage. Pendant une mise à jour, une copie complète de WordPress se trouvait alors à une adresse devinable et navigable, wp-admin/setup-config.php compris. Aucun compte ni action d'utilisateur n'est requis, mais l'attaquant doit viser une fenêtre de quelques secondes. Patchstack juge l'exploitation difficile et peu pratique ; cette fenêtre revient pourtant à chaque mise à jour, y compris automatique. Le correctif ajoute 16 caractères aléatoires au nom du dossier, recrée index.php sans le supprimer et empêche wp-config.php d'être copié hors du répertoire de travail. Reste l'objection d'agence : si c'est difficile à exploiter, pourquoi agir tout de suite ? Parce que la mise à jour du cœur passe en premier et coûte une commande par site, et que la fermeture du dossier au niveau du serveur est une défense en profondeur. Un pare-feu applicatif PHP ne peut pas la tenir, puisque la copie extraite s'exécute sans les mu-plugins du site.
Inventorier puis mettre à jour chaque site du parc
Huit étapes avec WP-CLI, du contrôle à la vérification
Sauvegarder avant tout
Exporter la base de chaque site, puis copier
wp-contentsi une sauvegarde de fichiers n'existe pas déjà :wp db export pre-update.sqlRetrouver les installations
Sur un serveur qui héberge plusieurs comptes, lister les
wp-config.php:find /home -name wp-config.php -not -path '*/wp-content/*' 2>/dev/nullLire la version de chaque site
Pour un site, puis pour une liste de chemins (un par ligne dans
sites.txt) :
`wp core version
wp core check-update`while read -r d; do printf '%s ' "$d"; wp --path="$d" core version --skip-plugins --skip-themes; done < sites.txtRepérer les branches sans correctif
Comparer chaque version lue au tableau ci-dessous : une branche 4.6 ou plus ancienne n'a aucun correctif et sort de la tournée de mise à jour.
Mettre à jour le cœur
Pour monter vers la dernière version, lancer la première commande ; pour rester sur la branche installée et appliquer son seul correctif, la seconde :
wp core updatewp core update --minorMettre à jour la base
Appliquer les éventuelles migrations de schéma :
wp core update-dbVérifier le résultat
Relire la version puis contrôler l'intégrité des fichiers du cœur :
`wp core version
wp core verify-checksums`Boucler sur le parc
Rejouer la mise à jour de branche sur chaque chemin de la liste :
while read -r d; do wp --path="$d" core update --minor && wp --path="$d" core update-db; done < sites.txt
Version corrigée par branche, le 28 octobre 2026
Faites défiler le tableau
| Branche installée | Version corrigée | Action pour l'agence |
|---|---|---|
| 7.1 | 7.1.4 | Mettre à jour ; la mise à jour automatique du cœur s'en charge si elle est active |
| 7.0 | 7.0.8 | Mise à jour mineure, puis planifier la montée de branche |
| 6.9 | 6.9.11 | Mise à jour mineure, puis planifier la montée de branche |
| 6.8 | 6.8.12 | Mise à jour mineure, puis planifier la montée de branche |
| 6.7, 6.6, 6.5, 6.4 | 6.7.11, 6.6.11, 6.5.14, 6.4.14 | Mise à jour mineure, puis montée de branche prioritaire |
| 6.3 à 4.7 | Un correctif par branche, jusqu'à 4.7.39 | Mise à jour mineure, puis migration vers une branche courante |
| 4.6 et antérieures | Aucun correctif | Ne pas patcher : migrer le site |
La règle d'agence tient en une phrase : un site sur une branche sans correctif se migre, il ne se patche pas. Le billet officiel précise que les correctifs sont rétroportés vers toutes les branches éligibles, aujourd'hui jusqu'à la 4.7, et qu'ils se déploient au fur et à mesure ; confirmez donc sur wordpress.org le numéro disponible pour chaque branche avant d'annoncer une date au client. Côté responsabilité, c'est vous que le client appelle si un site tombe : consignez par site la version avant, la version après et l'heure de l'opération, et tenez ce relevé à la disposition du client. Pour l'inventaire PHP du même parc, voir l'article dédié ; pour une faille précédente du cœur, voir celui sur la 7.1.2.
Fermer wp-content/upgrade/ au niveau du serveur
La source établit une seule chose : il faut interdire l'accès web à wp-content/upgrade/ et vérifier que le dossier n'est pas listable ; entre deux mises à jour, il ne devrait contenir que index.php. Les règles ci-dessous sont donc du durcissement générique que nous proposons, pas une consigne de l'avis. La mise à jour passe par le système de fichiers de PHP et non par une requête HTTP, de sorte que refuser l'accès web ne la gêne pas. Ce blocage ne remplace pas la mise à jour du cœur : il ferme la fenêtre pendant les opérations à venir. Placez toujours la règle au niveau du site ou du serveur, jamais dans le dossier lui-même, que le processus de mise à jour manipule.
Huit gestes selon l'environnement, du blocage à la preuve
nginx : bloquer le dossier
Ajouter dans le bloc
serverdu site, avant le bloc qui traite les fichiers PHP ; le modificateur^~évite qu'une expression régulière passe devant :
`location ^~ /wp-content/upgrade/ {
return 404;
}`
Puis tester et recharger :nginx -t && systemctl reload nginxnginx : une règle pour tout le parc
Écrire la règle dans un fichier de snippet et l'inclure dans chaque vhost, de façon qu'un nouveau site la reçoive aussi :
include /etc/nginx/snippets/wp-upgrade-deny.conf;Apache : bloc Directory
Dans la configuration du vhost, avec le chemin réel du site :
`<Directory "/var/www/votre-domaine.com/wp-content/upgrade">
Require all denied
</Directory>`
Puis valider et recharger :apachectl configtest && systemctl reload apache2Mutualisé ou cPanel : .htaccess
Sans accès à la configuration du serveur, ajouter à la racine du site, dans le
.htaccessexistant, une redirection vers une erreur 404 :RedirectMatch 404 ^/wp-content/upgrade(/|$)Docker : où poser la règle
La règle va dans le conteneur qui sert le HTTP : le reverse proxy nginx ou la configuration Apache de l'image. Montez-la en volume pour qu'elle survive à une reconstruction, puis rechargez le conteneur.
Prouver que ça répond 403 ou 404
Tester le dossier et son
index.phpdepuis l'extérieur ; chaque ligne doit rendre 403 ou 404, pas 200 :
`curl -I https://votre-domaine.com/wp-content/upgrade/
curl -I https://votre-domaine.com/wp-content/upgrade/index.php`Couvrir chaque vhost
Lister les sites qui n'ont pas la règle ; la liste doit être vide après un déploiement :
grep -L -E 'wp-content/upgrade|wp-upgrade-deny' /etc/nginx/sites-enabled/*Contrôler le contenu du dossier
Hors mise à jour en cours, seul
index.phpdoit apparaître :ls -A /var/www/votre-domaine.com/wp-content/upgrade
Auteurs externes : ce que les XSS Contributeur changent
Cinq contrôles sur les comptes d'un site client
- Lister les comptes — repérer les rôles Contributeur et supérieurs :
wp user list --role=contributor --fields=ID,user_login,user_registered - Retirer l'inutile — supprimer ou rétrograder les comptes d'anciens prestataires et de rédacteurs partis.
- Ne pas ouvrir de compte par confort — une XSS stockée a besoin d'un compte qui écrit ; moins de comptes, moins de surface.
- Prévenir les administrateurs — plusieurs failles se déclenchent quand un administrateur ouvre un contenu piégé ou l'écran de personnalisation.
- Mettre à jour avant de relire — appliquer la 7.1.4 avant de rouvrir les brouillons de contributeurs externes.
Une version de sécurité sert surtout de test de méthode. Si l'inventaire, la mise à jour et la règle serveur prennent une matinée sur un parc de dix sites, ils prendront trois jours sur cent. Un espace agence centralise les comptes cPanel, les hébergements et les expirations, pour que la tournée commence par une liste à jour plutôt que par une recherche.
