The Events Calendar : deux failles critiques, 600 000 sites, et un simple commentaire suffit pour prendre le contrôle

Deux failles critiques dans The Events Calendar, exploitables par un commentaire

Le 14 septembre 2026, Wordfence a publié l'analyse de deux chaînes de vulnérabilités indépendantes dans The Events Calendar, découvertes les 21 et 23 août par son agent de recherche automatisé Argus. Les deux commencent au même endroit, le pipeline de rendu des widgets de l'extension, et mènent toutes deux à une exécution de code à distance sans authentification. Aucune connexion, aucun compte, aucune ingénierie sociale : il faut seulement que la page de l'événement accepte les commentaires, ce qui suppose aussi que l'option « Show comments on event pages » de l'extension soit active.

Chaîne	Référence	Versions vulnérables	Effet
Injection d'objet PHP	CVE-2026-78006, CVSS 9.8	6.17.4 et antérieures ; corrigée en 6.17.4.1	Exécution de commandes système sur le serveur, via array_map() avec un callback contrôlé par l'attaquant
Invocation d'un callable arbitraire	CVE-2026-78159, CVSS 9.8	6.17.3 et antérieures ; corrigée en 6.17.3.1	Appel de n'importe quelle fonction PHP globale ; démonstration : réinitialisation du mot de passe de l'utilisateur 1 avec wp_update_user(), puis envoi d'une extension malveillante

StellarWP a reconnu les deux rapports le 24 août, publié un premier correctif dès le 25 août pour la première chaîne, et la version entièrement corrigée, 6.17.4.1, le 10 septembre d'après Wordfence. Les abonnés Wordfence Premium, Care et Response ont reçu une règle de pare-feu le 22 août ; la version gratuite la recevra le 21 septembre. Dans les jours qui ont suivi la publication, un code de démonstration pour CVE-2026-78006 est apparu sur GitHub et a été référencé par Sploitus : les sites non mis à jour sont désormais à la portée de n'importe quel outil automatisé.

Pourquoi un commentaire suffit

La surface d'attaque commune tient à un choix de conception. Dans son gabarit d'événement V2, The Events Calendar met en mémoire tampon la page entière, section des commentaires comprise, puis fait passer ce tampon dans la fonction do_blocks() de WordPress. Or WordPress n'exécute jamais do_blocks() sur le texte des commentaires, seulement sur le contenu des articles. En le faisant, l'extension étend l'analyseur de blocs Gutenberg à du contenu soumis par des inconnus.

Deux détails de WordPress rendent la chose exploitable. D'abord, le filtre KSES qui nettoie les commentaires conserve les délimiteurs de commentaire HTML (<!-- ... -->), qui sont précisément la syntaxe des blocs Gutenberg : un bloc malveillant survit donc au nettoyage. Ensuite, après l'envoi d'un commentaire, WordPress redirige l'auteur vers une URL de prévisualisation (?unapproved=N&moderation-hash=H) qui lui montre immédiatement son commentaire en attente. L'attaquant déclenche le rendu du widget en visitant sa propre prévisualisation, sans qu'aucun modérateur n'ait approuvé quoi que ce soit.

Le contournement du contrôle d'intégrité

Quand do_blocks() rencontre un bloc wp:legacy-widget dont l'identifiant commence par tribe-widget-, l'extension décode l'instance de widget fournie, la soumet à sa fonction is_safe_widget_instance(), et, si le test passe, remplace le hash fourni par un wp_hash() fraîchement calculé sur les données de l'attaquant. WordPress utilise justement ce hash comme unique garde-fou avant de désérialiser une instance de widget. En le générant pour des données hostiles, l'extension neutralise la seule protection du cœur. À partir de là, les deux chaînes divergent.

Chaîne 1 : un objet caché derrière une erreur de syntaxe

is_safe_widget_instance() désérialise les données avec l'option allowed_classes => false et vérifie que le résultat ne contient pas d'objet. Le raisonnement suppose que cette option empêche tout comportement lié aux objets pendant l'analyse ; c'est faux, PHP peut invoquer __unserialize() et __wakeup() pendant le parcours, avant même que la fonction ne retourne. L'attaquant place un objet complet dans une structure sérialisée et ajoute derrière un jeton invalide. Le premier passage échoue sur ce jeton et retourne false ; le garde-fou ne voit pas d'objet et déclare la charge sûre. Lors de la vraie désérialisation par le rendu de widget de WordPress, l'objet est construit et ses méthodes magiques s'exécutent avant l'échec.

Le gadget se trouve dans le code de l'extension elle-même : la méthode __unserialize() de sa classe Lazy_Post_Collection passe par custom_unserialize(), qui termine par array_map( $unserialized['callback'], $unserialized['ids'] ) sans aucune validation. Avec system comme callback et une commande dans ids, l'attaquant exécute ce qu'il veut avec les droits du serveur web.

Chaîne 2 : un simple tableau qui réinitialise le mot de passe admin

La seconde chaîne ne contient aucun objet et passe donc le garde-fou sans le contourner. Le tableau fourni est fusionné dans les arguments du widget, puis le moteur de gabarits fait un extract() du contexte, ce qui transforme chaque clé du tableau en variable locale, y compris classes. En forçant la requête d'événements à ne rien retourner (?tribe_paged=99), l'attaquant fait charger le sous-gabarit des messages, qui fusionne sa variable $classes et l'envoie à Element_Classes::parse_array(). Cette fonction accepte des closures pour générer des classes CSS dynamiques, mais son test n'est pas limité aux closures : tout ce qui satisfait is_callable() est appelé, y compris une chaîne nommant une fonction globale.

