Rapport CTI technique du 4 novembre 2026

Résumé exécutif

WordPress Core est exposé à une vulnérabilité TOCTOU, référencée CVE-2026-119977. Pendant la mise à niveau complète du cœur, WordPress utilise des chemins de staging prévisibles et accessibles depuis le web. Un attaquant non authentifié peut exécuter du code à distance sur le serveur. Les versions 4.7 à 7.1.3 sont affectées. L'éditeur a publié WordPress 7.1.4 en octobre 2026. Il rétroporte le correctif sur toutes les branches éligibles, actuellement jusqu'à la 4.7.

La CISA a ajouté la vulnérabilité au catalogue KEV le 3 novembre 2026. L'échéance de remédiation est fixée au 6 novembre 2026, conformément à la directive BOD 26-04. L'exploitation est active. Wordfence signale des blocages massifs et la presse évoque plus de 60 000 attaques bloquées en 24 heures. Le chercheur Umut Bayram est crédité pour le signalement responsable.

Chronologie

Date	Événement
Octobre 2026	Publication de WordPress 7.1.4, correctif de sécurité incluant la correction de la faille d'upgrade
31 octobre 2026	Premières couvertures presse : Rescana, GBHackers et Cyber Press signalent une exploitation active
2 novembre 2026	RS Web Solutions relaie le chiffre de plus de 58 000 tentatives d'exploitation bloquées
3 novembre 2026	Ajout de la CVE-2026-119977 au catalogue CISA KEV
4 novembre 2026	The Hacker News indique que la CISA confirme l'exploitation de la faille
6 novembre 2026	Échéance de remédiation CISA (BOD 26-04)

Fiche vulnérabilité

CVE-2026-119977 | CVSS 8.1 (Élevée, vecteur non fourni) | WordPress Core

Le processus de mise à niveau complète du cœur ouvre la faille. Lors d'une mise à niveau full-package, WordPress télécharge le paquet de la nouvelle version. Il le décompresse dans un répertoire de staging temporaire, sous la racine web. Puis il remplace les fichiers de l'installation. Ce répertoire suit un chemin prévisible et reste accessible via HTTP, sans authentification. La race condition TOCTOU survient entre la vérification de l'état du répertoire et son utilisation. Un attaquant non authentifié qui connaît ce chemin peut y déposer des fichiers PHP malveillants pendant la fenêtre de mise à niveau. Ces fichiers sont ensuite exécutés par le serveur web, avec les privilèges du processus serveur. Résultat : une exécution de code à distance.

Les références de code pointent vers class-core-upgrader.php, class-wp-upgrader.php, update-core.php et setup-config.php en version 7.1.3. En 7.1.4, les lignes modifiées concernent class-wp-upgrader.php et update-core.php. La correction déplace ou modifie la gestion du chemin de staging pour supprimer l'accès web non authentifié.

Version	Statut	Détail
4.7 à 7.1.3	Affectée	Exécution de code à distance non authentifiée pendant la fenêtre de mise à niveau
7.1.4	Corrigée	Publication de sécurité d'octobre 2026
Branches 4.7 et ultérieures éligibles	Rétroportage	Correctifs publiés progressivement selon l'éditeur

Conditions d'exploitation : accès réseau au serveur web, aucune authentification requise, aucune interaction utilisateur côté victime. Condition principale : la cible doit être en train d'effectuer une mise à niveau complète du cœur. C'est cette fenêtre temporelle qui rend la race condition exploitable. L'attaquant doit agir pendant cette phase.

Aucun PoC public n'est documenté dans les sources fournies. En revanche, l'exploitation active constatée par Wordfence et l'ajout au catalogue CISA KEV montrent que des exploits opérationnels circulent en conditions réelles.

L'ajout au catalogue CISA KEV le 3 novembre 2026 confirme l'exploitation observée. Wordfence a bloqué plus de 60 000 attaques en 24 heures, selon Cyber Press. GBHackers et RS Web Solutions évoquent plus de 58 000 tentatives bloquées. The Hacker News, le 4 novembre 2026, indique que la CISA confirme l'exploitation pendant les mises à niveau logicielles. Les données CISA KEV ne précisent pas si un rançongiciel exploite la faille.

Diagramme de la chaîne d'attaque

Chaîne d'attaque de CVE-2026-119977 (WordPress Core) — *Chaîne d'attaque de la race TOCTOU lors d'une mise à jour. Sources : wordpress.org, CISA KEV, NVD.*

