Si vous avez reçu un e-mail de ma part vous renvoyant à cette page, c’est parce que votre site web semble utiliser une version de Events Manager (l’extension WordPress events-manager, éditée par Marcus Sykes / wp-events-plugin.com) qui entre dans la plage concernée par un problème de sécurité connu. Cette page explique en quoi consiste ce problème, comment déterminer s’il s’applique à votre site, et comment mettre à jour.

Avant toute chose, le fait le plus important au sujet de cet avis : une version dans la plage concernée ne signifie pas à elle seule que votre site est exposé. Le problème décrit ci-dessous n’est exploitable que lorsque Events Manager est configuré pour accepter des réservations de la part de visiteurs qui ne sont pas connectés (le « No-User-Account Booking Mode » de l’extension, c’est-à-dire son mode de réservation sans compte utilisateur). Si votre site exige un compte pour réserver, ou ne prend aucune réservation, il n’est très probablement pas exposé, même sur une version concernée. Je peux lire la version de votre extension à partir de fichiers publics, mais je ne peux pas voir votre configuration de réservation ; cet avis est donc une mise en garde préventive, et non un constat confirmé au sujet de votre site.

Ce problème est CVE-2026-12987, une injection d’objet PHP non authentifiée menant à une injection SQL dans le système de réservation de l’extension. L’autorité qui a attribué le CVE n’a pas publié de score de sévérité ; Patchstack évalue la même faille à 8,8 sur 10 (élevée). Elle affecte les versions 4.0.0 à 7.3.6 et est corrigée dans 7.3.7. Si vous utilisez une version concernée, mettez à jour Events Manager vers 7.3.7 ou une version ultérieure (la version actuelle de la ligne 7.4.x est recommandée). Rien n’indique que ce problème soit exploité où que ce soit.

Un mot sur l’urgence, car il s’agit de l’avis le plus conditionnel que j’aie envoyé : son importance pour vous dépend presque entièrement de ce réglage de réservation. Si les réservations sur votre site exigent une connexion, la mise à jour relève de l’entretien courant des extensions. Si votre site accepte des réservations publiques de la part de visiteurs sans compte, veuillez traiter la mise à jour comme une priorité : dans cette configuration, la faille pourrait permettre à un attaquant de lire des données de la base de données de votre site (telles que des empreintes de mots de passe et des clés secrètes) sans se connecter. Même dans ce cas, cette page est une mise en garde préventive, et non un rapport d’incident, et aucune intervention d’urgence n’est sous-entendue.

Il s’agit d’une faille d’une extension, et non du noyau de WordPress. Un WordPress parfaitement à jour ne vous protège pas si l’extension Events Manager elle-même est sur une version concernée.

Ce message est-il légitime ?

Oui. Il s’agit d’un avis de bonne foi, selon le principe de la divulgation responsable, émanant d’un chercheur en sécurité indépendant. Je ne vous demande pas d’argent, de mots de passe ni d’accès à votre site, et je n’ai pas tenté de m’y introduire, de téléverser quoi que ce soit ni d’exploiter quoi que ce soit.

Je n’ai fait que consulter des fichiers publiquement visibles que votre site web fournit à chaque visiteur (de la même manière que votre page d’accueil est publique) et noter le numéro de version que l’extension Events Manager publie dans son fichier readme.txt public. Je n’ai spécifiquement pas touché au système de réservation, et rien dans cette vérification ne touche à vos données, à votre zone d’administration ni à aucune partie privée de votre site (plus de détails sous Ce que j’ai fait et n’ai pas fait ci-dessous).

Si vous souhaitez vérifier qui je suis, consultez les coordonnées au bas de cette page et la page À propos.

Pourquoi cela compte

Events Manager est l’une des extensions d’événements et de réservations les plus anciennes pour WordPress (dans l’annuaire officiel depuis 2008, avec environ 6,3 millions de téléchargements au cours de son existence). Elle permet à un site de publier des événements et d’accepter des réservations pour ceux-ci, y compris, si l’exploitant le choisit, des réservations de la part de visiteurs qui n’ont pas de compte utilisateur sur le site.

Dans les versions concernées, lorsqu’un visiteur soumet une réservation, les champs d’inscription personnalisés qu’il remplit sont stockés en tant que données de réservation, et lorsque l’extension charge ensuite cette réservation, elle décompresse (« désérialise ») les données stockées sans restreindre ce qu’elles sont autorisées à contenir. Une entrée spécialement conçue peut donc être transformée en objets de programme au choix de l’attaquant (injection d’objet PHP), et une chaîne de tels objets atteint une requête de base de données qui n’est pas correctement paramétrée (injection SQL). L’effet pratique sur un site dans la configuration vulnérable : un attaquant sans compte et sans connexion pourrait lire des données arbitraires de la base de données du site, telles que des empreintes de mots de passe et les clés secrètes qu’utilise WordPress.

