WordPress, faille CVE-2026-119977 exploitée : mettre à jour le cœur en sécurité

Le 28 octobre 2026, WordPress a publié la version de sécurité 7.1.4, avec des correctifs reportés sur toutes les branches antérieures jusqu’à la 4.7. Le plus important concerne CVE-2026-119977 : pendant une mise à jour du cœur (core), un attaquant sans aucun compte qui intervient au bon moment peut parvenir à exécuter du code sur le serveur. Le 3 novembre, l’agence américaine CISA a inscrit la faille dans son catalogue des vulnérabilités exploitées (KEV), sur la base de preuves d’exploitation active.

Pour une PME tessinoise disposant d’un site WordPress, la conséquence pratique est simple : le site doit tourner sur la version corrigée, et il vaut la peine de vérifier que rien d’anormal ne s’est produit depuis le 28 octobre. Un détail distingue toutefois ce cas des situations habituelles : la faille se trouve dans le processus de mise à jour lui-même.

Ce qui s’est passé

Selon l’avis de sécurité de WordPress (GHSA-4w3m-c66w-69mg, 29 octobre 2026), lors d’une mise à jour du cœur avec un paquet complet, WordPress extrayait les nouveaux fichiers dans un dossier au nom prévisible à l’intérieur de wp-content/upgrade, accessible depuis le web. Celui qui gagne la « course » contre cette extraction, pendant les quelques instants où la copie temporaire existe, peut parvenir à exécuter du code. Les versions 4.7 à 7.1.3 sont concernées.

Les évaluations de gravité divergent, et il est utile de comprendre pourquoi :

• WordPress classe la faille en gravité faible, car la fenêtre exploitable est très courte.
• Wordfence, qui a attribué le CVE, lui donne un score CVSS 3.1 de 8.1 (élevé), selon la base NVD : la complexité d’attaque est élevée, mais si l’attaque réussit, l’impact sur le serveur est total.
• La CISA la considère comme activement exploitée et le Centre canadien pour la cybersécurité a diffusé un avis le 3 novembre.

Selon Wordfence, les premières tentatives ont commencé le jour même de la publication et son pare-feu en a bloqué plus de 240 000. Wordfence précise que réussir l’attaque est difficile en pratique : les tentatives automatisées répétées visent justement à saisir le bref moment de la mise à jour.

Le détail à connaître : la dernière mise à jour

Le correctif rend aléatoire le nom du dossier temporaire. Mais la mise à jour qui installe la 7.1.4 est encore exécutée par l’ancien code présent sur le site : selon Wordfence, le passage de la version vulnérable à la version corrigée ouvre donc la fenêtre une dernière fois, pendant la durée de la mise à jour. Ensuite, les mises à jour futures ne sont plus concernées.

Ce n’est pas une raison pour attendre : Wordfence recommande de mettre à jour au plus vite. Comme précaution supplémentaire, il conseille de bloquer, au niveau du serveur web, l’accès aux fichiers PHP du dossier /wp-content/upgrade/ avant la mise à jour. WordPress écrit dans ce dossier directement sur le système de fichiers ; bloquer l’accès web n’empêche donc pas la mise à jour.

Versions corrigées

Versions indiquées comme corrigées dans l’avis de WordPress (extrait ; la liste complète couvre toutes les branches jusqu’à la 4.7) :

WordPress rappelle que seule la version la plus récente est activement maintenue : qui est encore sur une ancienne branche devrait planifier le passage à la 7.1.

Que faire avec son site WordPress

