Une faille CSRF d’Elementor peut donner le contrôle total de WordPress après un seul clic d’administrateur

Une faille de falsification de requête intersite (CSRF) dans Elementor Website Builder permet à un attaquant non authentifié de faire exécuter des actions privilégiées de l’API REST par un administrateur WordPress connecté. Sur une installation par défaut, l’attaquant peut exploiter la faille pour créer un compte administrateur qu’il contrôle.

Le problème concerne les versions 4.3.0 et 4.3.1 d’Elementor. Elementor l’a corrigé dans la version 4.3.2, que les administrateurs de sites doivent installer sans attendre.

Patchstack a publié les détails le 25 septembre 2026. D’après l’entreprise, Elementor avait été informé le 22 septembre, après que le chercheur en sécurité « Saggre » lui a signalé la vulnérabilité. La version corrigée est sortie deux jours après ce signalement.

La vérification de la route désactive une protection essentielle de WordPress

La vulnérabilité se trouve dans le module Editor Events d’Elementor. Ce composant examine l’URI brute de la requête et recherche le chemin suivant :

elementor/v1/events/

Lorsque cette chaîne est présente, le module contourne la validation des nonces de l’API REST de WordPress. Les nonces REST permettent à WordPress de vérifier qu’une requête authentifiée a bien été déclenchée volontairement par l’utilisateur connecté, et non imposée par un tiers.

La faille tient à la façon dont Elementor identifie la route. Au lieu de déterminer de manière sûre quel point de terminaison REST est appelé, le module recherche la chaîne attendue dans l’URI complète, que l’attaquant peut influencer.

Les paramètres de requête font partie de cette URI brute. Un attaquant peut donc envoyer une requête à un autre point de terminaison de l’API REST tout en ajoutant elementor/v1/events/ dans la chaîne de requête. Elementor repère ce chemin d’apparence légitime et désactive la vérification du nonce, alors que la requête vise en réalité un autre point de terminaison.

Le navigateur de la victime transmet tout de même sa session WordPress authentifiée. La requête REST s’exécute donc avec les autorisations dont dispose déjà la victime.

Il ne s’agit pas d’un contournement de l’authentification permettant à l’attaquant de se connecter directement en tant qu’administrateur. C’est une attaque CSRF qui pousse le navigateur d’un administrateur déjà connecté à agir pour le compte de l’attaquant. Dans les faits, le résultat peut toutefois équivaloir à une prise de contrôle du compte.

Un seul lien malveillant peut créer un compte administrateur permanent

Pour exploiter la faille, il suffit qu’un administrateur WordPress soit connecté, puis ouvre une URL conçue par l’attaquant. Le lien peut être envoyé par e-mail ou par messagerie, ou encore publié dans un commentaire sur le site visé.

L’attaque nécessite très peu de moyens pour être mise en œuvre. Elle ne requiert pas :

• l’exécution de JavaScript ;
• une page web contrôlée par l’attaquant ;
• un formulaire HTML caché ou soumis par l’utilisateur ;
• une authentification préalable sur le site WordPress ciblé.

Un seul clic suffit si l’administrateur dispose d’une session active.

Sur une installation WordPress par défaut, la requête REST forgée peut créer un autre compte administrateur. L’attaquant obtient ainsi un accès persistant, indépendant de la session de la victime. Même si le lien malveillant n’est plus jamais ouvert, le compte créé reste utilisable jusqu’à ce que les responsables du site le repèrent et le suppriment.

Un compte administrateur contrôlé par un attaquant peut lui donner accès au contenu du site, à sa configuration et aux données des utilisateurs. Il peut aussi lui permettre de gérer les extensions et les thèmes, selon la configuration du site et les autres mesures de sécurité en place. On ignore quelles actions précises ont été observées après la compromission dans des attaques réelles.

Aucun score de gravité public ni identifiant CVE n’a été attribué à cette vulnérabilité. Aucune information sur une exploitation active dans la nature n’a été communiquée. La faille ne figure pas, d’après les informations disponibles, dans le catalogue des vulnérabilités exploitées de la CISA et ne fait l’objet d’aucune échéance de correction fédérale annoncée.

Jusqu’à deux millions de sites pourraient utiliser une version vulnérable

Elementor Website Builder est utilisé sur environ 10 millions de sites web. D’après les statistiques d’adoption de WordPress.org, jusqu’à 2 millions de sites pourraient utiliser une version concernée par cette faille.

