ACF Extended : une faille critique d’escalade de privilèges peut donner un accès admin sans authentification

Une alerte sécurité publiée par Wordfence vise Advanced Custom Fields: Extended (ACF Extended), un addon populaire d’Advanced Custom Fields. Le point clé : une escalade de privilèges non authentifiée permettrait, dans certaines configurations, de se créer un utilisateur avec le rôle administrator et donc de prendre le contrôle du site.

Le plugin compte 100 000+ installations actives sur WordPress.org, mais l’exploitation n’est pas « automatique » sur tous les sites : elle dépend d’un cas d’usage précis autour des formulaires et d’un champ de rôle mappé.

Résumé de la vulnérabilité (CVE-2025-14533)

• Produit : Advanced Custom Fields: Extended
• Gravité : Critique (CVSS 9.8)
• CVE : CVE-2025-14533
• Versions affectées : <= 0.9.2.1
• Version corrigée : 0.9.2.2
• Type : Privilege escalation (élévation de privilèges) sans authentification

D’après l’analyse de Wordfence, le problème vient d’une action de formulaire côté ACF Extended qui crée (ou met à jour) un utilisateur à partir de champs soumis. Si un champ role est présent et mappé, un attaquant peut fournir la valeur administrator lors de la soumission et obtenir un compte admin.

Pourquoi c’est dangereux : « admin = contrôle total »

Une fois un compte administrateur obtenu, l’attaquant se retrouve avec un éventail d’actions classiques mais catastrophiques : installation de plugins/thèmes (y compris des archives ZIP malveillantes), modification de contenu pour injecter du spam ou des redirections, ajout de backdoors, création d’autres comptes, etc. Bref, c’est une compromission complète du site dans le modèle WordPress.

Ce qui s’est passé techniquement (sans entrer dans l’exploitation)

ACF Extended fournit notamment un form manager : tu définis un groupe de champs (email, login, mot de passe… et éventuellement rôle), puis tu relies ces champs à une action de formulaire du type « créer un utilisateur ». L’idée est pratique pour faire un formulaire d’inscription front sans recoder un flux complet.

Wordfence indique que la classe acfe_module_form_action_user utilise une fonction insert_user() pour construire les arguments d’un utilisateur, puis appelle wp_insert_user($args).

// Construction des args à partir des champs mappés
$args = apply_filters('acfe/form/submit_user_args', $args, $form, $action);

// Insertion de l'utilisateur
$user_id = wp_insert_user($args);

// Problème décrit : si un champ 'role' est mappé,
// une valeur non restreinte (ex: 'administrator') peut être acceptée.

// Construction des args à partir des champs mappés
$args = apply_filters('acfe/form/submit_user_args', $args, $form, $action);

// Insertion de l'utilisateur
$user_id = wp_insert_user($args);

// Problème décrit : si un champ 'role' est mappé,
// une valeur non restreinte (ex: 'administrator') peut être acceptée.

Le point subtil mentionné : ACF Extended propose une option de configuration sur le champ de rôle (par exemple « Allow User Role »), ce qui laisse penser qu’on peut limiter les rôles possibles. Or, sur les versions vulnérables, la restriction ne serait pas appliquée correctement au niveau de l’action de formulaire, ce qui laisse la porte ouverte à un rôle arbitraire.

Qui doit réagir en priorité ?

Tu es particulièrement concerné si tu coches au moins un de ces points :

• ACF Extended est installé et sa version est <= 0.9.2.1.
• Tu utilises les formulaires ACF Extended avec une action Create user ou Update user.
• Un champ de rôle (role) est présent dans le groupe de champs et mappé sur l’action du formulaire (par exemple via une sélection de rôle côté front).

Mesures immédiates : patcher et auditer

1. Mettre à jour ACF Extended en 0.9.2.2 (version corrigée mentionnée dans l’avis).
2. Identifier les formulaires ACF Extended en production qui créent/mettent à jour des utilisateurs, et vérifier si un champ role est mappé.
3. Si tu as besoin d’un choix de rôle côté front (cas rare), éviter de l’exposer directement : privilégier un rôle fixe côté serveur ou une whitelisting stricte.
4. Contrôler la liste des utilisateurs WordPress : repérer des comptes admin récents et inattendus, et vérifier l’historique des actions si tu as des logs.
5. Si un doute existe, révoquer les comptes suspects, régénérer les secrets (mots de passe, clés), et inspecter plugins/thèmes uploadés récemment.

Chronologie de divulgation (selon Wordfence)

• 10 décembre 2025 : soumission via le Bug Bounty Program Wordfence.
• 11 décembre 2025 : validation + preuve de concept confirmée ; règle firewall distribuée aux offres Premium/Care/Response ; divulgation au vendor via le portail de gestion des vulnérabilités.
• 14 décembre 2025 : correctif publié (ACF Extended 0.9.2.2).
• 10 janvier 2026 : règle firewall distribuée aux utilisateurs Wordfence Free.

À retenir

Cette faille rappelle un classique : dès qu’un formulaire front manipule des objets sensibles (comptes utilisateurs, rôles/capabilities), il faut une validation serveur stricte, indépendante des options d’UI. Si tu utilises ACF Extended et que tu as construit un flux d’inscription/édition d’utilisateur via ses actions de formulaire, mets à jour en 0.9.2.2 et vérifie immédiatement le mapping du champ role.