| Nom du plugin | WPFAQBlock |
|---|---|
| Type de vulnérabilité | Scripts intersites (XSS) |
| Numéro CVE | CVE-2026-1093 |
| Urgence | Faible |
| Date de publication du CVE | 2026-03-23 |
| URL source | CVE-2026-1093 |
WPFAQBlock XSS stocké (CVE-2026-1093) : Ce que les propriétaires de sites WordPress et les développeurs doivent faire maintenant
Publié : 23 mars 2026
En tant que professionnels de la sécurité WordPress, nous surveillons en continu les vulnérabilités des plugins qui mettent les sites web en danger. Une vulnérabilité récemment divulguée dans le WPFAQBlock — Bloc FAQ & Accordéon pour Gutenberg (versions <= 1.1) — est un problème de Cross-Site Scripting (XSS) stocké authentifié qui mérite une attention immédiate.
Cet article explique, en termes simples et en détail technique, ce qu'est la vulnérabilité, comment les attaquants peuvent (et le font souvent) essayer d'abuser du XSS stocké, qui est le plus à risque, comment vous pouvez détecter des signes de compromission, et des étapes pratiques et prioritaires que vous devriez prendre maintenant pour protéger votre site. Je montrerai également des modèles de codage sécurisé que les développeurs peuvent adopter pour prévenir des problèmes similaires, et comment les options de protection de WP-Firewall (y compris le plan gratuit) peuvent vous aider à atténuer les risques pendant que vous corrigez ou supprimez le plugin vulnérable.
Note: J'éviterai de partager du code d'exploitation ou des recettes d'attaque étape par étape. L'objectif ici est de permettre aux propriétaires de sites, aux administrateurs et aux développeurs de défendre leurs sites — pas d'aider les attaquants.
Résumé exécutif (court)
- Vulnérabilité : XSS stocké via le
classeattribut shortcode dans le plugin WPFAQBlock (<= 1.1). - CVE attribué : CVE-2026-1093.
- Privilège requis pour créer l'entrée malveillante : Contributeur (authentifié).
- CVSS : 6.5 (modéré). L'exploitation nécessite une interaction d'utilisateur privilégié pour se déclencher dans certains scénarios.
- Atténuation immédiate : supprimez ou désactivez le plugin si vous ne pouvez pas le mettre à jour, restreignez les privilèges des contributeurs et la publication de contenu, assainissez les entrées existantes, et activez un WAF/patch virtuel jusqu'à ce que le plugin soit corrigé.
- À long terme : appliquez une assainissement sécurisé des entrées dans le code du plugin, adoptez des pratiques de moindre privilège, et effectuez une surveillance continue.
Que s'est-il passé — en termes simples
WPFAQBlock contient une faiblesse dans la façon dont il gère le classe attribut sur sa sortie de shortcode FAQ. Un utilisateur authentifié malveillant avec des privilèges de niveau Contributeur peut soumettre un attribut de classe conçu qui est stocké dans la base de données et ensuite affiché non assaini dans les pages ou l'éditeur. Lorsque la valeur non assainie est rendue, elle peut provoquer l'exécution de JavaScript malveillant dans le navigateur de quiconque consulte la page — potentiellement des éditeurs de site, des administrateurs, ou même des visiteurs — selon la façon dont le plugin place l'attribut dans le contexte HTML.
Le terme “ XSS stocké ” signifie que le contenu malveillant est persistant sur le serveur (dans les publications, les métadonnées ou le stockage spécifique au plugin) et servi aux clients plus tard, ce qui peut donner aux attaquants un point d'ancrage fiable à long terme. Dans ce cas spécifique, l'exploitation de la vulnérabilité nécessite une interaction supplémentaire d'un utilisateur privilégié (par exemple, un administrateur ou un éditeur consultant le contenu affecté). Cela réduit l'immédiateté par rapport à un XSS totalement non authentifié, mais c'est toujours un risque réel et dangereux pour tout site qui permet des comptes de niveau contributeur ou a des éditeurs qui pourraient consulter du contenu dans le panneau d'administration ou en frontend.
Pourquoi le XSS stocké est dangereux
Le XSS stocké est fréquemment utilisé dans des campagnes réelles en raison de sa persistance et de sa portée :
- Si un attaquant peut injecter du JavaScript dans le contenu livré à un administrateur, l'attaquant peut escalader l'accès (voler des cookies ou des jetons de session) et détourner des sessions d'administration, permettant une prise de contrôle complète du site.
- Le JavaScript peut modifier le balisage de la page pour livrer d'autres attaques d'ingénierie sociale (faux avis de mise à jour, collecteurs de données d'identification).
- Des scripts malveillants peuvent rediriger les visiteurs vers des sites de phishing ou de malware, ou charger des scripts de cryptominage et d'autres contenus indésirables.
- Parce que la charge utile est stockée, une seule injection peut impacter de nombreux utilisateurs au fil du temps et est facile à propager.
Même si une vulnérabilité nécessite une interaction supplémentaire, cette interaction peut être conçue (lien de phishing, page admin spécialement conçue, ou un éditeur sans méfiance visualisant le mauvais post) — donc le risque reste réel pour tout site qui accepte du contenu de rôles moins fiables.
Qui est à risque
- Sites utilisant des versions de WPFAQBlock <= 1.1.
- Sites qui permettent au rôle de Contributeur ou à d'autres utilisateurs non fiables de créer du contenu — en particulier les sites qui permettent aux Contributeurs de soumettre des shortcodes, du HTML ou d'autres attributs sans modération.
- Sites où les éditeurs et les administrateurs parcourent le site ou le contenu du bloc dans l'interface admin (par exemple, en prévisualisant des posts ou en visualisant l'interface utilisateur du plugin).
- Blogs multi-auteurs, sites d'adhésion, plateformes d'apprentissage, et toute installation WordPress qui accorde la création de contenu à plusieurs utilisateurs authentifiés.
Si votre site n'autorise pas les comptes de Contributeur ou des rôles équivalents, et que vous êtes certain qu'aucun utilisateur non fiable ne peut ajouter ou modifier du contenu, le risque pratique est plus faible. Mais vous devriez tout de même inspecter votre contenu pour des entrées malveillantes et garder un œil sur les téléchargements et les modifications de la base de données.
À quoi pourrait ressembler une chaîne d'attaque typique (niveau élevé)
- L'attaquant crée un compte contributeur ou compromet un compte existant à faible privilège.
- L'attaquant soumet un nouveau bloc FAQ ou édite un post, fournissant une valeur d'attribut conçue
classequi contient du contenu malveillant. - Le plugin stocke l'attribut conçu dans la base de données sans désinfection ni échappement appropriés.
- À un moment ultérieur, un administrateur ou un éditeur visite la page ou ouvre des prévisualisations de posts dans l'admin WordPress (ou le balisage malveillant est rendu sur le frontend).
- Le script stocké s'exécute dans le navigateur de l'utilisateur privilégié ; le script peut envoyer les cookies ou les jetons d'authentification de l'admin au serveur de l'attaquant ou effectuer des actions au nom de cet utilisateur (par exemple, créer un compte admin).
- Avec un accès de niveau supérieur, l'attaquant peut faire n'importe quoi, de l'installation d'une porte dérobée à l'exfiltration de données ou à la défiguration du site.
Ce scénario souligne pourquoi le XSS stocké dans les flux de travail d'édition de contenu est particulièrement risqué : il exploite le comportement normal de gestion de contenu pour escalader l'accès.
Indicateurs de compromission — quoi rechercher
Lors de l'examen de cette vulnérabilité, surveillez :
- Nouveaux posts, FAQ ou pages créés par des comptes contributeurs contenant des shortcodes ou inhabituels
classevaleurs d'attributs suspectes. - Extraits JavaScript inattendus apparaissant dans le code source de la page où WPFAQBlock rend le contenu.
- Administrateurs ou éditeurs recevant des redirections suspectes ou des popups inattendus lors du chargement de pages spécifiques.
- Nouveaux comptes administrateurs ou changements de rôle d'utilisateur suspects peu après qu'un contributeur a publié du contenu.
- Fichiers inexpliqués dans le répertoire des téléchargements ou modifications des fichiers de plugin/thème.
- Connexions sortantes du site vers des domaines inconnus (points de terminaison d'exfiltration possibles).
- Alertes de votre scanner de sécurité ou WAF indiquant des tentatives XSS ou des charges utiles bloquées.
Vous pouvez rechercher dans la base de données des occurrences du shortcode FAQ ou des marqueurs spécifiques au plugin. Par exemple, recherchez post_content pour le nom du shortcode (par exemple, [faq ou HTML spécifique au plugin) et examinez les attributs suspects. Si vous voyez un balisage comme HTML injecté dans le classe attribut ou des attributs avec des chevrons, c'est un signal d'alerte.
Réponse immédiate — actions prioritaires
Si vous êtes responsable d'un site qui utilise WPFAQBlock (<=1.1), suivez cette liste de contrôle de réponse priorisée maintenant :
- Si possible, mettez à jour le plugin immédiatement
– Vérifiez si l'auteur du plugin a publié une version corrigée. Si une version mise à jour est disponible, mettez à jour via le tableau de bord WordPress ou WP-CLI.
– Si une mise à jour n'est pas encore disponible, passez à l'étape 2. - Désactivez temporairement ou supprimez le plugin si vous ne pouvez pas appliquer de correctif immédiatement
– La désactivation empêche le rendu ultérieur du code vulnérable et supprime le chemin d'exécution immédiat.
– Si vous avez besoin de la fonctionnalité, envisagez de la remplacer par une alternative sûre. - Restreindre la publication et les soumissions des contributeurs
– Interdire temporairement aux contributeurs de publier ou de créer du contenu sans révision éditoriale.
– Convertissez les comptes de contributeurs à un niveau de privilège inférieur, ou activez la modération pour le contenu avant sa publication. - Effectuez un audit de contenu
– Recherchez dans les tables post_content et plugin meta le shortcode FAQ et inspectez lesclassevaleurs d'attribut pour un contenu suspect.
– Supprimez ou assainissez toutes les entrées suspectes trouvées. Utilisez une exportation de base de données et une recherche/remplacement minutieuse (évitez la corruption accidentelle des données) ou gérez avec WP-CLI et un remplacement assaini. - Activez ou renforcez les protections WAF (patching virtuel)
– Configurez le pare-feu de votre site web pour bloquer les valeurs d'attribut suspectesclassedans les shortcodes et bloquez les requêtes qui semblent essayer d'injecter des scripts dans les attributs.
– Si vous avez déjà un WAF géré, assurez-vous que les signatures pour cette vulnérabilité sont appliquées ou demandez à votre fournisseur de pare-feu une règle temporaire. - Renforcez les rôles et permissions des utilisateurs
– Appliquez le principe du moindre privilège. Seuls les utilisateurs de confiance devraient avoir la permission de créer des shortcodes ou du HTML non filtré.
– Auditez les comptes utilisateurs pour des comptes inconnus et changez les mots de passe des utilisateurs administrateurs. - Scannez à la recherche de logiciels malveillants
– Effectuez une analyse complète du site pour détecter d'éventuelles portes dérobées, scripts plantés ou fichiers de base/plugin modifiés. - Surveiller les journaux et le trafic réseau
– Recherchez des connexions administratives suspectes, de nouveaux téléchargements de plugins/thèmes et des connexions sortantes vers des hôtes inconnus. - Si vous soupçonnez une compromission, suivez un flux de réponse aux incidents
– Isolez le site si nécessaire, restaurez à partir de sauvegardes propres (avant injection), changez les identifiants et effectuez un examen forensic complet.
Si l'une de ces étapes dépasse votre zone de confort, contactez votre fournisseur d'hébergement ou un professionnel de la sécurité WordPress qualifié.
Exemples d'atténuation à court terme (sûrs, non destructifs)
- Utilisez l'éditeur WordPress ou un éditeur de texte pour remplacer
class="..."les occurrences dans les shortcodes stockés par une valeur assainie ou supprimez complètement l'attribut pour les publications créées récemment par des utilisateurs à faible confiance. - Créez un plugin temporaire qui filtre le contenu produit par WPFAQBlock pour assainir le
classeattribut avant la sortie. Exemple de filtre de sécurité squelette :
<?php<>"\']+/', '', $safe );
Note: Les modifications basées sur des expressions régulières peuvent être fragiles. Testez sur un site de staging et sauvegardez votre base de données avant d'effectuer des modifications massives.
Guide pour les développeurs — comment corriger cela en toute sécurité dans le code
Si vous maintenez ou développez des plugins/blocs, suivez ces pratiques de codage sécurisées :
- Ne jamais supposer que les attributs (même quelque chose d'aussi inoffensif que
classe) sont sûrs. Assainir à l'entrée et échapper à la sortie.- Utiliser
assainir_champ_texte()pour des attributs de texte simples. - Utiliser
wp_kses()/wp_kses_allowed_html()où HTML est nécessaire, et définir strictement les balises et attributs autorisés. - Lors de la sortie des attributs dans HTML, utilisez toujours
esc_attr()pour les contextes d'attribut etesc_html()pour les contextes HTML.
- Utiliser
- Exemple de modèle de gestionnaire de shortcode sécurisé :
<?php
- Validez les capacités pour toute action qui stocke des données des utilisateurs. Ne permettez pas aux utilisateurs de niveau Contributeur de stocker du HTML arbitraire à moins qu'il ne soit strictement filtré et modéré.
- Utilisez des nonces et des vérifications de capacité sur tout point de terminaison AJAX ou REST qui accepte des données pour des shortcodes ou du contenu de bloc.
- Préférez la liste blanche côté serveur plutôt que la liste noire : définissez les caractères et modèles autorisés pour des attributs comme
classe.
Comment WP-Firewall vous protège (ce que nous recommandons et pourquoi)
Chez WP-Firewall, nous fournissons des défenses en couches qui réduisent la fenêtre d'exposition aux vulnérabilités comme celle-ci :
- Règles WAF gérées : notre pare-feu d'application web inclut des règles pour détecter et bloquer les modèles d'injection d'attributs suspects, y compris les tentatives de placer des balises ou des scripts dans des attributs tels que
classe. Cela bloque la plupart des tentatives automatisées et de nombreuses attaques manuelles. - Scanner de logiciels malveillants : Nous recherchons des charges utiles malveillantes connues et des scripts anormaux dans les pages et les téléchargements.
- Atténuation des 10 principales vulnérabilités OWASP : Le plan gratuit comprend des protections ciblées sur des vecteurs courants tels que les attaques XSS et par injection.
- Patching virtuel (Pro) : Si une vulnérabilité de plugin est divulguée et qu'un correctif n'est pas encore publié ou si vous ne pouvez pas mettre à jour immédiatement, notre patching virtuel peut atténuer la vulnérabilité au niveau de l'application web jusqu'à ce que vous installiez la mise à jour officielle.
- Surveillance et alertes : Une activité suspecte (tentatives répétées de créer ou de produire des attributs malveillants, anomalies de connexion admin) déclenche des alertes afin que vous puissiez agir rapidement.
Si vous gérez un site affecté par ce problème WPFAQBlock et que vous ne pouvez pas mettre à jour le plugin immédiatement, activer le WAF géré de WP-Firewall et le scan de logiciels malveillants réduira considérablement la chance d'exploitation réussie pendant que vous remédiez.
Manuel de détection et de récupération (étapes détaillées)
- Prenez un instantané / une sauvegarde
– Exportez votre base de données et vos fichiers pour une analyse judiciaire et un point de restauration. Si le site est activement compromis, isolez-le (mode maintenance). - Corrigez ou supprimez le composant vulnérable
– S'il existe une version de plugin corrigée : mettez à jour et vérifiez.
– S'il n'y a pas encore de correctif : désactivez et remplacez le plugin ou bloquez tous les chemins de rendu. - Identifiez et supprimez le contenu malveillant
– Recherchez des attributs de shortcode suspects, en particulierclasseles entrées contenant des chevrons, des gestionnaires d'événements (une erreur,sur clic),JavaScript :, des séquences similaires à , ou du contenu encodé en base64.
– Supprimez ou assainissez ces entrées, et republiez le contenu après révision. - Vérifiez l'activité et les comptes des utilisateurs
– Vérifiez l'activité récente des contributeurs. Verrouillez ou réinitialisez les mots de passe pour tous les comptes qui semblent suspects. Supprimez les comptes inutilisés.
– Activez l'authentification à deux facteurs pour les comptes admin et éditeur. - Scannez le site
– Utilisez un scanner de logiciels malveillants réputé pour localiser les portes dérobées ou les fichiers suspects dans les thèmes, les téléchargements et les répertoires de plugins. - Journaux d'audit
– Examinez les journaux d'accès du serveur web et les journaux de débogage de WordPress pour trouver des preuves d'injection, de requêtes POST inhabituelles et de connexions sortantes. - Restaurez et surveillez
– Une fois nettoyé et corrigé, restaurez les services et surveillez de près les tentatives répétées. Maintenez un état de surveillance accru pendant au moins deux semaines.
Conseils pratiques pour les propriétaires de sites et les éditeurs
- Limitez qui peut créer du contenu : Ce petit avantage de permettre aux contributeurs de publier sans révision comporte un risque de sécurité. Utilisez la révision éditoriale lorsque cela est possible.
- Désactiver
unfiltered_htmlcapacité pour les rôles non fiables. Même si WordPress restreint le HTML non filtré aux administrateurs par défaut, les plugins peuvent changer le comportement — donc vérifiez régulièrement les capacités des rôles. - Utilisez une politique de sécurité du contenu (CSP) pour restreindre d'où les scripts peuvent se charger. CSP est une couche supplémentaire efficace qui rend de nombreuses attaques XSS beaucoup moins utiles.
- Activez une authentification forte (2FA) pour tous les comptes ayant des capacités de publication.
- Gardez un serveur de staging et testez les mises à jour des plugins avant de les appliquer sur les sites de production.
- Planifiez des sauvegardes régulières et vérifiez que les sauvegardes sont restaurables.
Pour les hébergeurs et les opérateurs de plateforme
- Appliquez des processus d'intégration des éditeurs et de vérification des comptes pour rendre l'abus de crédentiels plus difficile.
- Offrez des options de modération de contenu et des notifications par e-mail aux propriétaires de sites lorsque les contributeurs créent du nouveau contenu.
- Fournissez des protections WAF par défaut et mettez un patch virtuel à la disposition des clients jusqu'à ce que les mises à jour des plugins soient disponibles.
- Surveillez les comportements anormaux des éditeurs ou un grand nombre de shortcodes/attributs ajoutés en peu de temps.
Pourquoi vous devriez prendre cela au sérieux (contexte réel)
Les attaquants ciblent de plus en plus les écosystèmes de plugins WordPress car des millions de sites utilisent des composants communs. Les vulnérabilités dans des plugins mineurs peuvent avoir des effets démesurés lorsqu'elles permettent une élévation de privilèges ou fournissent un accès aux comptes administrateurs. Même lorsque la capacité d'injection initiale est limitée aux comptes à faible privilège, le XSS stocké peut être utilisé pour prendre le contrôle complet du site en trompant un administrateur ou un éditeur.
Si vous êtes un développeur de plugins ou de blocs, considérez à quel point un mauvais encodage de sortie peut se comporter dangereusement dans des flux d'édition complexes. Si vous êtes un propriétaire de site, supposez que le contenu non fiable peut devenir un vecteur — et planifiez en conséquence.
Liste de contrôle échantillon — référence rapide
- [ ] Confirmez la version du plugin : WPFAQBlock <= 1.1 est-il installé ?
- [ ] Mettez à jour le plugin (si un correctif est disponible) ou désactivez le plugin maintenant.
- [ ] Auditer le post_content et le stockage spécifique aux plugins pour des attributs de shortcode suspects.
- [ ] Restreindre les privilèges des contributeurs et exiger une approbation éditoriale.
- [ ] Activer ou ajuster les règles WAF pour bloquer l'injection de scripts basée sur des attributs.
- [ ] Scanner les fichiers malveillants et inspecter les connexions récentes des administrateurs.
- [ ] Sauvegarder et, si nécessaire, restaurer à partir d'une sauvegarde connue comme bonne.
- [ ] Renforcer les comptes : réinitialiser les mots de passe, activer l'authentification à deux facteurs.
- [ ] Documenter l'incident et revoir la posture de sécurité pour prévenir la récurrence.
Pour les développeurs : modèles à éviter et à adopter
Éviter :
- Écho direct des attributs fournis par l'utilisateur dans le HTML sans assainissement.
- Compter uniquement sur l'assainissement côté client.
- Permettre aux rôles de niveau contributeur de fournir du HTML brut, des attributs ou des scripts sans vérifications côté serveur.
Adopter :
- Liste blanche côté serveur et échappement via les fonctions de base de WordPress (
assainir_champ_texte,wp_kses,esc_attr,echapper_html). - Validation explicite des attributs (n'accepter que les caractères ou les modèles de jetons que vous attendez pour
classe,identifiant, etc.). - Vérifications de nonce et de capacité sur les points de terminaison REST et les gestionnaires AJAX.
- Journalisation et échec gracieux : si un attribut fourni est invalide, le supprimer ou le remplacer par une valeur par défaut sûre, et enregistrer l'événement pour audit.
Comment nettoyer en toute sécurité le contenu stocké (approche exemple)
- Mettre votre site en mode maintenance et sauvegarder tout.
- Exporter les publications dans un fichier pour inspection hors ligne, ou rechercher dans la base de données les occurrences du shortcode (par exemple, utiliser WP-CLI :
wp post list --post_type=post --format=idset inspectezcontenu_du_post). - Pour chaque entrée suspecte, inspectez manuellement dans un environnement sûr, puis assainissez ou supprimez l'attribut.
- Si vous devez effectuer des remplacements automatiques, utilisez WP-CLI ou un script testé et vérifiez avec un diff avant d'appliquer.
Encore une fois : ne jamais exécuter de remplacements automatiques destructeurs sur des bases de données en direct sans une sauvegarde testée et un exécution en staging.
Comment notre équipe chez WP-Firewall aborde un problème comme celui-ci
Lorsqu'une nouvelle divulgation XSS stockée authentifiée apparaît, nos équipes de sécurité et d'ingénierie :
- Analyser les détails de la vulnérabilité pour déterminer les points de terminaison et les contextes de rendu impactés.
- Créer des règles WAF qui ciblent spécifiquement les modèles de rendu non sécurisés (par exemple, des valeurs d'attribut suspectes contenant des crochets angulaires, des attributs d'événement comme onerror, ou
JavaScript :des modèles dans les attributs). - Déployer des correctifs virtuels aux clients gérés pour bloquer les tentatives d'exploitation pendant que le fournisseur de plugin publie un correctif officiel.
- Fournir des conseils de remédiation étape par étape pour les propriétaires de sites et les hébergeurs.
- Surveiller les tentatives d'exploitation et mettre à jour les signatures à mesure que de nouvelles tactiques apparaissent.
Cette approche en couches réduit le risque pour les propriétaires de sites qui ne peuvent pas immédiatement mettre à jour ou supprimer le plugin vulnérable.
Protégez votre site aujourd'hui avec le plan gratuit de WP-Firewall
Si vous souhaitez une protection immédiate pendant que vous examinez ou corrigez la vulnérabilité WPFAQBlock, envisagez de commencer avec le plan de base WP-Firewall (gratuit). Il fournit des protections essentielles qui comptent en ce moment :
- Pare-feu géré avec des règles adaptées aux menaces WordPress
- Protections WAF pour bloquer les vecteurs XSS et d'injection courants
- Bande passante illimitée (pas de limites de requêtes cachées)
- Analyse de logiciels malveillants pour détecter les scripts malveillants connus
- Atténuations préconfigurées pour les risques du Top 10 de l'OWASP
Inscrivez-vous ici au forfait gratuit : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
La mise à niveau ultérieure est simple : Standard ajoute la suppression automatique de logiciels malveillants et des capacités de liste noire/blanche d'IP, et Pro ajoute le patching virtuel automatique, des rapports de sécurité mensuels et des services gérés premium si vous souhaitez une remédiation active et un support de compte.
Réflexions finales
Les vulnérabilités XSS stockées comme le problème WPFAQBlock soulignent une vérité perpétuelle de la sécurité WordPress : de petites erreurs dans la gestion des entrées peuvent entraîner de grandes violations. La différence entre une vulnérabilité et un incident est souvent la rapidité avec laquelle un propriétaire de site détecte et atténue le risque.
Priorisez : mettez à jour les plugins lorsque des correctifs sont disponibles, limitez qui peut publier du contenu, assainissez et validez toutes les entrées utilisateur, et exécutez un WAF et un scanner de logiciels malveillants dans le cadre d'une défense en couches. Si vous utilisez WPFAQBlock (<= 1.1), agissez maintenant : mettez à jour, désactivez ou appliquez des mesures d'atténuation temporaires. Si vous avez besoin d'une protection temporaire pendant que vous remédiez, le plan gratuit de WP-Firewall offre une couverture immédiate WAF et scanner pour réduire le risque.
Si vous souhaitez de l'aide pour examiner votre site concernant ce problème ou pour déployer rapidement des règles de protection, nos ingénieurs en opérations de sécurité peuvent vous aider avec des évaluations et des options de patch virtuel.
Restez en sécurité — et considérez chaque mise à jour de plugin comme un événement de sécurité jusqu'à preuve du contraire.