Un tableau équivalent à {"ID": true, "user_pass": true, "zz": "wp_update_user"} suffit : les deux premières clés sont ajoutées aux résultats, puis wp_update_user() est appelée avec ces résultats en argument. WordPress y lit une instruction de changer le mot de passe de l'utilisateur 1 en « 1 ». L'appel interne ne vérifie aucune capacité. L'attaquant se connecte ensuite comme administrateur et téléverse une extension malveillante.

Que vérifier sur votre site, dans l'ordre

Version et réglage des commentaires

wp plugin get the-events-calendar --field=version
wp option get tribe_events_calendar_options --format=json | grep -io '"showComments":[^,]*'

Toute version inférieure à 6.17.4.1 doit être mise à jour immédiatement. Si les commentaires sur les événements ne servent à rien sur votre site, désactivez-les dans les réglages de l'extension : cela ferme le vecteur d'entrée des deux chaînes, mise à jour ou non. Plus généralement, un site qui n'utilise pas les commentaires gagne à les fermer partout ; notre article sur le spam de commentaires explique comment.

Chercher le bloc malveillant dans les commentaires

Le marqueur est sans ambiguïté : aucun commentaire légitime ne contient un bloc wp:legacy-widget ni un identifiant tribe-widget-. La charge reste dans la table des commentaires, approuvée ou non, tant que personne ne l'a supprimée.

wp db query "SELECT comment_ID, comment_post_ID, comment_author_IP, comment_date, comment_approved FROM wp_comments WHERE comment_content LIKE '%wp:legacy-widget%' OR comment_content LIKE '%tribe-widget-%'"

Un résultat signifie qu'une tentative a eu lieu. Elle a réussi si le site était vulnérable à la date du commentaire ; dans ce cas, passez à l'étape suivante sans attendre.

Chercher les conséquences d'une exploitation réussie

1. Extensions installées depuis le 21 août. La chaîne 2 se termine par l'envoi d'une extension par l'attaquant connecté en administrateur. Comparez le contenu de wp-content/plugins et wp-content/mu-plugins sur le disque avec la liste de wp-admin, une extension malveillante pouvant se masquer.
2. Comptes administrateurs. Listez-les et vérifiez la date de dernière modification du mot de passe si votre journal d'activité la conserve ; voir administrateur inconnu dans WordPress.
3. Fichiers PHP récents dans uploads et à la racine, et fichiers modifiés hors mise à jour.
4. Journaux d'accès. Des POST vers wp-comments-post.php suivis d'un GET avec moderation-hash= et tribe_paged= depuis la même adresse, puis des requêtes vers /wp-admin/update.php?action=upload-plugin. La méthode est détaillée dans notre guide pour analyser les journaux d'un piratage.

find wp-content/plugins wp-content/mu-plugins -maxdepth 1 -newermt "2026-08-21"
find . -name "*.php" -newermt "2026-08-21" -not -path "./wp-content/plugins/the-events-calendar/*"
grep -E "moderation-hash=.*tribe_paged=|action=upload-plugin" /var/log/nginx/access.log*

Si l'un de ces contrôles est positif, le site est compromis : nettoyage complet, rotation des mots de passe et des clés de sécurité, recherche des portes dérobées. Notre guide de nettoyage décrit la procédure, et notre équipe peut s'en charger : nettoyage de site WordPress piraté, diagnostic gratuit sous 12 heures.

Ce que cette affaire dit des extensions à widgets

Les deux chaînes n'exploitent pas une erreur d'inattention mais un empilement de décisions raisonnables prises isolément : rendre les blocs sur toute la page pour supporter les widgets dans les gabarits, régénérer un hash pour que les widgets copiés fonctionnent, accepter des callables pour des classes CSS dynamiques. Chaque décision a du sens ; leur combinaison donne une exécution de code sans authentification. C'est le schéma type des failles découvertes en 2026 par les outils d'analyse automatisée, qui excellent à relier des maillons éloignés dans une base de code de plusieurs centaines de milliers de lignes.

Pour un propriétaire de site, la conclusion pratique est double. D'une part, une extension populaire et sérieusement maintenue peut abriter une faille critique pendant des années : StellarWP a réagi en quatre jours, mais personne n'avait vu ces chaînes avant le 21 août. D'autre part, chaque fonction non utilisée est une surface d'attaque gratuite : ici les commentaires sur les événements, ailleurs XML-RPC, l'inscription ouverte ou un champ de téléversement. Fermez ce qui ne sert pas, mettez à jour le jour même, et gardez des journaux pour pouvoir répondre à la question « ai-je été touché » quand une analyse comme celle-ci paraît. La même semaine, Wordfence a documenté une chaîne comparable dans Tutor LMS, et WordPress a publié la version 7.1.1 avec onze correctifs de sécurité.

Sources

• Wordfence, Chloe Chamberland, « Wordfence Argus Identifies Two Critical Unauthenticated Vulnerability Chains Leading to Remote Code Execution in The Events Calendar Plugin », 14 septembre 2026, wordfence.com
• Cyber Security News, « Critical WordPress Plugin Flaws Put Over 600,000 Websites at Risk of Takeover », 15 septembre 2026, cybersecuritynews.com
• Sploitus, fiche « DeadExpl0it/CVE-2026-78006-POC », septembre 2026, sploitus.com
• WordPress.org, fiche de l'extension « The Events Calendar », wordpress.org