WordPress: exécution de code pendant la mise à jour du cœur

Ce qui se passe

WordPress a corrigé le 28 octobre, avec la version 7.1.4, une condition de course dans le processus de mise à jour complète du cœur. Tant que la nouvelle version n'est pas installée, WordPress 4.7.0 à 7.1.3 déplie les fichiers dans un répertoire prévisible et accessible par le web sous wp-content/upgrade, copie qui contient l'installeur. Un attaquant non authentifié qui sonde ce chemin pendant la brève fenêtre de déploiement peut interagir avec l'installeur en préparation et aboutir à l'exécution de code avec les privilèges du processus web. Wordfence, CNA du dossier, a publié le CVE-2026-119977 le 31 octobre et le note 8,1 en CVSS 3.1, la complexité étant élevée puisque l'exploitation n'est possible que pendant la mise à jour. Des sondages automatisés ont commencé dans les heures suivant la publication du correctif et se poursuivent; à ce jour, aucune compromission confirmée n'est documentée. Le CERT national du Bhoutan a publié le 2 novembre un avis opérationnel recommandant de couper l'accès web au répertoire de transit avant toute montée de version.

Pourquoi c'est grave pour un hôtel

Le risque ne se déclenche pas sur un site à jour ou un site en retard: il se déclenche au moment où vous faites la mise à jour. Or les parcs hôteliers correspondent exactement au profil exposé: des dizaines de microsites gérés d'un même bureau, mis à jour par lots, souvent en pleine journée d'exploitation, avec des hébergeurs partagés où wp-content/upgrade reste servi par le serveur web. Un acteur qui surveille les domaines d'un groupe peut simplement attendre la fenêtre.

Qui est touché

• WordPress cœur 4.7.0 à 7.1.3, toutes langues, tant que la montée vers la version corrigée de la branche n'est pas terminée.
• Sites mis à jour par le tableau de bord (paquet complet), là où le staging est écrit sous wp-content/upgrade.
• Parcs gérés par des agences: la fenêtre de mise à jour se répète site par site, ce qui multiifie les occasions.

Comment corriger

1. Mettre à jour chaque site vers 7.1.4, ou vers la release de sécurité de sa branche (7.0.8, 6.9.11, rétroportées jusqu'à la lignée 4.7).
2. Avant la mise à jour, bloquer l'accès web à wp-content/upgrade par règle WAF ou réécriture serveur; le débloquer seulement si la montée échoue et doit être rejouée.
3. Préférer la mise à jour en ligne de commande (wp core update) sur les sites où c'est possible: elle réduit la fenêtre et permet de scripted le blocage.
4. Activer les mises à jour automatiques de sécurité et planifier les montées majeures hors heures d'affluence, propriété par propriété plutôt que par lots simultanés exposés aux mêmes sondes.
5. Vérifier auprès de l'hébergeur ou du WAF que les règles de protection s'exécutent avant le PHP du site.

Contexte

Cœur WordPress cette semaine, Gravity Forms la semaine dernière: la filière web des microsites hôteliers enchaîne les correctifs à un rythme soutenu, et cette faille a la particularité de punir l'administrateur qui fait ce qu'on lui demande. La parade n'est pas de reporter les mises à jour, mais de sécuriser la fenêtre: bloquer le chemin de transit, mettre à jour hors heures, vérifier après coup.