Une vulnérabilité dans Elementor permet à un administrateur ayant ouvert une session de créer un nouveau compte administrateur contrôlé par un attaquant d’un simple clic. Ce défaut concerne uniquement les versions Elementor 4.3.0 et 4.3.1, qui sont installées sur un maximum estimé de deux millions de sites WordPress. La correction est disponible dans la version 4.3.2.
Un paramètre dans l’URL suffit à contourner la protection.
La faiblesse réside dans le module Editor Events, qui est chargé de transmettre certaines données de télémétrie de l’éditeur. Pour ses propres appels, ce composant devait contourner la vérification de sécurité utilisée par l’API REST de WordPress. Cependant, le code vérifiait simplement si la chaîne “elementor/v1/events/” apparaissait dans l’adresse demandée, sans s’assurer que la requête était réellement destinée à ce chemin.
De plus, l’adresse examinée comprend également les paramètres ajoutés après le point d’interrogation. Ainsi, un attaquant peut insérer la chaîne attendue dans un paramètre inoffensif tout en dirigeant la requête vers une autre fonction de l’API. Elementor renvoyait alors un résultat positif avant de vérifier le jeton de sécurité de WordPress, validant ainsi incorrectement l’action.
Dans une installation par défaut, l’attaque peut cibler le chemin d’administration des utilisateurs et créer un compte avec un rôle d’administrateur. Cela ne confère pas de droits à la victime, puisque l’administrateur authentifié doit ouvrir le lien préparé. Votre navigateur attachera alors automatiquement les cookies de session et exécutera la requête avec ses privilèges.
Pas de JavaScript ni de faux formulaires requis
Le scénario est encore plus simple, car le lien n’a pas besoin de contenir du JavaScript, de charger un formulaire ou de rediriger vers une page hébergée par l’attaquant. Il peut arriver par e-mail, via un messager ou même dans un commentaire. Cette catégorie de vulnérabilité est connue sous le nom de falsification de requête intersites, ou CSRF : la victime demeure connectée au bon site, mais son navigateur envoie une action qu’elle n’avait pas l’intention d’effectuer.
Le module concerné est une expérience cachée. Il n’apparaît pas dans l’écran des fonctionnalités expérimentales d’Elementor et est activé par défaut sur les nouveaux sites ayant installé le constructeur depuis la version 3.32.0. Par conséquent, un site peut être vulnérable sans que son administrateur ait décidé de tester cette fonctionnalité.
Les versions antérieures à 4.3.0 ne contiennent pas ce proxy spécifique et ne sont pas affectées par ce bogue. Cela ne signifie pas qu’il est sans danger de revenir à une édition précédente : d’autres vulnérabilités y ont été corrigées. La réponse recommandée est de passer directement à Elementor 4.3.2 ou version ultérieure.
Une solution publiée deux jours après le signalement.
Le chercheur Saggre a soumis le bogue à Patchstack, qui l’a signalé à l’équipe d’Elementor le 22 septembre. La version 4.3.2 a été publiée le 24 septembre et vérifie le chemin REST réellement résolu au lieu de rechercher une sous-chaîne dans l’adresse brute. L’annonce publique est survenue le 25 septembre, une fois le correctif devenu disponible.
Patchstack attribue à la vulnérabilité l’identifiant CVE-2026-62062 et un score CVSS de 8.8. Toutefois, l’entreprise lui accorde une priorité moyenne dans son propre système, notamment parce que son exploitation nécessite l’interaction d’un utilisateur privilégié. Aucune information publique fournie dans l’avis n’indique qu’une campagne active se déroulait au moment de la publication.
Elementor est annoncé comme actif sur plus de dix millions de sites. Cet incident survient pendant une période de changements importants pour le CMS, à la suite de la sortie de WordPress 7.1 et de ses nouveaux outils de conception. Il rappelle également que les extensions restent un point de contrôle distinct par rapport au cœur de WordPress, même face à de nouveaux concurrents comme EmDash, le CMS introduit par Cloudflare.
Après la mise à jour, les administrateurs peuvent vérifier la liste des comptes, rechercher des utilisateurs inattendus et invalider des sessions suspectes. Le correctif 4.3.2 était déjà disponible avant la publication complète du mécanisme le 25 septembre.
