RCE WordPress Core pendant la fenêtre de mise à jour, corrigé dans 7.1.4 (CVE-2026-119977)

TL;DR

• Une faille du programme de mise à jour de WordPress Core permet à un attaquant non authentifié d'exécuter du code sur le serveur pendant la fenêtre de quelques secondes où WordPress décompacte une mise à jour du cœur. Les versions 4.7.0 à 7.1.3 sont concernées. Umut Bayram de Picus Security l'a divulguée de façon responsable.
• L'enregistrement CVE de Wordfence note la faille 8,1 High, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H, et l'avis de WordPress note la même course Low. Wordfence a bloqué 62 969 attaques la ciblant en 24 heures au 30 octobre.
• Le correctif est paru dans WordPress 7.1.4, publié le 28 octobre 2026, et rétroporté vers chaque branche jusqu'à 4.7. Aucune compromission n'est signalée, et le CVE n'est pas dans le catalogue KEV (Known Exploited Vulnerabilities) de la CISA au 31 octobre 2026.
• Passez à 7.1.4 ou au rétroportage de votre branche maintenant, puis fouillez vos journaux du serveur web pour les requêtes vers des fichiers PHP sous wp-content/upgrade. Les sites non corrigés ouvrent une fenêtre vulnérable à chaque mise à jour, y compris celle vers 7.1.4.

Suis-je concerné ?

Toutes ces conditions doivent être réunies pour l'attaque non authentifiée :

• Vous exécutez WordPress 4.7.0 à 7.1.3, dans une des branches listées ci-dessous.
• Votre site applique les mises à jour du cœur via le programme de mise à jour de WordPress, qui décompacte un paquet complet dans wp-content/upgrade/ sur le serveur web.
• Ce répertoire est accessible par le web, ce que Wordfence signale être le cas sur de nombreux serveurs, et ses fichiers s'exécutent comme du PHP.
• L'attaquant gagne la course : il doit atteindre les fichiers décompactés entre le décompactage et le nettoyage, une fenêtre que Wordfence a observée comme ne durant que quelques secondes en laboratoire.

Le chemin est prévisible sur toutes les versions concernées, donc la quatrième condition relève du minutage, pas de la connaissance. L'attaquant n'a besoin d'aucun compte sur le site ni d'aucune interaction de quiconque.

WordPress équipe 39,5 % des sites web. L’enquête W3Techs du 31 octobre montre la répartition par version majeure, sans distinguer les versions corrigées des versions vulnérables. Utilisez le tableau ci-dessus pour évaluer votre site.

Vérifiez la version de chaque site que vous exploitez. En ligne de commande :

wp core version

Sans elle, lisez la version dans le tableau de bord sous Tableau de bord, puis Mises à jour, ou dans l'encadré D'un coup d'œil. Pour examiner la réponse HTTP du répertoire de décompactage, interrogez-le depuis une machine que vous contrôlez, avec votre propre site :

curl -s -o /dev/null -w "%{http_code}\n" https://your-site.example/wp-content/upgrade/

La réponse du répertoire ne suffit pas à déterminer si les fichiers PHP décompactés sont accessibles. Un code 200 peut correspondre à une page d’index ; un 403 ou 404 ne prouve pas que les fichiers individuels sont bloqués. Vérifiez la configuration du serveur et installez une version corrigée.

Comment corriger ?

Mettez à jour chaque site vers la version corrigée de sa branche, ou vers 7.1.4 :

1. Sauvegardez le site et sa base de données.
2. Mettez à jour depuis le tableau de bord : Tableau de bord, Mises à jour, Mettre à jour maintenant. WordPress 7.1.4 est une publication de sécurité, donc les sites avec mises à jour automatiques en arrière-plan la reçoivent automatiquement, comme l'indique la note de publication.
3. Ou mettez à jour en ligne de commande :

wp core update

Pour rester sur la branche 7.0, utilisez plutôt cette commande à la place de la précédente :

wp core update --version=7.0.8

Utilisez la version corrigée de votre branche indiquée dans le tableau ; n’exécutez pas les deux commandes.

1. Après la mise à jour, supprimez tout résidu sous wp-content/upgrade/ que le programme de mise à jour n'a pas nettoyé lui-même.

Pour les sites qui ne peuvent pas encore mettre à jour, une solution de contournement ferme la condition d'accessibilité web :