Analyse technique

Étape 1 : Accès initial au chemin de staging prévisible

L'attaquant identifie ou devine le chemin de staging. WordPress l'utilise pendant les mises à niveau complètes. Ce chemin est prévisible et servi par le serveur web, sans exigence d'authentification. Aucune session administrative n'est requise. L'accès initial s'effectue directement par requête HTTP vers le répertoire de staging.

Étape 2 : Fenêtre TOCTOU et dépôt de la charge

Pendant la mise à niveau, le répertoire de staging est créé, puis peuplé de fichiers avant leur bascule vers l'installation. La faille TOCTOU tient à l'écart entre le contrôle de l'état du répertoire et son utilisation effective. L'attaquant exploite cet intervalle. Il y dépose un fichier PHP malveillant.

Étape 3 : Exécution de code distante

Le fichier déposé est accessible via le serveur web. Une simple requête HTTP suffit à déclencher son exécution. Le code s'exécute avec les privilèges du processus serveur web. Il peut alors exécuter des commandes, lire des fichiers ou modifier l'installation WordPress.

Étape 4 : Persistance et post-exploitation

Une fois l'exécution obtenue, l'attaquant peut installer un web shell dans le répertoire web. Objectif : conserver un accès durable. Les traces résiduelles incluent des fichiers PHP non attendus dans les répertoires de staging, des requêtes HTTP inhabituelles et des processus enfants anormaux lancés par le serveur web.

Exposition

Tout site WordPress en version 4.7 à 7.1.3 est exposé pendant la mise à niveau complète du cœur. Cela vaut pour les installations auto-hébergées comme pour les déploiements hébergés, dès lors que le serveur web sert le répertoire de staging sur Internet. Les mises à jour automatiques en arrière-plan élargissent la fenêtre, sans intervention manuelle. Les sites non exposés à Internet restent vulnérables à un attaquant disposant d'un accès réseau interne.

Indicateurs de compromission

Aucun IOC public documenté à ce jour.

Pistes de détection :

Journaliser et alerter sur les requêtes HTTP vers les répertoires de staging ou de mise à niveau pendant les fenêtres de mise à niveau.
Surveiller les accès non authentifiés vers setup-config.php et les fichiers du processus d'upgrade.
Contrôler l'intégrité des fichiers du répertoire de staging : tout fichier PHP non attendu doit déclencher une alerte.
Détecter les processus enfants anormaux lancés par le serveur web pendant une mise à niveau.
Activer les règles IDS/IPS de Wordfence ou d'un outil équivalent couvrant les chemins de staging prévisibles.
Rechercher les tentatives répétées d'accès à des chemins de staging sur plusieurs sites, signe d'un scan automatisé.

MITRE ATT&CK

Cartographie analytique, aucune cartographie officielle fournie par les sources.

Tactique	Technique	ID	Justification
Initial Access	Exploit Public-Facing Application	T1190	Accès non authentifié au chemin de staging web-accessibles
Command and Control	Ingress Tool Transfer	T1105	Dépôt de la charge malveillante dans le répertoire de staging
Execution	Command and Scripting Interpreter	T1059	Exécution du code PHP déposé sur le serveur
Persistence	Server Software Component: Web Shell	T1505.003	Installation d'un web shell pour maintenir l'accès

Remédiation : checklist opérationnelle

Appliquer WordPress 7.1.4, ou le rétroportage de sécurité correspondant pour les branches 4.7 à 7.1.x. Prioriser les sites exposés sur Internet. Échéance CISA : 6 novembre 2026.
Activer les mises à jour automatiques en arrière-plan pour appliquer les correctifs de sécurité sans délai.
Restreindre au niveau du serveur web l'accès aux répertoires de staging et de mise à niveau, par des règles de refus explicites sur ces chemins temporaires.
Déployer ou mettre à jour les règles WAF/IDS couvrant les chemins de staging prévisibles, notamment via Wordfence ou un équivalent.
Auditer les journaux d'accès pour repérer les requêtes vers les chemins de staging pendant les fenêtres de mise à niveau.
Vérifier l'absence de fichiers PHP non attendus dans les répertoires web et de staging, et contrôler l'intégrité du cœur WordPress.
Si le correctif ne peut pas être appliqué immédiatement, évaluer l'isolement du site ou la suspension des mises à niveau automatiques jusqu'à l'application, conformément à la directive BOD 26-04. En dernier recours, cesser l'utilisation du produit si aucune atténuation n'est disponible.