Un avis de sécurité a été publié concernant le populaire **plugin WPBakery** inclus dans des milliers de thèmes WordPress. La faille permet à des attaquants authentifiés d’injecter des scripts malveillants qui s’exécutent lorsque quelqu’un visite une page compromise.
Le plugin WPBakery
Le **WPBakery Page Builder** est un **plugin** d’édition visuelle par glisser‑déposer pour **WordPress**. Il permet aux utilisateurs, même sans compétences en développement, de concevoir et d’assembler des mises en page personnalisées pour des sites web. Ce plugin est largement distribué : de nombreux développeurs de **thèmes premium** l’intègrent sous licence afin d’offrir la puissance d’un constructeur de pages directement avec le thème.
Cette pratique de bundling (intégration au thème) simplifie le déploiement pour l’utilisateur final, mais elle peut aussi compliquer la gestion des mises à jour et la diffusion rapide des correctifs de sécurité. Lorsqu’un **plugin** est empaqueté dans un thème, le mécanisme de mise à jour automatique peut être différent ou même absent, ce qui exige une attention particulière de la part des éditeurs de thèmes et des administrateurs de sites.
Vulnérabilité dans WPBakery
La **vulnérabilité** a été signalée par une analyse de sécurité et concerne le module Custom JS du **WPBakery Page Builder**. Selon le rapport initial publié par Wordfence, le module ne met pas en œuvre correctement la **sanitisation des entrées** ni l’**échappement en sortie**.
Concrètement, l’absence de **filtrage approprié des données entrantes** et d’**échappement des caractères à la sortie** signifie qu’un utilisateur disposant d’un accès au panneau d’édition (niveau **contributor** ou supérieur) peut enregistrer du code JavaScript arbitraire dans la base de données. Ce code est ensuite renvoyé aux visiteurs du site et s’exécute dans leur navigateur, ce qui constitue un cas typique de **Cross‑Site Scripting stocké (Stored XSS)**.
- Sanitisation des entrées : consiste à valider et nettoyer les données fournie par les utilisateurs avant de les stocker ou de les traiter.
- Échappement en sortie : transforme les caractères avec une signification HTML/JavaScript en sorties sûres au moment où ils sont insérés dans une page, pour éviter qu’ils ne soient interprétés comme du code exécutable.
La combinaison d’un filtrage insuffisant et d’un mauvais échappement permet aux données malveillantes de persister dans la base et d’être servies à chaque visite de la page vulnérable, exposant ainsi les visiteurs et l’ensemble du site à des risques allant du détournement de session jusqu’à l’injection de charges utiles plus complexes.
Plus précisément, cette faille est exploitable par des utilisateurs disposant d’un accès de type **contributor** (contributeur) ou supérieur. Le rapport identifie que les versions affectées du **plugin WPBakery** incluent toutes celles jusqu’à la **version 8.6.1**. Une version corrigée, la **8.7**, a été rendue disponible pour remédier à ce problème.
Impact et risques associés
Les conséquences d’une vulnérabilité de type **XSS stocké** sont larges :
- Vol de cookies et de tokens d’authentification ;
- Redirections malveillantes vers des sites d’hameçonnage ;
- Injection de scripts de minage, d’enregistreurs de frappe (keyloggers) ou d’autres charges utiles malveillantes ;
- Escalade d’attaques visant la modification de contenu, la création de comptes administrateurs ou la contamination d’autres pages du site.
Dans un contexte multisite ou lorsque le site est utilisé comme point d’accès pour des services tiers, une exploitation réussie peut avoir des effets en cascade au‑delà d’une simple compromission de page.
Versions concernées et mise à jour
La faille touche les versions du **WPBakery Page Builder** antérieures ou égales à la **8.6.1**. Les responsables techniques doivent s’assurer que leurs instances passent à la **version 8.7** ou supérieure, qui contient le correctif officiel.
Attention : si votre thème inclut **WPBakery** en tant que composant packagé, la mise à jour peut ne pas être déclenchée automatiquement par la page des extensions. Dans ce cas, contactez le fournisseur du thème ou consultez sa documentation pour obtenir la méthode recommandée afin d’appliquer le correctif. Parfois, vous devrez mettre à jour le thème lui‑même pour recevoir la version corrigée du plugin, ou remplacer le composant packagé par une installation indépendante du plugin via le répertoire des extensions.
Détection et vérification
Pour identifier si votre site est potentiellement touché :
- Vérifiez la version du **plugin WPBakery** dans la page Extensions de WordPress ou depuis le fichier readme du plugin.
- Consultez la base de données pour repérer des entrées liées au module **Custom JS** (par exemple des options contenant des scripts personnalisés). Des requêtes SQL ciblées ou des commandes WP‑CLI peuvent faciliter cette recherche.
- Effectuez une analyse de sécurité avec des outils réputés (par ex. scanners comme Wordfence, Sucuri ou d’autres solutions) pour détecter la présence de scripts injectés et de signatures malveillantes.
- Passez en revue les journaux d’activité et d’enregistrement (logs) pour repérer des opérations d’édition inattendues ou des modifications de contenu provenant d’utilisateurs disposant d’un accès mineur.
Solutions immédiates si la mise à jour n’est pas possible
Si, pour des raisons techniques ou de compatibilité, vous ne pouvez pas mettre immédiatement à jour vers la version 8.7, plusieurs mesures compensatoires peuvent réduire le risque d’exploitation :
- Restreindre temporairement les rôles utilisateur : retirez ou limitez les capacités des comptes ayant le rôle **contributor** ou supérieur, en particulier ceux qui n’ont pas besoin d’exécuter du JavaScript personnalisé.
- Désactiver ou restreindre l’accès au module **Custom JS** si votre configuration le permet (certains thèmes ou extensions de sécurité proposent des filtres pour désactiver des modules spécifiques).
- Utiliser un filtre personnalisé pour purger ou échapper le contenu provenant du champ Custom JS avant affichage, en appliquant des fonctions WordPress telles que esc_js(), esc_html(), esc_attr() ou wp_kses(), selon le contexte.
- Mettre en place une **Content Security Policy (CSP)** stricte afin d’empêcher l’exécution de scripts provenant de sources non approuvées — cela peut limiter l’impact d’un script injecté.
- Appliquer des règles de pare‑feu applicatif (WAF) au niveau du serveur ou via un service cloud, pour bloquer les tentatives connues d’injection de scripts.
Ces mesures ne remplacent pas un correctif officiel, mais elles offrent une réduction de risque temporaire jusqu’à ce que la mise à jour puisse être appliquée correctement.
Bonnes pratiques de prévention et durcissement
Pour minimiser la surface d’attaque et réduire la probabilité d’une compromission similaire à l’avenir, voici une liste de recommandations techniques et organisationnelles :
- Principe du moindre privilège : attribuez aux utilisateurs uniquement les rôles et capacités nécessaires à leurs tâches. Limitez les droits d’édition avancée (comme la création de JS personnalisé) à un nombre restreint de comptes fiables.
- Authentification renforcée : activez l’authentification à deux facteurs (2FA) pour les comptes disposant de droits d’édition ou d’administration.
- Mise à jour régulière : planifiez et testez les mises à jour des extensions et des thèmes dans un environnement de préproduction avant déploiement en production.
- Scanner et surveiller : utilisez des solutions de sécurité (WAF, scanners de malware, systèmes de détection d’intrusion) pour détecter rapidement les anomalies et les modifications non autorisées.
- Sauvegardes régulières : conservez des sauvegardes fréquentes et testez leur restauration pour pouvoir revenir rapidement à un état sain en cas d’incident.
- Revues de code : pour les développeurs et éditeurs de thèmes, faire auditer le code des modules critiques, en particulier ceux qui acceptent du contenu éditable par les utilisateurs.
- Éducation des utilisateurs : formez les contributeurs et éditeurs aux risques liés à l’injection de contenu et aux bonnes pratiques de sécurité.
Conseils spécifiques pour les auteurs de thèmes et développeurs
Les éditeurs de thèmes qui intègrent des plugins tiers, comme **WPBakery**, doivent suivre quelques règles pour limiter les risques :
- Éviter de modifier directement le code des plugins tiers ; préférez l’utilisation de hooks, filtres et surcharges proprement gérées.
- Fournir un mécanisme clair de mise à jour du plugin packagé, ou documenter la procédure permettant au site de recevoir les correctifs officiels.
- Testez la compatibilité des nouvelles versions du plugin dans un environnement contrôlé avant de fournir la mise à jour aux clients.
- Informer rapidement les utilisateurs lorsque des vulnérabilités sont découvertes et fournir des instructions techniques précises pour appliquer les correctifs.
Exemples de fonctions WordPress utiles pour l’assainissement et l’échappement
Pour les développeurs souhaitant implémenter un niveau de protection additionnel, WordPress fournit plusieurs fonctions utiles. Parmi les plus courantes :
- sanitize_text_field() — nettoie une chaîne de texte simple avant stockage ;
- wp_kses() / wp_kses_post() — autorisent uniquement un sous‑ensemble d’éléments HTML et d’attributs sûrs ;
- esc_html() — échappe une chaîne destinée à être affichée dans un contexte HTML ;
- esc_attr() — échappe les données destinées à un attribut HTML ;
- esc_js() — échappe les chaînes destinées à être insérées dans du JavaScript ;
- wp_nonce_field() / check_admin_referer() — aident à protéger les formulaires et actions contre les requêtes inter‑sites forgées (CSRF).
Appliquer correctement ces fonctions dans le flux de traitement des données (à l’entrée et à la sortie) réduit considérablement le risque d’injection de code malveillant.
Notes sur l’exploitation par des rôles limités
Il est important de comprendre que la vulnérabilité rapportée n’exige pas forcément un accès administrateur pour être exploitée : des comptes **contributeur** peuvent suffire, selon la configuration du site et les capacités qui leur ont été accordées. Cela rappelle l’importance de revoir périodiquement les rôles et les capacités, ainsi que d’auditer les comptes inactifs ou inconnus.
Procédure recommandée de remédiation
En tant que consultant et développeur, voici une séquence d’actions structurée à mener lorsque vous gérez une instance affectée :
- Identifier la version actuelle du **WPBakery** installée.
- Mettre immédiatement à jour le plugin à la version **8.7** ou supérieure si possible. Si le plugin est empaqueté dans le thème, obtenir la version mise à jour du thème ou appliquer la méthode de mise à jour fournie par l’éditeur du thème.
- Si la mise à jour n’est pas possible immédiatement, appliquer les mesures compensatoires listées ci‑dessus (restreindre les rôles, désactiver le module Custom JS, implémenter CSP, etc.).
- Scanner le site pour détecter toute injection persistante en utilisant plusieurs outils et en inspectant manuellement les options et contenus susceptibles de contenir du JavaScript personnalisé.
- Nettoyer toute entrée compromise identifiée et forcer la réinitialisation des sessions utilisateur si nécessaire (par ex. invalider les tokens, réinitialiser les cookies d’authentification).
- Documenter l’incident, les actions prises et planifier un audit post‑mortem pour éviter la récurrence.
Ressources et outils utiles
Plusieurs ressources et outils peuvent aider à diagnostiquer, corriger et surveiller les incidents liés à ce type de vulnérabilité :
- Solutions de scan de vulnérabilités et de signatures (par ex. Wordfence, Sucuri) ;
- Outils d’analyse de logs et de détection d’anomalies ;
- WP‑CLI pour interroger rapidement la base et rechercher des options/valeurs suspectes ;
- Services de WAF et de mise en cache qui offrent des règles spécifiques contre les tentatives d’injection XSS.
La combinaison d’outils de détection automatisée et d’examens manuels approfondis demeure la meilleure approche pour découvrir des traces subtiles d’exploitation.
Conclusion
La découverte d’une **vulnérabilité** dans le module **Custom JS** du **WPBakery Page Builder** met en lumière l’importance d’une gestion rigoureuse des extensions et de leurs modules, ainsi que des droits utilisateurs au sein d’un site WordPress. Une mise à jour vers la **version 8.7** est la solution officielle pour corriger la faille affectant les versions ≤ **8.6.1**. Toutefois, face à l’hétérogénéité des déploiements (notamment les plugins packagés dans des thèmes), il est crucial d’adopter une démarche de défense en profondeur : contrôles d’accès stricts, échappement/sanitisation systématiques, surveillance continue et procédures de réponse aux incidents bien rodées.
Featured Image by Shutterstock/3d artwork wallpaper