1. Vérifier la version. Dans le tableau de bord, rubrique Mises à jour, ou en demandant au prestataire. Elle doit indiquer la 7.1.4 ou la version corrigée de votre branche. Les mises à jour automatiques en arrière-plan l’ont en principe déjà installée, mais il faut le contrôler : elles n’aboutissent pas toujours.
2. Si le site n’est pas encore à jour : sauvegarder fichiers et base de données, demander à qui gère le serveur de bloquer l’accès web aux fichiers PHP de /wp-content/upgrade/, puis mettre à jour immédiatement.
3. Rechercher des signes de compromission depuis le 28 octobre. Dans les journaux d’accès du serveur, des requêtes abouties vers /wp-content/upgrade/ ; dans le tableau de bord, des comptes administrateur inconnus ; sur le serveur, des fichiers PHP inattendus ou des modifications non planifiées de wp-config.php. Pour ses propres agences, la CISA exige justement une vérification forensique pour cette faille.
4. En cas d’indices : considérer le site comme compromis, l’isoler, changer les identifiants (administrateurs, base de données, clés API), restaurer une sauvegarde saine antérieure au 28 octobre et faire analyser le serveur. La mise à jour seule n’élimine pas ce qu’un attaquant aurait déjà installé.
5. Extensions, thèmes et PHP. Profiter de l’intervention pour mettre à jour extensions et thèmes et vérifier la version de PHP : en octobre, des failles critiques de PHP et plusieurs extensions WordPress ont aussi été corrigées.

Nous ne publions pas de détails sur l’exploitation de la faille : l’objectif est de fermer l’exposition et de vérifier les systèmes.

Si le site a été compromis : signalements

• Protection des données (nLPD). Si le site ou le serveur contient des données personnelles (formulaires de contact, comptes clients, commandes) et que la violation entraîne vraisemblablement un risque élevé pour les personnes concernées, l’article 24 de la loi sur la protection des données prévoit l’annonce au PFPDT dans les meilleurs délais. Le guide du PFPDT explique comment évaluer et annoncer le cas.
• OFCS. Pour la plupart des PME, signaler un cyberincident à l’OFCS est volontaire mais utile. Depuis le 1er avril 2025, les exploitants d’infrastructures critiques ont en revanche l’obligation de signaler les cyberattaques dans les 24 heures suivant leur découverte.
• Dommage financier. En cas de dommage, déposer plainte auprès de la police cantonale.

Questions fréquentes

Notre site se met à jour tout seul : devons-nous faire quelque chose ?

Selon Wordfence, les sites avec mises à jour automatiques activées devraient déjà être sur une version corrigée. Il reste utile de vérifier la version installée et de consulter les journaux depuis le 28 octobre, car la dernière mise à jour est passée par l’ancien code.

Pourquoi WordPress la juge faible et la CISA exploitée ?

Les deux évaluations regardent des choses différentes : WordPress pèse la difficulté d’atteindre la courte fenêtre de mise à jour, la CISA la présence de tentatives d’exploitation réelles. Pour qui gère un site, la conclusion est la même : mettre à jour et vérifier.

Notre site est géré par une agence : que lui demander ?

Trois questions suffisent : quelle version de WordPress est installée, si l’accès web à /wp-content/upgrade/ est bloqué et si les journaux depuis le 28 octobre ont été contrôlés. Demandez une réponse écrite.

Nous avons un pare-feu ou une extension de sécurité : sommes-nous protégés ?

Pas forcément. Wordfence explique que l’attaque vise des fichiers qui ne chargent pas WordPress ; une extension de sécurité interne au site ne les voit donc que dans certaines configurations. Le blocage au niveau du serveur web et la mise à jour restent les mesures principales.

Notre approche

ElaraTeq Sagl aide les PME et cabinets au Tessin à mettre à jour et vérifier leurs sites WordPress, à configurer leur serveur web et à héberger en Suisse (hébergement, conseil). Pour faire contrôler votre site, vous pouvez nous contacter.

Sources

• WordPress, WordPress 7.1.4, 28 octobre 2026
• WordPress, GHSA-4w3m-c66w-69mg: A race condition during core updates that could lead to remote code execution, 29 octobre 2026
• NIST NVD, CVE-2026-119977
• CISA, CISA Adds One Known Exploited Vulnerability to Catalog, 3 novembre 2026
• Centre canadien pour la cybersécurité, WordPress security advisory (AV26-1117), 3 novembre 2026
• Wordfence, Attackers Actively Probing for Upgrade-Window RCE Vulnerability in WordPress Core, novembre 2026
• OFCS, Obligation de signaler les cyberattaques contre des infrastructures critiques
• PFPDT, Guide sur la notification des violations de la sécurité des données