Aller au contenu
Le journal

Notes & retours d’expérience

Faille WordPress pendant les mises à jour (CVE-2026-119977) : que faire maintenant

9 min de lecture

Une faille du cœur de WordPress permet d'exécuter du code sans compte pendant les quelques secondes d'une mise à jour. Corrigée le 28 octobre, elle est inscrite au catalogue KEV de la CISA depuis le 3 novembre. Qui est exposé, l'ordre des gestes, et comment chercher des traces.

Mardi 3 novembre, la CISA, l'agence américaine de cybersécurité, a ajouté une faille du cœur de WordPress à son catalogue des vulnérabilités exploitées (KEV). Elle porte l'identifiant CVE-2026-119977 et permet à un attaquant sans compte d'exécuter du code sur le serveur, mais seulement pendant les quelques secondes où WordPress installe une mise à jour complète. Le correctif existe depuis le 28 octobre : WordPress 7.1.4, et une version corrigée pour chaque branche jusqu'à 4.7.

Ce n'est pas php2shell, que j'ai traité il y a deux semaines : l'attaque est difficile et aucun site piraté n'a été décrit publiquement à ce jour. Mais elle touche le cœur de WordPress, pas une extension, et presque toutes les versions encore en service. Surtout, elle a un piège : la mise à jour qui corrige la faille est elle-même réalisée par l'ancien code vulnérable. Je fais ici le point sur ce qui est établi, et sur ce qu'une PME qui a un ou plusieurs sites WordPress doit faire cette semaine.

Ce qui a été corrigé

Le 28 octobre, WordPress a publié la version 7.1.4, une version de sécurité qui corrige 22 problèmes, pour l'essentiel des failles XSS stockées exploitables par des comptes contributeur ou plus. Une seule ligne compte vraiment : « une faiblesse du processus de mise à jour qui peut mener à une exécution de code à distance pendant la fenêtre de mise à jour », signalée par le chercheur Umut Bayram (Picus Security).

Le mécanisme, tel que le décrit Wordfence, qui a attribué la CVE :

  • La copie temporaire : pendant une mise à jour du cœur à partir du paquet complet, WordPress décompresse une copie entière de lui-même dans un dossier au nom prévisible, sous wp-content/upgrade/, avant de déplacer les fichiers à leur place. Cette copie contient l'installeur, wp-admin/setup-config.php.
  • La fenêtre : sur beaucoup de serveurs, ce dossier est accessible depuis le web. Un attaquant qui appelle l'installeur au bon moment peut piloter la copie et aller jusqu'à l'exécution de code PHP. En laboratoire, la fenêtre ne dure que quelques secondes.
  • L'effet : selon l'analyse du correctif publiée par HOL, l'attaquant fait pointer l'installeur vers une base de données qu'il contrôle, et la mise à jour recopie ensuite le wp-config.php piégé dans le site en production.

La version 7.1.4 rend le nom du dossier aléatoire, y place une page index.php de garde et empêche la copie de la configuration depuis le dossier temporaire. Le correctif a été rétroporté sur toutes les branches maintenues : 7.0.8, 6.9.11, 6.8.12, 6.7.11, 6.6.11, puis 6.5.14, 6.4.14, 6.3.14, 6.2.15, 6.1.16, 6.0.18, 5.9.20, 5.8.19, 5.7.21, 5.6.23, 5.5.24, 5.4.25, 5.3.27, 5.2.30, 5.1.28, 5.0.31, 4.9.35, 4.8.34 et 4.7.39. Rien n'est prévu pour WordPress 4.6 et antérieurs.

Les notes divergent, et c'est un détail qui compte. Wordfence note la faille 8,1 sur 10 (CVSS 3.1), avec une complexité d'attaque élevée. L'avis de WordPress lui-même la classe en gravité faible, et la base américaine NVD ne l'avait pas encore notée au 4 novembre. Le CERT-FR l'a intégrée à son avis du 29 octobre sur les multiples vulnérabilités de WordPress, sans alerte dédiée. C'est l'inscription au catalogue KEV qui tranche : on planifie sur l'exploitation, pas sur la note.