1. Refusez l'accès web au répertoire de décompactage au niveau du serveur web. Pour nginx, dans le bloc server :

location ^~ /wp-content/upgrade/ { return 403; }

1. Pour Apache, dans la configuration du site ou le .htaccess :

RedirectMatch 403 ^/wp-content/upgrade/

La solution de contournement ne couvre que ce CVE. Elle bloque les fichiers décompactés par le web, donc ni l'installeur ni aucun autre fichier PHP décompacté ne s'exécute. Elle ne fait rien pour aucune autre faille, et elle doit rester en place jusqu'à ce que le site atteigne une version corrigée.

Le fichier index.php que le WordPress corrigé écrit dans le répertoire de mise à jour n'empêche que le listage du répertoire. Les requêtes directes vers le nom aléatoire du répertoire de travail fonctionnent toujours, c'est pourquoi un bloc au niveau du serveur est plus fort.

Quelle est la cause racine ?

Le programme de mise à jour décompacte chaque mise à jour du cœur dans un répertoire de travail dont le nom dérive du seul nom de fichier du paquet, dans un répertoire que le serveur web sert. Dans WordPress 7.1.3, WP_Upgrader::unpack_package() construit le chemin à partir du paquet sans rien d'imprévisible, dans wp-admin/includes/class-wp-upgrader.php ligne 378 :

$upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';
// ...
// We need a working directory - strip off any .tmp or .zip suffixes.
$working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );

Un paquet de mise à jour du cœur nommé wordpress-7.1.4.zip est donc décompacté vers wp-content/upgrade/wordpress-7.1.4, un chemin qu'un attaquant peut calculer avant le début de la mise à jour. Le paquet contient l'arborescence WordPress complète, y compris wp-admin/setup-config.php, l'assistant d'installation.

L'assistant est la deuxième moitié de la faille. setup-config.php refuse de s'exécuter uniquement lorsqu'un fichier wp-config.php existe déjà à côté de lui, dans wp-admin/setup-config.php lignes 58 à 60 :

