WordPress 7.1.4 : la faille exploitée pendant la mise à jour de votre site

Publié le 6 novembre 2026 · L'équipe mitza.es

Le 28 octobre 2026, WordPress a publié la version 7.1.4, une mise à jour de sécurité qui corrige une faiblesse dans le processus de mise à jour du cœur lui-même. Six jours plus tard, le 3 novembre, l'agence américaine CISA a ajouté la faille, identifiée comme CVE-2026-119977, à son catalogue des vulnérabilités activement exploitées (KEV). Autrement dit : ce n'est plus un risque théorique. Nous résumons ce qui est confirmé au 6 novembre 2026 et ce qui ne l'est pas encore.

Ce qui s'est passé, étape par étape

• 28 octobre : WordPress.org publie la 7.1.4 comme version de sécurité. L'annonce décrit « une faiblesse dans le processus de mise à jour de WordPress pouvant conduire à l'exécution de code à distance pendant la fenêtre de mise à jour » et l'attribue à Umut Bayram, le chercheur qui l'a signalée.
• 3 novembre : CISA inclut CVE-2026-119977 dans le catalogue KEV, « sur la base de preuves d'exploitation active ». La date limite qu'elle fixe pour les agences fédérales américaines est le 6 novembre.
• Avant l'alerte : selon l'analyse de SOC Prime, qui s'appuie sur la télémétrie de honeypots publiée par The Hacker News, des tentatives d'exploitation ont eu lieu dès le 30 octobre. Ce sont des tentatives enregistrées, pas des attaques réussies confirmées.

Une précision : l'annonce de WordPress.org ne cite pas le numéro de CVE. Le lien entre cet avis et CVE-2026-119977 s'établit par la description de la faille et par le chercheur qui l'a signalée ; CISA renvoie vers la version 7.1.4 dans sa propre fiche.

Ce qu'est exactement cette faille

CISA la classe comme une condition de concurrence de type time-of-check time-of-use (TOCTOU, CWE-367) et explique qu'elle pourrait permettre à des attaquants non authentifiés d'exécuter du code sur le serveur pendant la « fenêtre de mise à jour ». La cause qu'elle cite est technique, mais facile à comprendre avec une analogie :

Quand WordPress met à jour son cœur avec un paquet complet, il télécharge les nouveaux fichiers et les prépare dans une zone intermédiaire avant de remplacer les anciens. Selon CISA, ces chemins de préparation étaient prévisibles et accessibles depuis le web. C'est comme si, pendant que vous changez la serrure de votre porte, vous laissiez la boîte contenant les nouvelles clés sur le paillasson pendant quelques minutes : le danger n'existe pas le reste de l'année, mais pendant ces minutes, quiconque passe par là peut en profiter.