Ce que l'on sait de l'exploitation

Les attaquants ont compris très vite. Wordfence a déployé une règle de pare-feu le 28 octobre à 21 h 30, heure de Paris, environ trois heures après la publication de WordPress. La première requête bloquée est arrivée neuf minutes plus tard. En 21 heures, l'éditeur a compté plus de 18 500 requêtes visant des chemins setup-config.php dans le dossier temporaire, dont deux sources qui ont interrogé en boucle les mêmes petits groupes de sites pendant environ 14 h 30, pour tomber sur une mise à jour en cours. The Hacker News relève 12 632 attaques bloquées en 24 heures au 4 novembre, et trois tentatives d'exploitation enregistrées le 30 octobre par les leurres de Previdian, depuis une adresse britannique.

Le 3 novembre, la CISA a ajouté la faille au catalogue KEV « sur la base de preuves d'exploitation active ». Elle donne aux administrations fédérales américaines jusqu'au 6 novembre, soit trois jours, un délai plus court que d'habitude, et leur demande un tri forensique : vérifier qu'aucun système n'a été compromis avant le correctif. Le centre belge de cybersécurité a publié un avertissement le même jour.

Il faut rester précis. La CISA ne publie pas les preuves derrière ses inscriptions, aucun indicateur de compromission n'a été diffusé, et au 3 novembre ni la CISA, ni WordPress, ni Wordfence n'avaient décrit un site effectivement pris. Ce qui est établi, c'est un ciblage massif, automatisé et patient d'une fenêtre étroite.

Qui est exposé

Le danger ne vient pas du site au repos, mais du moment où il se met à jour. Or WordPress active par défaut les mises à jour automatiques de sécurité du cœur : pour beaucoup de sites, la fenêtre s'ouvre seule, la nuit, sans personne pour regarder. Et la mise à jour vers 7.1.4 a elle-même été décompressée par l'ancien code, le jour où les sondages avaient déjà commencé.

Sont exposés les sites qui cumulent trois conditions : une version entre 4.7 et 7.1.3 au moment de la mise à jour, une mise à jour du cœur par l'outil intégré (tableau de bord, mise à jour automatique ou WP-CLI), et un dossier wp-content/upgrade/ dont les fichiers PHP s'exécutent quand on les appelle depuis le web.

Sont hors de portée de cette faille précise :

  • Les sites déployés par Composer, git ou image de conteneur avec DISALLOW_FILE_MODS à true : l'outil de mise à jour intégré ne tourne jamais, il n'y a pas de fenêtre. Ils doivent quand même recevoir le code corrigé.
  • Les serveurs qui refusaient déjà l'accès web à `wp-content/upgrade/` avant leur dernière mise à jour.
  • Les versions antérieures à 4.7, qui ont d'autres problèmes, et pas de correctif.

Pour une PME, le vrai sujet est donc moins le site vitrine qu'on suit de près que les autres : le site d'un événement passé, le WordPress installé par une agence il y a cinq ans, le blog d'une filiale, l'intranet sur un mutualisé. C'est exactement le parc qui se met à jour tout seul, sans surveillance.

Ce que je ferais cette semaine

Déroulé de la faille CVE-2026-119977 pendant une mise à jour du cœur WordPress, et les quatre actions à mener dans l'ordre : bloquer d'abord le dossier upgrade au niveau du serveur web, mettre à jour, vérifier, chercher des traces

La faille ne vit que pendant la mise à jour. D'où l'ordre : fermer le dossier avant de mettre à jour.

1. Bloquer le dossier avant de mettre à jour. Interdisez tout accès web à wp-content/upgrade/ au niveau du serveur web, pas dans une extension de sécurité : la copie temporaire démarre à partir de ses propres fichiers, vos extensions ne se chargent jamais pour ces requêtes. Pour nginx, dans le bloc server : location ^~ /wp-content/upgrade/ { deny all; }. Pour Apache, dans le virtual host ou le .htaccess racine, hors du bloc # BEGIN WordPress : RedirectMatch 403 ^/wp-content/upgrade/. Testez ensuite qu'une requête vers /wp-content/upgrade/ renvoie bien 403. Sur un hébergement mutualisé ou infogéré où vous n'avez pas la main sur la configuration, posez la question par écrit à l'hébergeur. La règle est sans risque et sert pour toutes les mises à jour suivantes, pas seulement celle-ci.

