WordPress : la faille de la mise à jour du cœur désormais exploitée

La mise à jour est d'ordinaire le geste qui protège. Avec CVE-2026-119977, c'est le moment précis où un site WordPress devient attaquable. Le 28 octobre, WordPress a publié la version 7.1.4, qui corrige notamment une situation de concurrence (« race condition ») dans le processus de mise à jour du cœur pouvant mener à une exécution de code à distance. Le 3 novembre, la CISA, l'agence américaine de cybersécurité, a ajouté cette faille à son catalogue des vulnérabilités activement exploitées (KEV).

WordPress fait tourner une grande partie des sites vitrines, des blogs d'entreprise et des sites de campagne. Beaucoup sont gérés par une agence ou un prestataire, et rarement suivis par la DSI. C'est précisément là que ce type de faille fait des dégâts.

Ce que l'on sait

D'après l'alerte de la CISA et les analyses publiées par la presse spécialisée :

Produit : le cœur de WordPress (pas une extension).
Versions touchées : de 4.7 à 7.1.3.
Versions corrigées : 7.1.4, publiée le 28 octobre, avec des correctifs reportés sur les branches maintenues, par exemple 7.0.8, 6.9.11, 6.8.12 et 6.7.11. Les sites en version 4.6 ou antérieure ne reçoivent aucun correctif.
Gravité : Wordfence, qui a attribué le CVE, la note 8,1 sur 10 (CVSS 3.1). WordPress, de son côté, la classe en sévérité faible, selon la presse.
Conditions : l'attaque ne demande ni compte ni action d'un utilisateur, mais elle doit réussir pendant la courte fenêtre où le site installe une mise à jour complète du cœur.
Exploitation : la CISA l'a inscrite au catalogue KEV « sur la base de preuves d'exploitation active ». Selon Threat Defence, qui cite Wordfence, plus de 18 500 requêtes visant les fichiers d'installation temporaires ont été observées dans les 21 premières heures après la publication du correctif. Wordfence ne faisait alors état d'aucune compromission confirmée.

La version 7.1.4 corrige aussi d'autres failles, dont plusieurs de type XSS stocké. Les sources ne s'accordent pas sur leur nombre exact.

Comment fonctionne l'attaque

Selon l'analyse technique de Threat Defence, lorsqu'un site installe un paquet complet du cœur, les versions vulnérables décompressent les nouveaux fichiers dans un dossier temporaire au nom prévisible, sous `wp-content/upgrade`. Cette copie contient l'installateur de WordPress, dont `wp-admin/setup-config.php`.

Pendant les quelques secondes où ce dossier existe, un attaquant qui interroge le bon chemin peut atteindre cet installateur et aller jusqu'à l'exécution de code PHP sur le serveur. La requête vise directement le fichier PHP sans charger WordPress : une extension de pare-feu qui fonctionne à l'intérieur de WordPress ne la voit donc pas.

Le correctif rend le nom du dossier temporaire aléatoire, conserve le fichier qui empêche le listage du répertoire et ne recopie plus les données de configuration.

Pourquoi c'est grave pour une entreprise

Un site vitrine paraît sans enjeu. En pratique, il partage souvent un hébergement avec d'autres sites, stocke des formulaires de contact, des candidatures ou des comptes clients, et porte le nom de votre marque. Un attaquant qui exécute du code sur ce serveur peut y déposer une porte dérobée, voler les données, injecter du contenu malveillant à destination de vos visiteurs ou utiliser le serveur comme point d'appui.

Le paradoxe de cette faille tient en une phrase : les sites les plus exposés sont ceux qui se mettent à jour, à condition qu'ils ne soient pas encore en 7.1.4. Les sites dont les mises à jour automatiques sont désactivées, ou gérés par une chaîne de déploiement qui n'a pas encore intégré le correctif, restent vulnérables à chaque future mise à jour du cœur.

Les mesures à prendre maintenant

Inventorier. Listez tous vos sites WordPress, y compris ceux gérés par une agence, les sites de campagne et les environnements de préproduction exposés sur Internet.
Vérifier la version. Chaque site doit être en 7.1.4 ou dans la version corrigée de sa branche. Un site en 4.6 ou antérieure doit être migré ou retiré.
Bloquer l'accès web au dossier `wp-content/upgrade` avant toute mise à jour d'un site non corrigé. WordPress y accède par le système de fichiers, pas par le web.
Contrôler les journaux. Recherchez les requêtes vers des fichiers PHP sous `/wp-content/upgrade/`, en particulier un `POST` vers un `setup-config.php` temporaire ayant reçu une réponse 200.
Chercher les traces de compromission : comptes administrateurs inconnus, fichiers PHP inattendus dans les dossiers `uploads`, `upgrade` ou `mu-plugins`.
Interroger vos prestataires. Demandez à votre agence ou à votre hébergeur la version installée sur chaque site et la date de mise à jour.

Notre regard

Lors de nos tests d'intrusion, les sites WordPress oubliés reviennent souvent : un site de campagne jamais retiré, une préproduction ouverte, une extension abandonnée. Ils sont rarement dans le périmètre des audits, alors qu'ils sont sur Internet, au nom de l'entreprise.

Si vous voulez savoir ce que votre organisation expose réellement sur Internet, et ce qu'un attaquant pourrait en faire, contactez-nous.