Deux éléments permettent de garder cela en perspective. Premièrement, le point d’entrée est le formulaire de réservation public, de sorte que l’attaque ne fonctionne que là où un visiteur non connecté peut soumettre une réservation. C’est exactement la condition préalable du « No-User-Account Booking Mode » : si la réservation sur votre site exige un compte, le chemin vulnérable n’est pas accessible aux visiteurs anonymes, et votre site n’est très probablement pas exposé, même sur une version concernée. Deuxièmement, il s’agit d’un problème de lecture de données, et non d’une prise de contrôle du serveur ou d’un compte administrateur : il ne permet pas à lui seul à un attaquant d’exécuter du code sur votre serveur ni de se connecter à votre zone d’administration. Et pour le répéter clairement, il n’existe aucune indication d’exploitation active : elle ne figure pas dans le catalogue des vulnérabilités exploitées connues (Known Exploited Vulnerabilities) de la CISA, son score de probabilité d’exploitation (EPSS) est proche de zéro, et je n’ai connaissance d’aucun signalement d’exploitation.

Si mon e-mail a cité ce problème, cela signifie que la version signalée par votre site entre dans la plage concernée. Je n’ai pas testé si votre site en particulier est exploitable, et je ne peux pas voir comment votre système de réservation est configuré ; tout ce que j’ai observé, c’est que le site signale une version concernée.

Suis-je concerné ?

Deux questions permettent de trancher, dans cet ordre.

D’abord : acceptez-vous des réservations de la part de visiteurs qui ne sont pas connectés ? C’est la question décisive, et vous seul pouvez y répondre.

  • Si les réservations sur votre site exigent un compte ou une connexion, ou si votre site ne prend aucune réservation, vous n’êtes très probablement pas exposé, même sur une version concernée. La mise à jour reste recommandée, au titre de l’entretien ordinaire.
  • Si votre site accepte des réservations de la part de visiteurs sans compte (Events Manager appelle cela le « No-User-Account Booking Mode »), le problème vous concerne, et vous devriez mettre à jour rapidement.
  • Pour vérifier : dans l’administration WordPress, cherchez dans les réglages de réservation d’Events Manager l’option qui autorise les réservations sans compte utilisateur. Ou testez-le simplement depuis l’extérieur : ouvrez l’une de vos pages d’événement dans une fenêtre de navigation privée et voyez si vous pouvez remplir et soumettre une réservation sans qu’il vous soit demandé de vous connecter.

Ensuite : quelle version utilisez-vous ? Vous n’êtes pas obligé de me croire sur parole.

Depuis le manifeste public (aucune connexion nécessaire) : ouvrez yourdomain.com/wp-content/plugins/events-manager/readme.txt dans un navigateur. Notez que cette extension fournit son fichier readme sous le nom readme.txt (en minuscules). La ligne Stable tag: située près du haut est la version signalée par votre installation, et il s’agit du même fichier public que celui que j’ai lu.

Depuis la zone d’administration WordPress (si vous y avez accès) :

  1. Connectez-vous à votre tableau de bord WordPress (généralement à l’adresse yourdomain.com/wp-admin).
  2. Allez dans Extensions puis Extensions installées.
  3. Recherchez Events Manager et notez la version affichée sous son nom.

Appliquez ensuite cette règle, et notez que les versions se comparent numériquement, et non alphabétiquement :

  • 4.0.0 à 7.3.6 : potentiellement concernée (sous réserve de la question du mode de réservation ci-dessus), mettez à jour maintenant.
  • 7.3.7 ou plus récente : déjà corrigée. Cela inclut 7.3.7.1, qui était un correctif de suivi pour une régression d’affichage sans rapport avec la sécurité, et non une seconde version de sécurité : 7.3.7 et 7.3.7.1 contiennent toutes deux le correctif de sécurité. Cela inclut également toutes les versions actuelles de la ligne 7.4.x.
  • Antérieure à 4.0 : non concernée par ce problème. Le traitement vulnérable des données de réservation est apparu pour la première fois dans la refonte 4.0 de l’extension, de sorte que les versions antérieures ne le comportent pas (une version aussi ancienne a bien d’autres raisons d’être mise à jour, mais cet avis n’en fait pas partie).
  • Ne vous laissez pas tromper par l’ordre du texte : Events Manager utilisait des chaînes de version comme 5.99912 avant la 6.0 (l’éditeur est resté bloqué sur un schéma de numérotation 5.999.x jusqu’à la 6.0), et une telle version est une ancienne version inférieure à 6.0, à l’intérieur de la plage concernée, et non quelque chose de plus récent que la 7. Comparez chaque nombre l’un après l’autre plutôt que de lire la version comme du texte.

Comment mettre à jour

