TechPastWeek logo
Sécurité8 min de lecture

WordPress corrige Comment2Shell, une faille dans les commentaires menant à la prise de contrôle du serveur

WordPress 7.1.1 a corrigé une faille de script intersite stocké non authentifiée dans wpautop(), référencée CVE-2026-93485, qui peut mener à l'exécution de code à distance.

Une capture d'écran du tableau de bord d'administration de WordPress montrant les panneaux Tableau de bord, Santé du site, En un coup d'œil et Brouillon rapide.
Sur cette page

À retenir

  • WordPress 7.1.1, publié le 17 septembre 2026, a corrigé une faille de script intersite stocké non authentifiée dans la fonction wpautop(), référencée CVE-2026-93485.
  • La faille a un score CVSS 3.1 de 7.1 et est accessible à un visiteur anonyme par un simple commentaire, sans compte requis.
  • Comme les scripts des commentaires s'exécutent dans le navigateur des administrateurs connectés, la faille peut passer d'un commentaire à l'exécution de code à distance sur le serveur.
  • Patchstack indique que le problème se reproduit sur les installations par défaut, car la modération manuelle des commentaires est désactivée par défaut et la protection liée aux commentateurs déjà approuvés peut être contournée.
  • WordPress a rétroporté le correctif vers d'anciennes branches jusqu'à la version 4.7, et rien n'indiquait d'exploitation active au moment de la publication.

WordPress a publié la version 7.1.1 le 17 septembre 2026, et ce n'est pas la mise à jour de maintenance de routine que son numéro de version laisse imaginer. La sortie comporte onze correctifs de sécurité en plus de ses corrections de bugs, et le plus grave d'entre eux est une faille de script intersite stocké qu'un visiteur anonyme peut déclencher par un commentaire ordinaire. La vulnérabilité, référencée CVE-2026-93485, a été surnommée Comment2Shell en raison de ce à quoi elle peut mener : d'un commentaire dans une file de modération jusqu'à du code exécuté sur le serveur.

À lire aussi: Check Point corrige deux failles VPN de gravité 9,8 permettant une exécution de code non authentifiée · SAP corrige une faille du noyau notée CVSS 10.0 qui ne demande aucun identifiant.

La faille réside dans wpautop(), la fonction de WordPress qui convertit les sauts de ligne d'un texte en balisage de paragraphes. WordPress y fait passer le texte des commentaires avant l'affichage, et le bug permet à un visiteur sans compte d'injecter du script qui franchit le nettoyeur de commentaires du site, wp_kses(), car rien dans la charge utile ne ressemble au balisage que ce nettoyeur est censé supprimer. Le script ne devient dangereux que plus tard, lorsque le commentaire est affiché et que les filtres d'affichage réorganisent le texte.

La vulnérabilité a été signalée par le chercheur en sécurité Rafie Muhammad, d'Awesome Motive, dans le cadre du programme de divulgation de vulnérabilités de Patchstack le 15 septembre 2026. WordPress a publié le correctif deux jours plus tard, et Patchstack l'a ajouté à sa base de données le 18 septembre. La sortie complète comprenait 17 corrections de bugs du cœur et 21 corrections de l'éditeur de blocs, en plus du travail de sécurité.

Ce qui rend cette faille différente

WordPress publie régulièrement des correctifs de sécurité, et la plupart exigent un certain niveau d'accès pour être exploités. Pas celle-ci. CVE-2026-93485 est notée 7.1 sur l'échelle CVSS 3.1, avec un vecteur accessible par le réseau, de faible complexité, sans privilèges requis, et nécessitant qu'une personne consulte la charge utile. C'est le seul des onze problèmes de la sortie qu'un attaquant sans compte peut atteindre ; la plupart des autres exigent un utilisateur connecté disposant au moins d'un accès contributeur.

L'analyse de Patchstack est sans détour sur la protection de modération. Les notes de version de WordPress décrivent la faille comme soumise à l'approbation des commentaires, ce qui semble rassurant. La fiche CVE l'est moins : elle indique que le problème se reproduit sur une installation par défaut, car la modération manuelle des commentaires est désactivée par défaut et parce que le réglage qui retient un commentateur pour la première fois en vue d'une vérification peut être contourné. Autrement dit, une charge utile peut atteindre la file de modération sur un site standard, et un attaquant dont un commentaire a déjà été approuvé est approuvé automatiquement par la suite.

