WBase de données des vulnérabilités WordPress

Le groupe de cybersécurité de Hong Kong avertit sur le XSS de WPBakery (CVE202511160)

Plugin de constructeur de pages WPBakery pour WordPress
0
Partages
0
0
0
0
Nom du plugin Constructeur de pages WPBakery
Type de vulnérabilité XSS stocké
Numéro CVE CVE-2025-11160
Urgence Faible
Date de publication CVE 2025-10-15
URL source CVE-2025-11160

Constructeur de pages WPBakery <= 8.6.1 — XSS stocké via le module JS personnalisé (CVE-2025-11160) : Ce que les propriétaires de sites doivent faire maintenant

Introduction

Une vulnérabilité de Cross‑Site Scripting (XSS) stockée affectant WPBakery Page Builder (versions ≤ 8.6.1) a été divulguée comme CVE-2025-11160. Un attaquant avec des privilèges limités peut injecter du JavaScript qui est ensuite exécuté dans les navigateurs des visiteurs. Les sites qui permettent aux comptes de niveau contributeur ou similaires de créer ou d'éditer du contenu sont exposés.

Du point de vue d'un expert en sécurité de Hong Kong, ce rapport explique comment le problème fonctionne, qui est affecté, et les actions pratiques et immédiates que vous pouvez entreprendre : correction, modifications de configuration, détection/nettoyage de contenu, et concepts de patching virtuel avec des conseils génériques de WAF.

Résumé exécutif

  • Logiciel affecté : plugin WPBakery Page Builder (≤ 8.6.1)
  • Vulnérabilité : XSS stocké via le module JS personnalisé du plugin
  • CVE : CVE-2025-11160
  • Corrigé dans : 8.7 (mettez à jour immédiatement si possible)
  • Privilège requis pour l'exploitation (signalé) : Contributeur (ou éditeur de bas niveau équivalent)
  • Risque : Les attaquants qui peuvent créer ou éditer du contenu de constructeur de pages peuvent stocker des charges utiles JavaScript qui s'exécutent dans les navigateurs des visiteurs (redirections, vol de cookies, détournement de session, distribution de contenu malveillant).
  • Atténuation immédiate : Mettez à jour vers 8.7+, restreignez l'accès aux modules JS personnalisés, recherchez/nettoyez le contenu du site, appliquez des règles de WAF/patching virtuel pour bloquer l'injection de scripts.

Comment cette vulnérabilité fonctionne (explication simple)

Le XSS stocké survient lorsque des entrées non fiables sont enregistrées et ensuite rendues sans une désinfection ou un encodage de sortie appropriés. Ici, le module “JS personnalisé” du plugin permettait aux contributeurs de sauvegarder du contenu JS et de l'inclure dans les modèles de page sur le front-end. Comme le contenu pouvait inclure du JavaScript brut ou des attributs d'événements DOM, les visiteurs d'une page affectée exécuteraient le code fourni par l'attaquant. Le seul privilège requis est la capacité d'ajouter ou d'éditer ce module personnalisé, généralement disponible pour les rôles de contributeur/auteur.

Pourquoi le XSS stocké est dangereux

Le XSS stocké est particulièrement grave car le code malveillant persiste sur le site et s'exécute pour chaque visiteur d'une page infectée. Les conséquences typiques incluent :

  • Vol de cookies de session et prise de contrôle de compte (lorsque les cookies ne sont pas correctement sécurisés)
  • Redirections silencieuses vers des domaines malveillants
  • Spam SEO et injection de contenu non autorisé
  • Cryptominage basé sur le navigateur ou fraude publicitaire
  • Attaques secondaires et persistance (portes dérobées, élévation de privilèges)

Comprendre l'impact et la gravité

CVE‑2025‑11160 est corrigé dans 8.7. Certaines évaluations ont placé le CVSS autour de 6.5. Les scores numériques sont utiles, mais le risque dans le monde réel dépend du contexte :

  • Les pages à fort trafic utilisant Custom JS augmentent l'exposition.
  • Une mauvaise hygiène des comptes (mots de passe partagés, pas de MFA) augmente la probabilité d'exploitation.
  • Une population de visiteurs incluant des utilisateurs privilégiés (éditeurs, administrateurs) peut augmenter l'impact.

Étant donné l'utilisation courante de comptes contributeurs/auteurs pour la gestion de contenu, répondez rapidement.

Actions immédiates (étape par étape)

  1. Mettez à jour WPBakery Page Builder vers 8.7 ou une version ultérieure.

    C'est la correction définitive. Mettez à niveau via l'administration WordPress ou votre processus de déploiement dès que possible. Si des mises à niveau immédiates sont impossibles (tests de compatibilité, grandes flottes), appliquez les atténuations ci-dessous.

  2. Restreindre l'accès à la fonctionnalité “Custom JS”.

    Révoquez temporairement l'accès contributeur/auteur aux modules permettant Custom JS. Si vous utilisez des gestionnaires de rôles, retirez les capacités pour les rôles non fiables d'éditer les modules du constructeur de pages.

  3. Scannez le site à la recherche de scripts malveillants et de contenu suspect.

    Recherchez des balises script et des modèles XSS courants dans les publications, pages, postmeta et données stockées du constructeur de pages (exemples ci-dessous).

  4. Appliquez des règles WAF/de patch virtuel.

    Mettez en œuvre des règles qui bloquent les requêtes tentant d'injecter