2. Mettre à jour, puis vérifier que c'est fait. Passez en 7.1.4, ou en version corrigée de votre branche. Les clients Wordfence payants ont la règle de pare-feu depuis le 28 octobre, les utilisateurs gratuits ne l'auront que le 27 novembre ; dans les deux cas, Wordfence précise que le pare-feu doit tourner en mode « Extended Protection » pour intercepter ces requêtes directes, et qu'il ne remplace pas la mise à jour. Une mise à jour automatique peut échouer en silence : vérifiez site par site. Avec WP-CLI, wp core version doit renvoyer la version corrigée, wp core verify-checksums doit passer sans erreur, et l'option auto_core_update_failed, que WordPress crée quand une mise à jour automatique échoue, ne doit pas exister (wp option get auto_core_update_failed). Le dossier wp-content/upgrade/ ne doit contenir que index.php une fois la mise à jour terminée, et aucun fichier .maintenance ne doit traîner à la racine.

3. Chercher des traces, surtout autour de la dernière mise à jour. Repérez quand le cœur a été mis à jour : stat -c '%y %n' wp-includes/version.php donne la date de la dernière réécriture. Cherchez ensuite dans les journaux d'accès les requêtes vers l'installeur dans le dossier temporaire, par exemple grep -E "/wp-content/upgrade/.*(setup-config|install)\.php" access.log*. Des 403 ou des 404, c'est le sondage décrit par Wordfence. Un code 200 proche de l'heure de mise à jour, c'est le cas à creuser. Si les journaux ne remontent pas jusqu'au 28 octobre, regardez le site lui-même : find wp-content/upgrade -type f -name '*.php' ! -path 'wp-content/upgrade/index.php' ne doit rien trouver, et la date de modification de wp-config.php doit avoir une explication.

4. Ouvrir wp-config.php. C'est la vérification la plus simple et la plus parlante. DB_HOST, DB_NAME et DB_USER doivent pointer vers votre base de données. Un hôte de base inconnu signifie que le site doit être traité comme compromis : on l'isole, on part d'une sauvegarde antérieure au 28 octobre, on change tous les secrets (mots de passe de base, clés et sels WordPress, comptes administrateurs) et on cherche ce qui a pu être déposé ailleurs sur le serveur. Les comptes administrateurs, extensions ou fichiers PHP apparus récemment méritent le même examen.

Si vous gérez un parc de sites, ces quatre étapes tiennent dans un script et une demi-journée. Si vous n'avez ni accès au serveur ni prestataire qui répond, c'est le type d'intervention que je fais : audit, sécurisation et remise en route, décrite sur la page remise en route WordPress et PHP.

Ce que ça dit des mises à jour automatiques

La leçon dépasse WordPress. On répète depuis des années qu'il faut activer les mises à jour automatiques, et c'est toujours vrai. Mais cette faille rappelle qu'une mise à jour est elle-même une opération à risque : un moment où le système est dans un état intermédiaire, où des fichiers temporaires existent, où la configuration change. Un attaquant patient n'a pas besoin d'une faille permanente s'il sait quand regarder.

Pour un CTO de PME, cela veut dire trois choses. Une mise à jour automatique doit être vérifiée, pas seulement activée : savoir qu'elle a réussi, quand, et dans quelle version. Les dossiers de travail d'un outil n'ont rien à faire sur le web, et une règle de serveur posée une fois vaut mieux qu'une extension de plus. Enfin, le déploiement par artefact, où le code part d'un dépôt et où le serveur ne se modifie pas lui-même, supprime toute une famille de failles de ce type. C'est la même logique que dans notre article sur la discipline de patch des runtimes : la vitesse compte, mais la capacité à prouver qu'un correctif est bien en place compte autant.

Sources

Retour au journalEn parler ensemble
Tout le journal