La voie la plus sûre consiste à effectuer la mise à jour via WordPress lui-même, et à réaliser une sauvegarde au préalable :

  1. Sauvegardez votre site (fichiers et base de données) avant d’apporter des modifications. La plupart des hébergeurs proposent des sauvegardes en un clic, ou utilisez une extension de sauvegarde WordPress.
  2. Dans l’administration WordPress, allez dans Tableau de bord puis Mises à jour, ou Extensions puis Extensions installées. Si une mise à jour d’Events Manager est répertoriée, installez-la à partir d’ici.
  3. Si vous préférez la ligne de commande, WP-CLI fait la même chose : wp plugin update events-manager.
  4. Si aucune mise à jour n’apparaît, vous pouvez obtenir la dernière version directement depuis la page de l’extension sur l’annuaire WordPress.org, Events Manager, et mettre à jour via Extensions puis Ajouter une extension puis Téléverser une extension.
  5. Après la mise à jour, confirmez le nouveau numéro de version (7.3.7 ou ultérieure ; la version actuelle de la ligne 7.4.x est recommandée) en suivant les étapes ci-dessus, et vérifiez que vos pages d’événements et de réservations fonctionnent normalement.

Tant que vous y êtes, il vaut la peine de confirmer que le noyau de WordPress et vos autres extensions sont à jour, car le même principe s’applique à tous.

Après la mise à jour

La mise à jour vers 7.3.7 ou une version ultérieure comble la faille, et pour la plupart des sites, c’est là toute la tâche. Rien n’indique que cette faille ait été exploitée où que ce soit, donc aucune intervention d’urgence n’est sous-entendue : vous n’avez pas besoin de considérer votre site comme compromis ni de le mettre hors ligne.

Un suivi mérite d’être envisagé, et il est conditionné par la même question de réservation. Si votre site acceptait des réservations publiques de la part de visiteurs sans compte alors qu’il était sur une version concernée, alors les données que la faille pouvait atteindre (le contenu de la base de données, y compris les empreintes de mots de passe et les clés secrètes) étaient au moins théoriquement lisibles, même s’il n’existe aucune preuve que quiconque l’ait fait. Dans ce cas, deux précautions de routine sont judicieuses :

  • Jetez un œil aux réservations et à l’activité des utilisateurs récentes à la recherche de tout élément qui semble anormal, de la manière ordinaire dont vous examineriez l’activité du site.
  • Renouvelez les secrets qui se trouvent dans votre base de données et votre configuration : régénérez les clés secrètes et les sels (salts) de WordPress dans wp-config.php (de nouvelles valeurs sont à un clic près sur le générateur de clés secrètes officiel ; leur remplacement déconnecte tous les utilisateurs une fois), et changez le mot de passe de votre base de données via le panneau de votre hébergeur. Comme les empreintes de mots de passe faisaient partie des données théoriquement lisibles, faire renouveler leurs mots de passe aux comptes administrateurs est une mesure supplémentaire raisonnable.

Considérez cela comme un entretien de sécurité ordinaire, et non comme une réponse à incident. Si les réservations sur votre site ont toujours exigé une connexion (ou si vous ne prenez aucune réservation), la mise à jour suffit à elle seule.

Ce que j’ai fait et n’ai pas fait

Pour être pleinement transparent sur la vérification derrière mon e-mail : je n’ai lu que des fichiers publics que votre site fournit déjà à chaque visiteur, en l’occurrence le fichier readme.txt public de l’extension et votre page d’accueil. Je n’ai pas accédé à votre zone d’administration WordPress, à votre base de données ni à aucune partie privée du site. En particulier, je n’ai pas touché au chemin de réservation vulnérable, et je n’ai rien testé ni exploité.

Il s’agit d’une observation fondée sur la version : votre site signale une version dans la plage concernée. Comme ce problème dépend de la configuration, un site dans cette plage peut ne pas être exposé du tout (si les réservations exigent une connexion, ou si aucune réservation n’est prise), et il peut aussi déjà être protégé par d’autres moyens, tels qu’un pare-feu applicatif web. Cet avis n’est pas une affirmation que votre site était exploitable au moment de ma vérification.

Je n’ai pas de webmaster / je suis bloqué

Si vous n’êtes pas la personne qui gère le site, veuillez transférer cette page à celle qui s’en charge (votre développeur web, votre agence ou votre hébergeur). Elle reconnaîtra rapidement les étapes ci-dessus.

Si vous gérez le site vous-même et que vous êtes bloqué, je me ferai un plaisir de vous aiguiller dans la bonne direction, sans frais. Contactez-moi à l’aide des coordonnées ci-dessous.

Contact

Evan Harris, chercheur en sécurité

Je contacte les exploitants au sujet de problèmes comme celui-ci uniquement pour les aider à sécuriser leurs sites. Si vous préférez ne plus être contacté, faites-le-moi simplement savoir et je le respecterai.

Références

Avis officiels et suivi

Éditeur / extension