D'après ce qui a été publié, le risque se concentre sur cet intervalle, et SOC Prime évalue la complexité de l'attaque comme élevée (score CVSS 3.1 de 8,1 selon son analyse ; nous n'avons pas pu le recouper dans la base de données NVD). Ce n'est pas une raison d'attendre : le correctif est disponible et WordPress recommande de mettre à jour immédiatement.

Versions concernées

SOC Prime indique que la faille touche WordPress de la version 4.7 à la 7.1.3, et que la correction a été reportée sur les anciennes branches qui reçoivent encore des correctifs de sécurité. WordPress.org confirme ce dernier point : les corrections ont été portées « sur toutes les branches éligibles aux correctifs de sécurité (actuellement jusqu'à la 4.7) », mais prévient que ces anciennes versions sont publiées au fur et à mesure qu'elles sont prêtes. Si votre site est sur une ancienne branche, vérifiez dans le panneau des mises à jour si la version de votre branche est déjà disponible ou, après avoir fait une sauvegarde et un test, passez à la 7.1.4.

Que faire dès aujourd'hui : la checklist

1. Vérifiez votre version. Dans l'administration, allez dans Tableau de bord → Mises à jour. Si ce n'est pas la 7.1.4 (ou la correction de votre branche), mettez à jour.
2. Faites une sauvegarde avant de mettre à jour, sans retarder la mise à jour pour autant. Si vous n'avez pas de système en place, nous expliquons ici la règle 3-2-1 des sauvegardes.
3. Ne supposez pas que la mise à jour automatique s'est bien terminée. WordPress.org indique que, sur les sites avec mises à jour en arrière-plan, le processus démarre tout seul. Vérifiez dans l'administration que la version est la bonne et qu'il n'y a pas d'avis de mise à jour échouée.
4. Interrogez votre hébergeur. Certains fournisseurs de WordPress géré mettent à jour à votre place. Demandez-lui de confirmer par écrit la version et la date.
5. Cherchez une activité inhabituelle si votre site a effectué une mise à jour du cœur ces dernières semaines : administrateurs que vous ne reconnaissez pas, fichiers nouveaux ou modifiés à la racine et dans wp-content, modifications de wp-config.php ou de .htaccess. Selon SOC Prime, les requêtes observées visaient des chemins temporaires de l'installateur (comme setup-config.php) ; vous pouvez donc aussi rechercher ces chemins dans les journaux d'accès de votre serveur.
6. Changez les identifiants en cas de doute (administrateurs, base de données, SFTP) et passez en revue les extensions installées : supprimez celles que vous n'utilisez pas.
7. Notez la date et les actions menées. Si des données personnelles étaient concernées, cette chronologie vous servira à évaluer avec votre conseiller s'il faut notifier l'AEPD (l'Agence espagnole de protection des données).

Deux nuances honnêtes : la fiche de CISA indique que l'on ignore si la faille est utilisée dans des campagnes de ransomware et qu'elle exige un tri forensique selon sa directive BOD 26-04, destinée aux agences fédérales américaines. Pour une PME, la traduction pratique est la suivante : si votre site a mis à jour son cœur ces dernières semaines avec une version vulnérable, il mérite une vérification, pas seulement un correctif.

Si vous pensez que votre site est déjà compromis

Des signes comme des redirections étranges, des pages que vous n'avez pas créées, de nouveaux utilisateurs, des alertes de Google ou un hébergeur qui suspend le compte sont des raisons d'agir avec méthode. Nous avons préparé un guide pas à pas : mon site WordPress est piraté : que faire, signes, nettoyage et prévention. Pour une vérification professionnelle, notre audit de sécurité web contrôle les versions, les utilisateurs, les fichiers et la configuration du serveur.

Pourquoi cela se répète et comment réduire le risque

Elle s'ajoute à d'autres alertes graves de WordPress que nous avons relayées cet automne : la faille CVE-2026-87902 dans la 7.1.2, la famille wp2shell et les extensions exploitées en octobre. WordPress fait tourner une part énorme d'internet, c'est donc la cible la plus rentable. Cela ne veut pas dire qu'il ne faut pas l'utiliser ; cela veut dire qu'on ne peut pas le laisser sans maintenance.

• Tenez un calendrier de mises à jour du cœur, des extensions et du thème, avec un délai maximal pour les correctifs critiques.
• Utilisez un environnement de test (staging) pour répéter les mises à jour importantes avant de les appliquer en production.
• Mettez en place un pare-feu applicatif web (WAF) : il réduit les tentatives, mais ne remplace pas la mise à jour, car la faille est dans WordPress lui-même. Si vous voulez comprendre la première ligne de défense, lisez qu'est-ce qu'un pare-feu et de quoi une PME a besoin.
• Activez la vérification en deux étapes et des mots de passe uniques pour tous les administrateurs.
• Déléguez la maintenance si ce n'est pas votre métier : vous trouverez le détail de ce qu'elle comprend dans maintenance de site web : ce qu'elle comprend et ce qu'elle coûte.

Questions rapides

Suis-je concerné si mon WordPress est hébergé sur WordPress.com ?

Les avis que nous avons consultés parlent d'installations WordPress qui mettent à jour leur propre cœur. Si votre site est sur une plateforme gérée, demandez à votre fournisseur s'il a déjà appliqué la correction ; nous n'avons pas trouvé de déclaration spécifique de WordPress.com à ce sujet.

Désactiver des extensions sert-il à quelque chose ?

Pas pour cette faille : elle se trouve dans le cœur, pas dans une extension. La mesure efficace est de passer à la version corrigée.

Dois-je m'inquiéter si j'ai déjà mis à jour ?

Si votre site a mis à jour son cœur avant le 28 octobre, cette mise à jour a été effectuée par une version vulnérable ; le risque concret dépend de savoir si quelqu'un a attaqué à ce moment précis. Une vérification rapide des utilisateurs et des fichiers s'impose. Si vous avez mis à jour après, vérifiez seulement que la version est la bonne.

Comment Mitza peut vous aider

Nous mettons à jour et examinons WordPress dans le cadre de notre service de maintenance de site web, avec sauvegardes, tests préalables et alerte en cas de problème. Si vous préférez commencer par savoir dans quel état se trouve votre site, exposez-nous votre cas depuis la page de contact.

À lire aussi : le zero-day d'Ivanti Connect Secure et la maintenance informatique pour PME.