// Check if wp-config.php has been created.
if ( file_exists( ABSPATH . 'wp-config.php' ) ) {
    wp_die(

Un paquet de publication embarque wp-config-sample.php, pas wp-config.php, donc l'arborescence décompactée ne déclenche jamais cette garde. Une requête non authentifiée vers l'assistant décompacté pendant la fenêtre de mise à jour l'exécute. Il écrit un wp-config.php dans l'arborescence de décompactage à partir des valeurs du formulaire soumis : nom de base, utilisateur, mot de passe, hôte et préfixe de table. WordPress 7.1.4 a changé les trois maillons de cette chaîne, comme la section suivante le montre.

Comment la faille est-elle exploitée ?

L'attaquant interroge en boucle le chemin de décompactage prévisible pour l'assistant décompacté jusqu'à ce que le site décompacte une mise à jour, gagne la course de quelques secondes et transforme l'assistant décompacté en exécution de code. Aucun code de preuve de concept n'est public, et Wordfence n'a publié que les schémas de requêtes bloqués ; les étapes viennent du code source concerné, du correctif et de la description de Wordfence :

1. L'attaquant calcule le chemin de décompactage pour la version que sa cible s'apprête à installer, par exemple /wp-content/upgrade/wordpress-7.1.4/, et l'interroge en boucle pour wp-admin/setup-config.php. Wordfence a vu deux sources interroger de petits groupes de sites pendant environ 14,5 heures, et d'autres tester de nombreuses variantes de répertoires et de noms de versions.
2. Quand le programme de mise à jour du site décompacte le paquet, les sondes commencent à atteindre l'assistant décompacté. La fenêtre ne dure que quelques secondes en laboratoire, donc l'attaque est un sondage répété, pas une requête isolée forgée.
3. L'assistant décompacté s'exécute, car l'arborescence décompactée ne contient pas de wp-config.php. L'attaquant complète son formulaire avec des réglages de base de données pointant vers une base qu'il contrôle, et l'assistant écrit ces réglages dans un wp-config.php à l'intérieur de l'arborescence de décompactage.
4. L'attaquant interagit ensuite avec la copie WordPress décompactée contre sa propre base de données, comme le décrit Wordfence. Par les écrans d'administration décompactés, qui comprennent l'ajout d'extensions et de thèmes, il progresse vers l'exécution de PHP.
5. Par ailleurs, avant 7.1.4, l'étape de copie de la mise à jour installait les fichiers du répertoire de travail à la racine du site en n'ignorant que wp-content et wp-includes/version.php. Un wp-config.php écrit par l'attaquant dans le répertoire de travail serait donc copié à la racine du site. Là, il s'exécute à chaque requête et pointe le site réel vers la base de données de l'attaquant.
6. WordPress supprime le répertoire de travail après la mise à jour, et la fenêtre se referme. Un échange de configuration ayant survécu à l'étape 5 persiste ; ce qui n'est resté que dans l'arborescence de décompactage, non.

Les conditions de succès de Wordfence correspondent à ces étapes :

• une mise à jour en paquet complet contenant les fichiers de l'installeur
• un accès web et PHP public à l'arborescence de décompactage
• un chemin de décompactage prévisible ou découvert
• assez de temps pour compléter l'attaque avant que WordPress ne nettoie les fichiers temporaires

Quel est le flux de l'attaque ?

Un attaquant non authentifié interroge en boucle le chemin de décompactage prévisible pendant une mise à jour du site, atteint l'assistant décompacté et en tire une exécution de code avant le nettoyage. Le contrôle manquant du flux est l'imprévisibilité que le répertoire de travail n'a jamais eue.

Que peut faire un attaquant ?

Un gagnant de la course exécute du PHP sur le serveur web, sous l'utilisateur du processus WordPress, pendant la fenêtre de mise à jour. Sur les versions avant 7.1.4, il peut aussi faire persister un échange de configuration au-delà de la fenêtre. L'attaque n'exige ni compte, ni privilèges, ni interaction de quiconque sur le site.

L'équipe sécurité de WordPress note la faille Low et Wordfence la note 8,1 High ; la différence est la course, que le vecteur enregistre comme complexité d'attaque High.

Ce qui est connu de l'usage réel est plus étroit. Wordfence a bloqué 62 969 requêtes ciblant la faille en 24 heures au 30 octobre 2026, ce sont des tentatives, pas des compromissions. Aucune compromission réussie n'a été signalée par Wordfence, par la presse ou par WordPress, et le CVE n'est pas dans le catalogue KEV au 31 octobre 2026.

La vitesse est l'histoire : des tentatives d'attaque massives sont arrivées deux jours après la sortie du correctif, alors que les sites achevaient leur passage à 7.1.4.

Pourquoi le correctif fonctionne-t-il ?

WordPress 7.1.4 casse la chaîne en trois points dans le commit b625b2d49c6a, « Upgrade/Install: Improve the handling of the upgrade working directory » :

        $upgrade_folder = $wp_filesystem->wp_content_dir() . 'upgrade/';

-       // Clean up contents of upgrade directory beforehand.
+       // Clean up contents of upgrade directory beforehand, keeping its index.php.
        $upgrade_files = $wp_filesystem->dirlist( $upgrade_folder );
        if ( ! empty( $upgrade_files ) ) {
            foreach ( $upgrade_files as $file ) {
+               if ( 'index.php' === $file['name'] ) {
+                   continue;
+               }
+
                $wp_filesystem->delete( $upgrade_folder . $file['name'], true );
            }
        }

-       // We need a working directory - strip off any .tmp or .zip suffixes.
-       $working_dir = $upgrade_folder . basename( basename( $package, '.tmp' ), '.zip' );
+       /*
+        * The upgrade directory is web-served. Keep it from being listed, as core does
+        * for wp-content and its plugins and themes directories, so the name of the
+        * working directory created below cannot be discovered from a directory index.
+        */
+       if ( ! $wp_filesystem->exists( $upgrade_folder . 'index.php' ) ) {
+           $wp_filesystem->put_contents( $upgrade_folder . 'index.php', "<?php\n// Silence is golden.\n", FS_CHMOD_FILE );
+       }
+
+       // We need a working directory.
+       $working_dir = $upgrade_folder . $this->get_working_dir_name( $package );

La nouvelle méthode privée ajoute un suffixe aléatoire :

    private function get_working_dir_name( $package ) {
        // Strip off any .tmp or .zip suffixes.
        $name = basename( basename( $package, '.tmp' ), '.zip' );

        return $name . '-' . wp_generate_password( 16, false );
    }

Le troisième changement est dans update-core.php, où la liste d'exclusion de l'étape de copie gagne le fichier que l'attaquant écrit :

-   $skip              = array( 'wp-content', 'wp-includes/version.php' );
+   $skip              = array( 'wp-content', 'wp-includes/version.php', 'wp-config.php' );

Le suffixe aléatoire supprime le chemin prévisible, qu'aucun attaquant ne peut calculer à l'avance. Le fichier index.php supprime l'index du répertoire comme moyen de découvrir le nom aléatoire. L'entrée dans la liste d'exclusion signifie que même un attaquant qui trouve le répertoire ne peut plus faire installer son wp-config.php à la racine du site.

Le correctif est complet pour cette chaîne dans le programme de mise à jour, et chaque rétroportage de branche porte les trois mêmes changements. Il ne supprime pas l'accès web au répertoire de mise à jour lui-même. C'est pourquoi le bloc au niveau du serveur de « Comment corriger ? » reste une défense en profondeur utile.

Comment vérifier si j'ai été compromis ?

Fouillez les journaux d'accès de votre serveur web pour le schéma de requêtes de cette attaque. Sur nginx, le journal par défaut consigne une ligne par requête avec le chemin :

# Nginx: requests to PHP files under the staging path, case-insensitive; decode encoded paths separately.
grep -iE "wp-content/upgrade/[^ ]+\.php" /var/log/nginx/access.log

Sur Apache, remplacez le chemin de votre journal d'accès. Un chemin de décompactage dans la requête, setup-config.php en particulier, est la signature de cette faille :

# Apache: any request to the staged installer, on any version name.
grep -iE "wp-content/upgrade/.*/setup-config\.php" /var/log/apache2/access.log

Décodez les chemins encodés en pourcent avant de les juger, car Wordfence signale que les attaquants varient les graphies du répertoire et des noms de versions. Une requête légitime n'a aucune raison d'appeler ces chemins, donc toute occurrence mérite d'interroger l'adresse source et ce qui a suivi ; un résultat isolé est une piste, pas une preuve. Puis cherchez ce qu'une course gagnée laisse derrière elle :

# Any PHP file left in the staging tree.
find wp-content/upgrade -name "*.php" | sort

Un seul index.php contenant // Silence is golden. est ce que le WordPress corrigé écrit lui-même à cet endroit. Tout autre fichier PHP, et surtout un wp-config.php, est une piste à creuser. Wordfence conseille aussi de chercher des comptes administrateur inconnus, des extensions non installées par vous et des fichiers PHP non reconnus. Une attaque qui a échoué peut ne laisser aucune trace au-delà de la sonde elle-même.

Chronologie

• 2026-10-28 : WordPress publie 7.1.4 avec le commit correctif b625b2d49c6a, et rétroporte le correctif vers chaque branche de 7.0.8 à 4.7.39.
• 2026-10-29 : WordPress publie son avis GHSA-4w3m-c66w-69mg, qui note la condition de course Low, et crédite Umut Bayram de Picus Security.
• 2026-10-30 : The Hacker News rapporte le bilan de Wordfence : 62 969 attaques bloquées en 24 heures ; aucune compromission n'est signalée.
• 2026-10-31 : l'enregistrement CVE-2026-119977 est publié par Wordfence avec un score CVSS v3.1 de 8,1 High. La faille n'est pas dans le catalogue KEV de la CISA à cette date.

FAQ

Me mettre à jour vers 7.1.4 m'expose-t-il pendant cette mise à jour même ?

Oui, pendant les secondes que dure la mise à jour. Le code qui exécute une mise à jour est la version installée avant elle, donc la mise à jour vers 7.1.4 décompacte encore dans un chemin prévisible. Une attaque à cet instant suppose un attaquant interrogeant déjà votre site, ce que Wordfence a observé. Mettez à jour immédiatement plutôt que d'attendre, et gardez le bloc au niveau du serveur de « Comment corriger ? » pendant la fenêtre de changement.

Mon site exécute une vieille branche. Dois-je sauter vers 7.1.4 ?

Non. WordPress a rétroporté le correctif vers chaque branche jusqu'à 4.7, donc 7.0.8, 6.9.11 et tous les autres rétroportages du tableau des branches de « Suis-je concerné ? » portent les trois mêmes changements. Sauter de branche porte ses propres risques de compatibilité, donc le rétroportage de votre branche est le changement le plus petit.

Pourquoi WordPress et Wordfence divergent-ils sur la sévérité ?

WordPress note la condition de course sous-jacente Low, et l'enregistrement CVE de Wordfence la note 8,1 High avec une complexité d'attaque High. Les deux décrivent le même chemin non authentifié vers l'exécution de code ; la note Low pondère la fenêtre de quelques secondes, la note High l'impact de la gagner. Dans tous les cas, le correctif est le même et la télémétrie d'attaque est réelle.

Qu'a réellement observé Wordfence ?

Wordfence a bloqué 62 969 requêtes ciblant cette faille en 24 heures au 30 octobre 2026. Deux des plus grosses sources ont interrogé de petits groupes de sites pendant environ 14,5 heures, et d'autres sources ont essayé de nombreuses variantes de répertoires et de noms de versions. Ce sont des tentatives qu'un produit pare-feu a bloquées, pas des compromissions confirmées, et aucune victime n'a été signalée.

Les mises à jour automatiques suffisent-elles ?

Elles sont le mécanisme de livraison du correctif, et la note de publication confirme que les publications de sécurité s'appliquent automatiquement là où les mises à jour d'arrière-plan sont prises en charge. L'exposition qu'elles laissent est la fenêtre de mise à jour elle-même. Associez-les aux contrôles de journaux de cet article après la mise à jour, et au bloc au niveau du serveur si le répertoire de décompactage est accessible par le web.

Recensez vos déploiements WordPress avant que les attaquants ne les interrogent

Le scan agentique web d'Ostorlab recense vos applications web et leurs versions de framework. Il montre lesquels de vos sites exécutent WordPress 4.7.0 à 7.1.3, pour que vous les ameniez à une version corrigée avant la prochaine fenêtre de mise à jour.

Références

• Avis de sécurité WordPress GHSA-4w3m-c66w-69mg, « A race condition during core updates that could lead to remote code execution », publié le 29 octobre 2026, avec la matrice des versions corrigées par branche : https://github.com/WordPress/wordpress-develop/security/advisories/GHSA-4w3m-c66w-69mg (consulté le 31 octobre 2026)
• Enregistrement CVE-2026-119977, publié par le CNA Wordfence avec un CVSS v3.1 8.1 : https://www.cve.org/CVERecord?id=CVE-2026-119977 (consulté le 31 octobre 2026)
• Note de publication de WordPress 7.1.4, 28 octobre 2026, créditant Umut Bayram pour le signalement du processus de mise à jour : https://wordpress.org/news/2026/10/wordpress-7-1-4/ (consulté le 31 octobre 2026)
• Commit correctif b625b2d49c6a, « Upgrade/Install: Improve the handling of the upgrade working directory », dans WordPress 7.1.4 : https://github.com/WordPress/WordPress/commit/b625b2d49c6a (consulté le 31 octobre 2026)
• Source de WordPress 7.1.3, dérivation du répertoire de travail vulnérable dans WP_Upgrader::unpack_package() et garde de setup-config.php sur la configuration existante : https://raw.githubusercontent.com/WordPress/WordPress/7.1.3/wp-admin/includes/class-wp-upgrader.php et https://raw.githubusercontent.com/WordPress/WordPress/7.1.3/wp-admin/setup-config.php (consulté le 31 octobre 2026)
• Analyse Wordfence de la publication de sécurité 7.1.4, « WordPress 7.1.4 Patches Unauthenticated Upgrade-Window RCE; Exploitation Attempts Detected After Release », 29 octobre 2026 : https://www.wordfence.com/blog/2026/10/wordpress-7-1-4-security-release-rce/ (consulté le 31 octobre 2026)
• The Hacker News, « WordPress RCE Flaw Draws Nearly 63,000 Attack Attempts in Just 24 Hours », 30 octobre 2026, citant Alex Thomas de Wordfence et les 62 969 attaques bloquées : https://thehackernews.com/2026/10/wordpress-rce-flaw-draws-nearly-63000.html (consulté le 31 octobre 2026)
• Fiche de renseignement de menace Wordfence pour la RCE de fenêtre de mise à jour de WordPress Core 4.7-7.1.3 : https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-core/wordpress-core-470-713-unauthenticated-upgrade-window-staged-installer-remote-code-execution (consulté le 31 octobre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, flux JSON, recherché pour CVE-2026-119977 : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (consulté le 31 octobre 2026)
• Statistiques d'usage W3Techs pour WordPress, 39,5 % de tous les sites web et la répartition par version : https://w3techs.com/technologies/details/cm-wordpress (consulté le 31 octobre 2026)