Si une faille de commentaire compte plus qu'il n'y paraît, c'est à cause de qui lit les commentaires. Les visiteurs les voient, mais aussi les modérateurs et les administrateurs. Un script qui s'exécute dans le navigateur connecté d'un administrateur peut agir avec les permissions de cet administrateur, et à partir de là un attaquant peut créer un nouveau compte administrateur et l'utiliser pour exécuter du code sur le serveur. Le nom Comment2Shell décrit cette chaîne plutôt que le commentaire lui-même.

La fenêtre, c'est le correctif

WordPress est un logiciel libre, donc chacun peut comparer la 7.1.1 avec la 7.1 et voir exactement ce qui a changé dans le code de mise en forme. Les chercheurs en sécurité considèrent le correctif lui-même comme la divulgation, ce qui explique pourquoi le délai entre la publication d'un correctif et le début de l'exploitation tend à être court.

L'écart entre le nettoyage et l'affichage

La faille illustre pourquoi le filtrage des entrées est difficile. WordPress nettoie un commentaire au moment de son enregistrement, en utilisant wp_kses() pour retirer tout ce qui ressemble à du balisage exécutable, puis le reformate au chargement de la page, en utilisant wpautop() pour transformer les sauts de ligne en paragraphes. La vulnérabilité se loge dans l'espace entre ces deux étapes. Une charge utile qui franchit le nettoyeur n'est pas dangereuse en soi ; elle le devient quand le filtre d'affichage réorganise le texte et que le navigateur interprète le résultat comme une balise.

L'analyse de Patchstack montre que le correctif rend l'expression dans wpautop() sensible aux guillemets, de sorte qu'un chevron fermant à l'intérieur d'une valeur entre guillemets n'est plus lu comme la fin d'une balise. La modification est minime, ce qui est typique des correctifs de script intersite et explique aussi pourquoi ils passent facilement inaperçus en revue. La leçon que les équipes de sécurité tirent de ce type de bug est que le nettoyage et l'affichage doivent s'accorder sur ce que signifie l'entrée, et que tout décalage entre les deux constitue un chemin d'exécution potentiel.

Qui est touché et comment corriger

Toutes les branches de WordPress à partir de la 4.7 sont vulnérables en deçà de leur propre correctif. WordPress a rétroporté le correctif sur les branches prises en charge, et les versions corrigées pour les lignes actuelles sont 7.1.1 pour la branche 7.1, 7.0.5 pour la 7.0 et 6.9.8 pour la 6.9. Les branches plus anciennes, jusqu'à la 4.7.36, ont reçu leurs propres versions corrigées. Le projet recommande une mise à jour immédiate et précise que les sites avec les mises à jour automatiques en arrière-plan activées récupéreront le correctif d'eux-mêmes.

Pour les administrateurs qui ne peuvent pas mettre à jour immédiatement, l'atténuation pratique consiste à modifier les conditions dont dépend l'exploitation. Activer la modération manuelle des commentaires place un humain entre un commentaire anonyme et la page, et fermer les commentaires sur les anciens billets supprime entièrement le point d'entrée. Ni l'un ni l'autre ne remplace un correctif, et la note de Patchstack indiquant que la protection liée aux commentateurs déjà approuvés peut être contournée signifie que la modération n'aide que si les modérateurs approuvent des commentaires qu'ils reconnaissent comme authentiques.

Les autres correctifs de la sortie valent la peine en eux-mêmes. Ils comprennent une faille de niveau contributeur qui permettait à un utilisateur authentifié d'écraser des articles qui ne lui appartenaient pas, une traversée de chemin authentifiée dans le contrôleur de modèles REST signalée par Anthropic, et plusieurs problèmes dans l'API HTML et la gestion des thèmes. Aucun n'est aussi largement accessible que la faille de commentaire, et tous sont traités par la même mise à jour.

Comment vérifier votre version : le tableau de bord de WordPress affiche la version actuelle dans la rubrique Mises à jour. Les versions corrigées sont 7.1.1, 7.0.5 et 6.9.8 pour les branches actuelles, les rétroportages pour les lignes plus anciennes figurant dans la documentation de version du projet.

Un schéma familier, avec un tranchant plus vif

Cette sortie prolonge une année difficile pour la sécurité du cœur de WordPress. En juillet, une faille appelée wp2shell a permis à des attaquants d'exécuter du code sans aucune connexion, et les autorités américaines l'ont ensuite classée comme exploitée dans de véritables attaques. En août, des chercheurs ont divulgué une faille de script dans un autre composant. Comment2Shell est un bug distinct avec un correctif distinct, et son accessibilité à un visiteur non authentifié le place dans la même catégorie inconfortable que ces problèmes antérieurs.