Les versions touchées sont peu nombreuses, mais le problème reste important :

Version d’Elementor	Statut
4.3.0	Vulnérable
4.3.1	Vulnérable
4.3.2	Corrigée
Antérieure à 4.3.0	Non concernée par cette faille spécifique du module Editor Events

Les versions antérieures à la 4.3.0 ne comprennent pas le proxy Editor Events vulnérable. Cela ne constitue toutefois pas une solution de contournement sûre : ces versions présentent d’autres failles de sécurité, dont certaines sont déjà activement exploitées.

La bonne mesure consiste donc à passer à la version 4.3.2, et non à revenir à une version antérieure.

La vaste base d’installation d’Elementor augmente le risque de campagnes de balayage opportunistes et de diffusion massive de leurres. Les attaquants n’ont pas forcément besoin de savoir si un administrateur donné est connecté au moment de l’attaque. Ils peuvent diffuser des liens à grande échelle et attendre que l’un d’eux atteigne un utilisateur disposant d’une session privilégiée active.

La version 4.3.2 bloque le contournement par la chaîne de requête

Elementor 4.3.2 empêche les attaquants d’utiliser la chaîne de requête pour faire passer une requête REST sans rapport pour un appel à la route Editor Events. Les administrateurs doivent vérifier la version installée au lieu de se fier uniquement aux paramètres supposés de mise à jour automatique.

Voici les mesures à prendre sans attendre :

1. Mettre à niveau Elementor Website Builder vers la version 4.3.2.
2. Vérifier que les versions 4.3.0 et 4.3.1 ne sont plus utilisées nulle part, y compris sur les environnements de préproduction et les installations WordPress secondaires.
3. Examiner les comptes administrateur et repérer ceux qui n’ont pas été créés délibérément.
4. Analyser les opérations récentes de gestion des comptes et les requêtes REST, si les journaux nécessaires sont disponibles.
5. Révoquer les sessions administrateur actives et réinitialiser les identifiants en cas d’activité privilégiée non autorisée.

Le seul élément concret de requête mentionné pour cette vulnérabilité est la chaîne :

elementor/v1/events/

Les équipes de défense peuvent rechercher ce chemin dans les chaînes de requête ou dans des requêtes visant des points de terminaison REST sans rapport, à l’aide des journaux des serveurs web, des reverse proxies, des pare-feu applicatifs et des applications. Sa présence ne prouve pas à elle seule qu’un site a été compromis, car le trafic légitime d’Elementor peut emprunter la même route. Le contexte est déterminant : il faut examiner conjointement le point de terminaison réellement visé, l’emplacement de la chaîne dans la requête, le code de réponse et l’activité associée aux comptes.

Les sites doivent également rechercher les comptes administrateur récemment ajoutés, en particulier ceux dont le nom, l’adresse e-mail ou la date de création sont inhabituels. Les informations disponibles ne précisent aucun nom d’utilisateur, aucune adresse IP ni aucun autre indicateur propre à une campagne.

Le risque plus général : une compromission facilitée par l’administrateur

Cette vulnérabilité appartient à une catégorie d’attaques qui exploitent le navigateur d’un administrateur de confiance comme vecteur d’exécution. L’attaquant ne déjoue pas le mot de passe de l’administrateur et ne vole pas directement son cookie de session. Une validation insuffisante des requêtes permet plutôt à un lien piégé de transformer la session existante de l’administrateur en action privilégiée.

Les mesures habituelles de prévention de l’hameçonnage restent donc pertinentes, mais la prudence des utilisateurs ne remplace pas l’application du correctif. Les liens peuvent être maquillés, raccourcis ou intégrés à des espaces où les administrateurs ont l’habitude de cliquer. Comme l’attaque ne nécessite ni JavaScript ni site malveillant dédié, l’attaquant a également moins d’infrastructure à mettre en place.

WordPress a récemment été confronté à une autre faille exploitant l’interaction d’un administrateur : une simple visite pouvait servir à imposer l’installation d’un thème et potentiellement ouvrir la voie à une compromission plus vaste. Cette attaque a été décrite sous le nom de Click2Shell, une attaque qui transforme la visite d’un administrateur en installation forcée d’un thème.

Pour les utilisateurs d’Elementor, la marche à suivre est simple : installer la version 4.3.2. Même sans identifiant CVE ni score de gravité, la possibilité de créer un compte administrateur contrôlé par un attaquant suffit à faire de cette mise à jour une urgence.