WordPress : la course entre extraction et nettoyage pendant une mise à jour

Correctif du 28 octobre 2026 ; avis détaillé du 29 octobre. La vulnérabilité publiée par l’équipe WordPress apparaît pendant une opération qui semble sûre : la mise à jour du cœur. Lorsqu’une mise à jour utilise un paquet complet, les nouveaux fichiers étaient extraits dans un répertoire prévisible, à l’intérieur du dossier upgrade servi par le Web. Un attaquant sans compte pouvait, s’il gagnait une course contre l’extraction, atteindre une exécution de code sur le serveur. Le sujet n’est donc pas une « mise à jour malveillante » ; c’est l’exposition momentanée de fichiers légitimes pendant la procédure.

La frontière traversée par l’archive

Une mise à jour a besoin d’un espace de travail : recevoir une archive, l’extraire, vérifier ou déplacer les fichiers, puis nettoyer. Ces étapes ne sont pas atomiques. Entre deux opérations du serveur, un client HTTP peut envoyer des requêtes. Si l’espace temporaire est situé sous une racine publiée par le serveur Web, son contenu peut devenir adressable avant que WordPress ait fini de l’installer ou de le retirer.

L’avis officiel établit deux éléments spécifiques : le chemin d’extraction était prévisible et se trouvait dans un dossier servi par le Web. La combinaison donne à l’attaquant une cible temporelle et une route d’accès. La course est du type time of check to time of use : la sûreté attendue de la séquence globale ne vaut pas nécessairement pour chaque état intermédiaire visible par HTTP. La réussite dépend de l’instant où les fichiers existent et de la façon dont le serveur les traite ; l’avis ne donne pas une durée universelle de fenêtre ni une garantie de réussite à chaque tentative.

Ce point est plus subtil qu’un banal dépôt de fichier. L’attaquant ne doit pas nécessairement contrôler le paquet officiel ; il vise la présence transitoire de fichiers extraits dans un emplacement accessible. La publication WordPress affirme la possibilité de RCE, mais ne fournit pas dans son texte un PoC complet ni toutes les particularités de configuration qui conduisent de l’accès au fichier à l’exécution. Nous ne transformons pas cette conclusion en recette indépendante du serveur Web, de PHP et de la procédure d’upgrade.

Pourquoi une fenêtre courte reste pertinente

Une mise à jour n’a lieu que par moments, mais les installations WordPress sont nombreuses et les mises à jour automatiques peuvent être prévisibles à l’échelle d’une population de sites. Un acteur peut répéter les requêtes ou surveiller les signes d’une mise à jour en cours ; cela décrit la logique d’une attaque de course, pas un taux de succès mesuré pour cette faille. Le risque porte surtout sur les sites où le processus Web peut servir le dossier temporaire et où un paquet complet est utilisé, conditions explicitement mentionnées par WordPress.

Il existe un piège de lecture dans les identifiants : l’entrée GitHub de WordPress, publiée le 29 octobre, indiquait encore « No known CVE », tandis que des alertes ultérieures nomment CVE-2026-119977 et signalent une exploitation active. Ces documents ne décrivent pas deux failles distinctes ; ils reflètent une chronologie de référencement. Pour éviter une fausse précision, il faut dater l’affirmation et conserver le lien vers l’avis technique du projet.

Comment l’identifier dans un audit autorisé

La recherche commence par une cartographie des états de l’updater : chemins créés, permissions, répertoire temporaire, routage HTTP, extraction, renommage et suppression. On peut instrumenter une mise à jour sur un environnement de test et enregistrer, à chaque étape, quels fichiers sont atteignables depuis une session HTTP sans authentification. Un test différentiel entre version vulnérable et version corrigée doit montrer la disparition de l’état exposé. Pour établir la RCE, il faut ensuite démontrer le passage exact d’un fichier accessible à une exécution dans la configuration testée ; observer seulement une réponse HTTP sur un chemin temporaire ne suffit pas.

Ce protocole de recherche n’est pas attribué au découvreur. WordPress remercie Umut Bayram pour le signalement, mais l’avis ne donne pas toutes ses étapes expérimentales. L’enseignement généralisable est de tester les états transitoires d’une opération de maintenance, et pas uniquement son résultat final.

Correctif et contrôle opérationnel

La version 7.1.4 corrige la faille ; WordPress indique aussi des correctifs rétroportés jusqu’aux branches 4.7 affectées. Un contrôle utile relève la version du cœur réellement en production, le canal de mise à jour, les permissions et l’exposition HTTP du dossier de travail. Une mise à jour réussie aujourd’hui réduit l’exposition future ; elle ne prouve pas à elle seule qu’aucune requête n’a profité d’une mise à jour antérieure. Les journaux Web autour des créneaux d’upgrade et l’intégrité des fichiers restent les éléments à examiner en cas de soupçon.

La leçon dépasse WordPress : placer une étape temporaire dans un répertoire public transforme le temps en surface d’attaque. Le correctif doit supprimer l’état dangereux, et le test doit observer les instants intermédiaires où cet état pourrait réapparaître.

Sources principales : advisory WordPress, notes de WordPress 7.1.4, alerte NCSC-NL sur CVE-2026-119977.