Ce qui distingue cette faille, c'est le chemin d'escalade plutôt que le point d'entrée. Le script intersite dans les commentaires est un problème ancien, et la recommandation standard est de modérer les commentaires et de maintenir le logiciel à jour. Le point intéressant de Comment2Shell, c'est que la charge utile survit au nettoyeur, puis transforme une action administrative banale, l'ouverture d'un commentaire, en une étape vers la compromission du serveur. Cela rappelle que la sécurité d'un système de gestion de contenu dépend de l'action la moins privilégiée qu'il invite à faire, et pas seulement des composants directement exposés à internet.

Le bug constitue aussi une petite étude de cas en matière de divulgation. Muhammad l'a signalé dans le cadre d'un programme coordonné, WordPress l'a corrigé en deux jours, et Patchstack a publié les détails le lendemain de la sortie. C'est le processus qui fonctionne. Ce même processus signifie que les détails sont désormais publics et que le correctif constitue la seule défense, ce qui explique pourquoi les chercheurs ont qualifié la mise à jour d'urgente plutôt que de souhaitable.

La leçon pratique est qu'un formulaire de commentaire ordinaire est une surface de sécurité. Les sites qui gardent les commentaires ouverts sur d'anciens billets, ou qui approuvent automatiquement les commentateurs ayant déjà écrit, devraient considérer la file de modération comme un point d'entrée et mettre à jour sans attendre une fenêtre de maintenance. Les hébergeurs gérés qui exploitent de nombreuses installations peuvent aussi vérifier si certaines sont figées sur une branche non prise en charge, car les rétroportages n'aident que les sites qui les appliquent.

Ce qu'il faut surveiller

La question immédiate est la vitesse à laquelle la longue traîne des sites WordPress se met à jour. WordPress alimente une large part du web, et de nombreuses installations sont maintenues par des personnes qui ne suivent pas de près les publications de sécurité. Les hébergeurs gérés et les mises à jour automatiques combleront une bonne partie de l'écart, et les sites qui traînent sont ceux qui risquent le plus d'être sondés dès l'apparition d'un code de démonstration.

Deux signaux montreront si cela compte. Le premier est de savoir si la faille apparaît dans des tentatives d'exploitation ou sur la liste des vulnérabilités activement exploitées du gouvernement américain, ce qui n'était pas le cas au moment de la publication du correctif. Le second est de savoir si un exploit fonctionnel est publié, puisque le correctif rend la modification exacte visible et qu'une charge utile publique réduirait le temps dont disposent les défenseurs. Les administrateurs sur une branche prise en charge devraient considérer la mise à jour comme faite quand elle est appliquée, pas quand elle est planifiée.

Couverture : le tableau de bord d'administration de WordPress, version 7.0. Capture d'écran de la WordPress Foundation, via Wikimedia Commons, GPL, recadrée en 16:9.

Étiquettes

Questions fréquentes

Qu'est-ce que CVE-2026-93485 ?
C'est une vulnérabilité de script intersite stocké non authentifiée dans le cœur de WordPress, corrigée dans la version 7.1.1 le 17 septembre 2026. Un visiteur sans compte peut injecter du script par un commentaire ordinaire traité par wpautop(), et le script s'exécute quand quelqu'un consulte le commentaire.
Quelles versions de WordPress sont touchées ?
Toutes les branches à partir de la 4.7 sont vulnérables en deçà de leur propre correctif. WordPress l'a corrigée dans les versions 7.1.1, 7.0.5 et 6.9.8, et a publié des rétroportages jusqu'à la 4.7.36. Les sites bénéficiant des mises à jour automatiques en arrière-plan se mettront à jour seuls.
CVE-2026-93485 a-t-elle été exploitée en conditions réelles ?
Rien n'indiquait d'exploitation au moment de la publication du correctif, et la faille ne figure pas sur la liste des vulnérabilités activement exploitées du gouvernement américain. Des chercheurs en sécurité ont averti que le délai entre un correctif et une exploitation publique tend à être court pour un logiciel libre.
Comment une faille de commentaire mène-t-elle à la prise de contrôle du serveur ?
Les commentaires sont consultés par les modérateurs et les administrateurs, et un script qui s'exécute dans le navigateur connecté d'un administrateur peut agir avec ses permissions. À partir de là, un attaquant peut créer un nouveau compte administrateur et l'utiliser pour exécuter du code sur le serveur.
Share

Utile ? Partagez-le avec votre équipe.

TPW Editorial

TPW Editorial

Rédaction

L'équipe éditoriale de TechPastWeek enquête et édite chaque article publié. Chaque sujet est recoupé avec des sources primaires et secondaires fiables, et un éditeur le relit avant publication.

À la une et les plus lus

À lire ensuite