Nom du plugin	Constructeur de pages Bold
Type de vulnérabilité	Scripts intersites (XSS)
Numéro CVE	CVE-2026-3694
Urgence	Moyen
Date de publication du CVE	2026-05-13
URL source	CVE-2026-3694

Bold Page Builder (<= 5.6.8) — XSS stocké pour contributeur authentifié (CVE-2026-3694) — Risque, Détection & Atténuation Pratique avec WP‑Firewall

Date: 2026-05-14
Auteur: Équipe de sécurité WP-Firewall
Mots clés: WordPress, WAF, XSS, Vulnérabilité, Bold Page Builder, Réponse aux Incidents

Résumé: Une vulnérabilité de script intersite stocké (XSS) (CVE-2026-3694) affectant les versions de Bold Page Builder <= 5.6.8 permet à un contributeur authentifié de stocker une charge utile qui peut s'exécuter lorsque qu'un utilisateur privilégié interagit avec la page/builder affectée. Le problème a été corrigé dans la version 5.6.9. Cet article explique le risque, les scénarios d'exploitation, les méthodes de détection, les recommandations de durcissement et comment WP‑Firewall peut aider à protéger votre site immédiatement — y compris un patch virtuel temporaire pendant que vous planifiez la mise à jour.

En bref (en un coup d'œil)

• Vulnérabilité: XSS stocké
• Plugin concerné : Bold Page Builder (WordPress)
• Versions vulnérables : <= 5.6.8
• Corrigé dans : 5.6.9
• CVE : CVE-2026-3694
• CVSS (signalé) : 6.5
• Privilège requis pour injecter : Contributeur (utilisateur authentifié)
• Nuance d'exploitation : interaction de l'utilisateur requise (exécution déclenchée lorsque qu'un utilisateur privilégié consulte ou interagit avec un contenu conçu)
• Remédiation immédiate : Mettre à jour le plugin vers 5.6.9 ou une version ultérieure ; si vous ne pouvez pas, appliquez un patch virtuel / règle(s) WAF et restreignez les privilèges

Pourquoi cela compte — impact dans le monde réel expliqué par les experts de WP‑Firewall

Le XSS stocké est dangereux car le code malveillant injecté dans le contenu persiste dans votre base de données et s'exécute dans les navigateurs des utilisateurs du site qui consultent ce contenu. Lorsqu'un utilisateur authentifié à faible privilège (un Contributeur) peut stocker un tel contenu, le danger le plus sérieux est une réaction en chaîne :

• Le script injecté peut s'exécuter dans le navigateur d'un éditeur, d'un administrateur ou d'un autre utilisateur privilégié lorsqu'il charge la page dans l'éditeur de site, l'aperçu ou l'interface du builder. Ce script peut alors :
  • Voler des cookies d'authentification ou des jetons de session (menant à une prise de contrôle de compte).
  • Effectuer des actions non désirées dans le contexte de l'utilisateur privilégié (modifier des paramètres, créer des portes dérobées, exporter des données).
  • Planter d'autres charges utiles persistantes ou rediriger vers des pages de phishing.
• Les attaquants automatisent souvent la découverte : une fois la vulnérabilité connue, des campagnes de masse tenteront d'enregistrer ou de compromettre des comptes de niveau Contributeur sur de nombreux sites et de stocker des charges utiles.

Parce que l'exploitation ici nécessite l'interaction d'un utilisateur privilégié, ce n'est pas une prise de contrôle à distance entièrement autonome — mais c'est pratique et largement exploité dans la nature contre les écosystèmes CMS. Tout site où des contributeurs, des rédacteurs invités ou des créateurs de contenu externes peuvent utiliser le builder de page est à risque jusqu'à ce qu'il soit corrigé ou protégé.

Comment l'attaque se déroule généralement (niveau élevé)

1. L'attaquant enregistre ou compromet un compte de Contributeur (ou utilise un Contributeur existant).
2. En utilisant l'interface du builder de page ou les entrées fournies par le plugin, l'attaquant stocke un balisage malveillant (conçu pour contourner des filtres naïfs) dans le contenu des publications ou les champs du builder de page.
3. Un utilisateur privilégié (Éditeur/Admin) ouvre plus tard la page dans le builder ou l'aperçu, ou clique sur un lien conçu qui déclenche la charge utile malveillante. Parce que l'utilisateur privilégié a de plus grandes capacités, la charge utile peut effectuer des actions privilégiées dans le contexte du navigateur.
4. L'attaquant exploite le contexte de navigateur privilégié pour escalader (vol de cookies, actions CSRF, stockage de contenu supplémentaire/backdoors), pouvant éventuellement aboutir à une compromission totale du site.

Note: La description de la vulnérabilité indique “Interaction de l'utilisateur requise” — ce qui signifie que l'attaque n'est pas triviale à armer pour s'exécuter automatiquement sur des visiteurs anonymes. Elle nécessite qu'un utilisateur privilégié consulte ou interagisse avec le contenu stocké.

Détection : signes que vous pourriez déjà être affecté

Si vous enquêtez pour savoir si votre site a été ciblé ou compromis, recherchez les indicateurs suivants.

Vérifications de la base de données et du contenu

• Publications, pages et méta de constructeur de pages contenant des balises suspectes telles que <script, onerror=, onload=, ou des attributs suspects avec des URI javascript:.
• JavaScript inattendu intégré dans le contenu des publications, postmeta, ou champs JSON/meta du constructeur.
• Nouveau contenu ou contenu modifié rédigé par des comptes de contributeurs que le propriétaire du site ne reconnaît pas.

Audit WordPress et journaux d'activité

• Enregistrements de contenu inexpliqués, en particulier par des comptes de contributeurs.
• Activité d'administrateur/éditeur peu après l'ajout de contenu par des utilisateurs à privilèges inférieurs.
• Nouvelles inscriptions d'utilisateurs suivies de changements immédiats de contenu de page.

Journaux du serveur et d'accès

• Requêtes vers des points de terminaison de constructeur (points de terminaison AJAX) avec des chaînes base64 inhabituelles ou un contenu semblable à une charge utile dans les corps POST.
• Requêtes qui mènent à des actions d'utilisateur privilégié peu après qu'un contributeur ait enregistré du contenu.

Indicateurs de système de fichiers

• Nouveaux fichiers placés dans les répertoires de téléchargements ou de plugins/thèmes correspondant aux moments d'activité suspecte.
• Fichiers PHP modifiés ou fichiers avec un contenu obfusqué (recherchez base64_decode, eval, etc.).

Artefacts post-exploitation

• Nouveaux utilisateurs administrateurs créés de manière inattendue.
• Connexions sortantes inattendues du site vers des IP externes (exfiltration de données).
• Tâches cron modifiées ou événements planifiés qui déclenchent du code malveillant.

Interrogation avec des requêtes

Utilisez des requêtes SQL ou WP-CLI pour rechercher des charges utiles probables. Exemples de commandes WP‑CLI (à exécuter dans un environnement sûr ou après une sauvegarde) :

# Trouver des publications contenant <script"

Soyez conscient : le contenu légitime peut contenir des scripts dans certains cas d'utilisation, mais lorsqu'il est trouvé dans des champs de constructeur ou attribué à des comptes de contributeurs, traitez-le comme suspect.

Plan de réponse immédiate (que faire maintenant)

1. Sauvegarde
   • Effectuez une sauvegarde complète du site (base de données + fichiers). C'est crucial avant de faire des changements.
2. Appliquez un correctif si possible
   • Mettez à jour Bold Page Builder vers 5.6.9 ou une version ultérieure immédiatement dans un environnement de staging, puis en production une fois vérifié.
3. Si vous ne pouvez pas mettre à jour immédiatement, appliquez des contrôles de protection :
   • Mettez le site en mode maintenance pour les environnements à haut risque pendant que vous appliquez des atténuations.
   • Utilisez un pare-feu d'application web (WAF) pour bloquer les charges utiles d'exploitation probables (patching virtuel). WP‑Firewall peut déployer rapidement des règles de blocage pour prévenir les tentatives d'exploitation contre les modèles connus sans attendre la mise à jour du plugin.
   • Restreignez temporairement qui peut utiliser le constructeur de pages :
     • Limitez l'accès au constructeur de pages aux Éditeurs+ (ou rôles de confiance).
     • Supprimez la possibilité pour les Contributeurs d'utiliser le plugin de constructeur de pages lorsque cela est possible.
4. Faire tourner les identifiants et les clés
   • Forcez les réinitialisations de mot de passe pour Administrateur, Éditeur et tous les utilisateurs privilégiés.
   • Faites tourner les sels de WordPress (mettez à jour l'AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY dans wp-config.php). Remarque : cela invalide toutes les connexions existantes — utile après une compromission de compte suspectée.
   • Révoquez les clés API ou les intégrations si suspectes.
5. Scannez et enquêtez
   • Exécutez une analyse de malware et un contrôle d'intégrité des fichiers (par exemple, comparez avec des copies propres).
   • Recherchez dans la base de données et postmeta des modèles suspects comme indiqué ci-dessus.
   • Vérifiez les journaux d'accès autour des moments où du contenu suspect a été créé.
6. Remédiation (si vous trouvez une compromission)
   • Supprimez le contenu malveillant et les portes dérobées.
   • Réinstallez les fichiers de base/plugin/thème avec des copies connues comme bonnes.
   • Restaurez à partir d'une sauvegarde propre si nécessaire et plus sûr.

Comment WP‑Firewall aide (patching virtuel et protection pendant que vous mettez à jour)

En tant que fournisseur de pare-feu WordPress, nous recommandons une approche en couches : protection WAF immédiate + mises à jour de code + durcissement des rôles + surveillance en temps réel.

• Patching virtuel : WP‑Firewall peut appliquer des règles ciblées qui bloquent les tentatives d'exploitation correspondant à des modèles malveillants connus pour cette vulnérabilité. Cela empêche les charges utiles XSS stockées d'être enregistrées ou exécutées dans de nombreux flux d'attaque courants.
• Filtrage des requêtes par rôle : les règles peuvent être ajustées pour être plus strictes pour les requêtes provenant d'utilisateurs à faible privilège (par exemple, Contributeurs). Par exemple, les POST provenant de sessions de Contributeurs qui incluent des balises de script HTML ou des modèles d'attributs suspects peuvent être bloqués ou assainis.
• Prévenir l'exécution : WP‑Firewall peut injecter des en-têtes préventifs (Content-Security-Policy) et appliquer une validation des entrées lorsque cela est possible, réduisant le risque que des charges utiles stockées s'exécutent dans le navigateur d'un utilisateur privilégié.
• Surveillance et alertes : Des alertes en temps réel sur les tentatives bloquées et l'activité suspecte vous aident à réagir rapidement.
• Réponse assistée aux incidents : conseils et soutien pour le triage, le nettoyage et un durcissement supplémentaire.

Ci-dessous, nous fournissons des exemples de logique de règles et de mitigations non invasives que WP‑Firewall appliquerait pendant que vous planifiez la mise à jour du plugin.

Exemple de logique de règle WAF (conceptuel, sûr à mettre en œuvre)

Important: les exemples suivants sont des règles conceptuelles pour expliquer l'approche. Les règles exactes doivent être testées en staging pour éviter les faux positifs ou de casser les flux de travail légitimes des éditeurs.

1. Bloquer les requêtes POST provenant de comptes de Contributeurs authentifiés qui contiennent des modèles semblables à des scripts :
   • Conditions de déclenchement :
     • Méthode de requête = POST vers les points de terminaison du constructeur (par exemple, /wp-admin/admin-ajax.php ou des points de terminaison spécifiques au plugin).
     • Rôle d'utilisateur authentifié = Contributeur.
     • Le corps de la requête contient des séquences insensibles à la casse : <script, JavaScript :, onerror=, onload=, et alerter l'administrateur.
2. Limiter le taux et bloquer les tentatives automatisées :
   • Soumissions de posts suspectes multiples depuis la même IP ou compte → réduire et bloquer.

Exemples de motifs pseudo-regex (à titre d'illustration) :

• (?i)<\s*script\b
• (?i)on(error|load|mouseover|focus)\s*=
• (?i)javascript\s*:

Encore une fois : le réglage est important. De nombreux cas d'utilisation légitimes existent pour inclure des scripts en toute sécurité (par exemple, intégrer des scripts via des hooks d'éditeur appropriés), donc WP‑Firewall limitera les règles aux requêtes provenant de rôles à faible confiance ou aux API de constructeur spécifiques aux plugins.

Recommandations de durcissement pour les propriétaires de sites et les développeurs

1. Tenez tout à jour
   • Mettez à jour Bold Page Builder vers 5.6.9 ou une version ultérieure dès que possible.
   • Gardez les autres plugins, thèmes et le cœur de WordPress à jour.
2. Renforcez la gestion des rôles et des capacités
   • Restreindre l'accès au constructeur de pages aux rôles de confiance.
   • Minimisez l'utilisation de unfiltered_html capacité — elle ne devrait être réservée qu'aux Administrateurs ou aux éditeurs de confiance.
   • Envisagez un examen des rôles : supprimez les capacités inutiles des utilisateurs de niveau Contributeur.
3. Assainir et échapper
   • Assurez-vous que les développeurs utilisent un échappement approprié sur la sortie :
     • Utiliser esc_html(), esc_attr() et wp_kses_post() le cas échéant.
     • Pour les champs JSON du constructeur ou les méta-champs spécialisés, validez et assainissez les données structurées lors de l'enregistrement.
   • Pour le code de thème ou de plugin personnalisé : ne jamais afficher le contenu fourni par l'utilisateur sans assainissement/échappement.
4. Nonces et vérifications de capacité
   • Vérifiez les nonces et current_user_can() les vérifications de capacité sur tous les points de terminaison qui enregistrent le contenu du constructeur ou le postmeta.
   • Évitez de faire confiance aux validations côté client ; appliquez des vérifications côté serveur.
5. Limitez le contenu externe et les intégrations.
   • Utilisez une politique de sécurité du contenu (CSP) adaptée à votre site pour bloquer les scripts en ligne ou restreindre les sources de scripts autorisées aux domaines de confiance.
   • Envisagez de bloquer l'exécution des scripts en ligne avec une CSP stricte tout en évaluant le comportement existant du site.
6. Formation des éditeurs et processus.
   • Formez les éditeurs/admins à prévisualiser le nouveau contenu dans un environnement isolé et sûr avant de modifier en production.
   • Encouragez un flux de travail où les contributeurs soumettent des brouillons qui sont d'abord examinés sur la mise en scène.
7. Surveillance et enregistrement
   • Activez la journalisation des activités pour les modifications de contenu et les actions des utilisateurs.
   • Surveillez les journaux WAF pour les tentatives bloquées et enquêtez sur les motifs répétés.

Pour les développeurs : liste de contrôle de codage sécurisé liée aux XSS dans les constructeurs.

• Validez et assainissez tous les champs du constructeur lors de l'enregistrement :
  • Pour les champs uniquement textuels : utilisez assainir_champ_texte().
  • Pour un HTML limité : utilisez wp_kses() avec une liste blanche stricte.
  • Pour les champs HTML riches : utilisez wp_kses_post() et, le cas échéant, une définition KSES personnalisée limitant les attributs et les protocoles.
• Évitez de stocker du HTML ou du javascript fournis par l'utilisateur brut dans les métadonnées sans assainissement explicite.
• Lors du rendu des données dans les pages d'administration ou les boîtes méta, appliquez des fonctions d'échappement :
  • esc_html() pour les nœuds de texte.
  • esc_attr() pour les attributs.
  • wp_kses_post() si vous autorisez du HTML sûr.
• Ajoutez des vérifications de capacité sur tous les points de terminaison AJAX et REST :
  • si ( ! current_user_can( 'edit_posts' ) ) { wp_send_json_error( 'Permissions insuffisantes' ); }
• Utilisez des nonces pour prévenir le CSRF sur les points de terminaison de sauvegarde.

Liste de contrôle de réponse à un incident et de récupération (post-détection)

1. Instantané : prenez un instantané judiciaire (journaux, dump de base de données, liste de fichiers).
2. Endiguement:
   • Appliquez des règles WAF et/ou désactivez temporairement le plugin vulnérable (si possible).
   • Bloquez les comptes utilisateurs et les IP suspects.
3. Éradication:
   • Supprimez le contenu malveillant des publications/meta.
   • Supprimez ou nettoyez les portes dérobées (recherchez des fichiers PHP dans les téléchargements, des tâches cron suspectes).
4. Récupération:
   • Réinstallez les fichiers de base/plugin/thème à partir de sources fiables.
   • Restaurez à partir d'une sauvegarde connue comme propre si l'intégrité du site ne peut être assurée.
5. Après l'incident :
   • Faites tourner tous les secrets (clés API, clés wp-config.php, mots de passe administrateur).
   • Réalisez un post-mortem et renforcez les processus pour prévenir la récurrence.

Criminalistique : requêtes et vérifications spécifiques de la base de données

• Trouvez des publications avec des scripts en ligne :

  SELECT ID, post_title, post_author, post_date;
    

• Trouvez des meta de constructeur de page suspects :

  SELECT post_id, meta_key;
    

• Exportez le contenu suspect vers un environnement hors ligne sécurisé pour analyse plutôt que de l'ouvrir dans le navigateur.

Communications et divulgation — quoi dire aux parties prenantes

• Soyez transparent en interne : informez les propriétaires de site et les éditeurs de la situation, des actions attendues et des délais.
• Si vous gérez des sites pour des clients, communiquez le risque, les mesures prises (règle WAF, calendrier de mise à jour) et les actions recommandées pour leur équipe (par exemple, changement de mot de passe forcé).
• Documentez les actions entreprises, les journaux collectés et les indicateurs de compromission (IOC) pour de potentielles futures audits.

Stratégie à long terme : réduire la dépendance aux frontières de confiance des plugins

• Limiter l'accès aux constructeurs de pages tiers uniquement aux utilisateurs de confiance.
• Pour les environnements à haut risque (par exemple, les blogs multi-auteurs avec de nombreux contributeurs externes), envisager :
  • Un flux de travail de révision qui déplace le contenu vers une zone de staging pour approbation par un éditeur.
  • Interdire les constructeurs de pages pour les contributeurs de niveau intermédiaire/bas ou fournir un sous-ensemble restreint de fonctionnalités du constructeur.
• Adopter une approche de défense en profondeur :
  • Renforcer WordPress (moindres privilèges, configuration sécurisée).
  • Appliquer un WAF qui peut déployer rapidement des correctifs virtuels.
  • Surveiller et alerter sur les sauvegardes de contenu suspectes et les élévations de privilèges.

Chronologie d'atténuation échantillon (recommandée)

• T = 0–24 heures
  • Sauvegarder le site, activer un correctif virtuel WAF temporaire pour les modèles de vulnérabilité, restreindre l'accès au constructeur aux rôles de confiance.
• T = 24–72 heures
  • Mettre à jour Bold Page Builder vers 5.6.9 dans un environnement de staging ; tester les flux de travail critiques et les modèles de constructeur personnalisés.
  • Promouvoir en production et vérifier.
• T = 72 heures – 2 semaines
  • Effectuer une analyse complète du site pour détecter tout contenu malveillant résiduel ou portes dérobées.
  • Faire tourner les identifiants administratifs et les sels WordPress (si une compromission est suspectée).
  • Examiner les rôles des utilisateurs et les resserrer si nécessaire.
• En cours
  • Surveiller les journaux WAF et l'activité du site, maintenir le plugin à jour.
  • Intégrer les apprentissages des incidents dans le processus d'intégration, d'attribution des rôles et de révision du contenu.

Prévenir des problèmes similaires à l'avenir (politiques pratiques)

• Politique de moindre privilège : les contributeurs devraient avoir des capacités minimales ; les éditeurs devraient examiner tous les changements de contribution avant publication.
• Politique de vérification des plugins : n'activer les constructeurs de pages que pour les plugins de confiance et examinés et limiter au minimum les modules de constructeur tiers.
• Flux de travail en priorité sur la mise en scène pour le contenu des contributeurs externes.
• Audits de sécurité réguliers et tests de pénétration axés sur les interfaces d'édition de contenu.

Exemples concrets (comment cette classe de vulnérabilité a été exploitée)

(Seulement à un niveau élevé — nous ne publions pas de code d'exploitation.)

• Les attaquants téléchargent des XSS stockés via des champs de constructeur et attendent qu'un administrateur ouvre le constructeur. Lorsque l'administrateur lance l'aperçu du constructeur, un script vole le jeton de session de l'administrateur et l'escalade.
• Les charges utiles persistantes sont combinées avec l'ingénierie sociale : l'attaquant laisse un contenu marqué comme “ nécessite une révision ” puis envoie un e-mail avec un lien incitant un éditeur à cliquer ; lorsque l'éditeur clique, le code malveillant s'exécute dans son navigateur.
• Chaînes : le XSS stocké initial conduit à un compromis d'administrateur, qui est ensuite utilisé pour télécharger un plugin malveillant ou modifier des fichiers de thème pour obtenir un accès distant persistant.

Ce sont des problèmes courants et évitables avec des mises à jour et des défenses en couches.

Ce qu'il faut changer dans votre politique WP‑Firewall pour une protection par étapes

• Ajouter une signature temporaire pour la vulnérabilité qui :
  • Inspecte les corps POST vers les points de terminaison du constructeur pour les balises de script et les gestionnaires d'événements lorsqu'ils proviennent de comptes de contributeurs.
  • Bloque ou assainit le contenu de la réponse du serveur pour les pages d'aperçu du constructeur lorsque des motifs suspects sont présents.
• Activer une journalisation stricte pour les événements bloqués et notifier l'administrateur du site en temps réel.
• Configurer une action d'atténuation automatisée : lorsque N tentatives bloquées se produisent dans une courte fenêtre depuis une IP ou un utilisateur, mettre le compte utilisateur en quarantaine et limiter les demandes.

Commandes et vérifications utiles (opérationnelles)

• Rechercher des scripts dans tous les postmeta (exécuter depuis l'hôte avec accès à la base de données) :

  mysql -u wpuser -p -D wpdb -e "SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%onerror=%' LIMIT 500;"
    

• Faites une exportation en lecture seule des lignes suspectes pour une analyse hors ligne :

  mysqldump -u wpuser -p wpdb wp_posts --where="post_content LIKE '% suspicious_posts.sql
    

Protégez votre site immédiatement — essayez le plan gratuit WP‑Firewall

Si vous ne l'avez pas déjà fait, protégez votre site dès maintenant avec le plan gratuit WP‑Firewall. Vous bénéficierez d'une protection essentielle et gérée, y compris un pare-feu géré, une bande passante illimitée, des règles WAF adaptées à WordPress, un scanner de logiciels malveillants automatisé et des atténuations ciblant les risques OWASP Top 10 — tout ce dont vous avez besoin pour arrêter les campagnes d'exploitation de masse et bloquer des menaces comme le XSS de Bold Page Builder pendant que vous mettez à jour.

Commencez avec le plan gratuit : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Note: Si vous avez besoin d'une suppression automatique des logiciels malveillants, d'un contrôle de liste noire/blanche d'IP ou de patching virtuel à grande échelle, nos plans Standard et Pro étendent les capacités de protection et de support en cas d'incident.

Liste de contrôle finale — ce que vous devez faire maintenant

• Sauvegarder les fichiers et la base de données.
• Mettez à jour Bold Page Builder vers 5.6.9 (testez d'abord sur la mise en scène).
• Si vous ne pouvez pas mettre à jour immédiatement, activez le patching virtuel WP‑Firewall et bloquez les modèles connus contre les points de terminaison du constructeur.
• Restreignez l'accès au constructeur aux rôles de confiance (Éditeurs+).
• Recherchez dans la base de données des scripts ou des attributs d'événements suspects (voir les requêtes ci-dessus).
• Changez les mots de passe administratifs et les sels WordPress si vous trouvez une activité suspecte.
• Surveillez les journaux WAF et définissez des notifications pour les tentatives bloquées.

Remarques de clôture de l'équipe WP‑Firewall

Cette vulnérabilité met en évidence un thème récurrent : les parties les plus risquées d'un CMS sont souvent les interfaces où des utilisateurs à faible privilège peuvent stocker du HTML ou du contenu structuré. Les constructeurs de pages sont puissants — mais cette puissance s'accompagne de risques. Appliquer des correctifs rapidement est essentiel, mais dans les environnements de production, vous ne pourrez pas toujours mettre à jour immédiatement. C'est précisément là qu'un WAF géré et le patching virtuel jouent un rôle crucial : ils vous donnent du temps et bloquent l'exploitation active pendant que vous effectuez une mise à jour et un nettoyage approfondis et sûrs.

Si vous souhaitez de l'aide pour trier un incident spécifique, ou si vous avez besoin d'assistance pour appliquer un patch virtuel en toute sécurité à votre environnement, notre équipe de sécurité est disponible pour vous guider tout au long du processus. Utilisez le tableau de bord WP‑Firewall pour appliquer des protections immédiates, ou en savoir plus sur nos niveaux payants si vous avez besoin d'une remédiation automatisée et d'un support en cas d'incident.

Restez en sécurité et mettez à jour tôt.

— Équipe de sécurité WP-Firewall