veilletech.fr
27 sept. Feed du jour
#01 SÉCURITÉ Faille

Elementor 4.3 : un lien, et l'attaquant est admin

Un paramètre dans l'URL, et le nonce ne compte plus.

Elementor 4.3.0 et 4.3.1 désactivent la protection CSRF de toute l'API REST de WordPress dès que la chaîne elementor/v1/events/ figure dans l'adresse, paramètres compris. Un simple lien cliqué par un administrateur connecté suffit à créer un compte administrateur pour l'attaquant. Plus de deux millions de sites ont installé ces versions ; la 4.3.2 corrige.

3 min de lectureintermédiairevidéo 1:21
Partager
Sommaire6 sections
  1. Ce qui se passe
  2. Le mécanisme
  3. Qui est touché
  4. Comment s'y prendre
  5. Ce que ça apprend aux auteurs d'extensions
  6. À retenir

Ce qui se passe

Patchstack a publié le 25 septembre l'analyse d'une faille CSRF dans Elementor Website Builder, le constructeur de pages actif sur plus de dix millions de sites WordPress. Seules les versions 4.3.0 et 4.3.1 sont concernées, installées sur plus de deux millions de sites selon WordPress.org. La 4.3.2, sortie le 24 septembre, corrige. Score CVSS 8.8, aucun CVE attribué pour l'instant ; la découverte revient au chercheur Saggre.

Concrètement : un administrateur connecté qui ouvre un lien piégé crée, sans le savoir, un second compte administrateur au profit de l'attaquant.

Le mécanisme

Le module Editor Events relaie la télémétrie de l'éditeur et veut soustraire ses propres routes REST à la vérification du nonce wp_rest. Il se branche pour cela sur le filtre rest_authentication_errors, en priorité 0, et répond true dès que la chaîne elementor/v1/events/ figure dans $_SERVER['REQUEST_URI'].

Trois erreurs se cumulent :

  1. Le filtre s'exécute avant le routage. WordPress ne sait pas encore quelle route est visée ; le module n'a que l'URI brute sous la main.
  2. Cette URI inclut la chaîne de requête, écrite par l'auteur du lien, et la recherche n'est pas ancrée : ?zzz=elementor/v1/events/ suffit, et même un fragment noyé dans une autre valeur.
  3. Sur ce filtre, true ne signifie pas « sans avis » mais « authentification réussie ». rest_cookie_check_errors(), seule protection CSRF du cœur pour les requêtes REST authentifiées par cookie, trouve une valeur déjà posée et s'arrête. Les extensions de sécurité branchées sur le même filtre aussi.

Le permission_callback de la route interroge encore les droits de l'utilisateur, et ils sont intacts. Ce qui disparaît, c'est la preuve qu'il voulait faire la requête. Comme WordPress accepte le paramètre _method pour changer de verbe, une simple navigation devient une écriture :

HTTP
GET /wp-json/wp/v2/users?_method=POST&username=csrfadmin&email=…&password=…&roles%5B%5D=administrator&x=elementor/v1/events/

Sans le dernier paramètre, la réponse est un 401 rest_cannot_create_user. Avec, un 201 et un utilisateur au rôle administrator.

Route usersContrôle dunonceFiltre ElementorNavigateuradminAttaquantRoute usersContrôle dunonceFiltre ElementorNavigateuradminAttaquantLien piégé1GET avec cookie2true, déjà authentifié3Nonce ignoré4201, admin créé5
Le lien piégé fait agir le navigateur de l'administrateur, et le nonce n'est jamais vérifié

Qui est touché

Le contournement vaut pour toute l'API REST du site : routes du cœur et des autres extensions comprises. Patchstack montre aussi GET /wp-json/wp/v2/settings passer de 401 à 200.

Le module est une expérience marquée hidden, absente de l'écran Experiments, mais active par défaut sur tout site dont la première installation d'Elementor date de la 3.32.0 ou après. Une installation par défaut en 4.3.0 ou 4.3.1 est vulnérable, quels que soient les réglages de télémétrie. Les versions antérieures à la 4.3.0 n'embarquent pas ce module.

Comment s'y prendre

  1. Passer Elementor en 4.3.2 ou au-delà.
  2. Relire les comptes administrateurs et les inscriptions récentes.
Terminal
wp plugin get elementor --field=version
wp user list --role=administrator --fields=ID,user_login,user_registered

Ce que ça apprend aux auteurs d'extensions

Le correctif lit $wp->query_vars['rest_route'], la route résolue, sans chaîne de requête, exige qu'elle commence par le préfixe (0 === strpos(...) au lieu de false !== strpos(...)) et refuse une route passée en tableau. Deux règles en découlent : REQUEST_URI est une donnée de l'attaquant, pas une information de routage ; et sur rest_authentication_errors, un filtre sans avis renvoie $result tel quel.

Source : analyse de la faille CSRF d'Elementor, Patchstack, 25 septembre 2026. Relayée par The Hacker News le 26 septembre.