Gutentor XSS (CVE-2026-2951) : Ce que les propriétaires de sites WordPress doivent savoir et comment WP-Firewall vous protège

Publié le 2026-04-23 par l'équipe de sécurité WP-Firewall

Résumé: Une vulnérabilité de Cross-Site Scripting (XSS) stockée a été divulguée affectant le plugin Gutentor (versions ≤ 3.5.5). Elle permet à un contributeur authentifié d'injecter du HTML pouvant exécuter du JavaScript dans certains contextes. Cet article explique le risque, les scénarios d'exploitation, les étapes de détection et de confinement, la remédiation et le durcissement à long terme — ainsi que des moyens pratiques par lesquels WP-Firewall vous aide à atténuer l'exposition immédiatement, même si vous ne pouvez pas mettre à jour tout de suite.

Table des matières

• Contexte : que s'est-il passé
• Résumé technique de la vulnérabilité
• Qui est à risque et pourquoi
• Scénarios d'exploitation réalistes
• Actions immédiates (mise à jour, confinement, détection)
• Comment rechercher des indicateurs de compromission (IoCs) en toute sécurité
• Durcissement et changements de configuration (court et long terme)
• Conseils aux développeurs : modèles de codage sécurisés pour le bloc HTML
• Stratégie WAF et règles recommandées (patching virtuel)
• Liste de contrôle pour la surveillance, la réponse et le nettoyage
• Comment WP-Firewall peut aider (y compris les détails du plan gratuit)
• Annexe : commandes et requêtes rapides

Contexte : que s'est-il passé

Le 23 avril 2026, une vulnérabilité de Cross-Site Scripting (XSS) stockée affectant le plugin Gutentor — Gutenberg Blocks / Page Builder a été divulguée publiquement (suivie sous le nom de CVE-2026-2951). Le problème impacte les versions de Gutentor jusqu'à et y compris 3.5.5. Le fournisseur a publié une version corrigée (3.5.6) pour résoudre le problème.

Faits clés en un coup d'œil :

• Classe de vulnérabilité : Cross-Site Scripting (XSS) stocké
• Versions affectées : ≤ 3.5.5
• Version corrigée : 3.5.6
• CVE : CVE-2026-2951
• Privilège requis pour injecter : Contributeur (utilisateur authentifié)
• Exploitation : Nécessite une interaction utilisateur (un utilisateur privilégié doit déclencher le payload)

Il s'agit d'un XSS stocké typique dans un plugin qui accepte du contenu HTML provenant de comptes moins privilégiés (contributeurs) et le restitue d'une manière qui permet l'exécution de scripts. Bien que l'acteur initial n'ait besoin que d'un accès de niveau Contributeur pour stocker le payload, d'autres actions sont nécessaires pour exploiter pleinement le problème — ce qui rend la vulnérabilité quelque peu moins triviale à utiliser en masse, mais toujours sérieuse pour des attaques ciblées, des flux de travail éditoriaux de haute confiance, ou des sites qui acceptent les contributions des utilisateurs.

Résumé technique de la vulnérabilité

À un niveau élevé, le bug est causé par une sanitation/échappement insuffisante de l'HTML fourni à un bloc Gutentor qui accepte du HTML brut (souvent étiqueté “ Gutentor Block HTML ” ou similaire). Les contributeurs (ou rôles supérieurs) peuvent insérer du HTML dans un bloc qui est stocké dans le contenu du post ou les métadonnées du bloc. Comme la sortie n'est pas correctement échappée ou filtrée, cet HTML stocké peut s'exécuter dans le contexte du navigateur d'un utilisateur privilégié plus tard — par exemple, lorsque un éditeur, un admin ou un autre utilisateur avec des privilèges supérieurs charge le post dans l'éditeur admin, l'aperçu, ou certains chemins de rendu public.

Propriétés techniques importantes :

• Le point d'injection est un bloc qui permet du HTML en libre forme (le bloc HTML Gutentor).
• Le payload est stocké dans la base de données (XSS stocké), pas réfléchi.
• L'exécution nécessite une action de suivi par un autre utilisateur (interaction utilisateur), comme ouvrir le post dans l'admin, prévisualiser le post, ou cliquer sur un lien spécialement conçu qui provoque le rendu du bloc malveillant.
• Le contexte du site rend cela utile pour des chaînes d'escalade de privilèges (voler des cookies, effectuer des actions dans l'interface admin via le navigateur de la victime, installer des portes dérobées, etc.), selon les protections du navigateur et les privilèges admin.

Comme l'attaque est stockée, elle peut persister à travers les chargements de page et affecter plusieurs utilisateurs au fil du temps.

Qui est à risque et pourquoi

Tous les sites WordPress utilisant Gutentor ne sont pas également à risque. Considérez les facteurs de risque suivants :

• Les sites utilisant Gutentor ≤ 3.5.5 (non corrigé) sont vulnérables.
• Les sites qui permettent aux comptes de Contributeur (ou tout rôle permettant de créer des posts/blocs) pour des utilisateurs externes, des auteurs invités, ou des éditeurs de faible confiance sont à risque plus élevé.
• Les sites avec plusieurs éditeurs/admins qui prévisualisent ou éditent régulièrement du contenu sont à risque plus élevé — le payload nécessite une interaction d'utilisateur privilégié.
• Les sites où les contributeurs peuvent télécharger ou créer du contenu sans sanitation manuelle sont à risque plus élevé.
• Les sites de grande valeur (e-commerce, adhésion, publications éditoriales) sont des cibles attrayantes pour les attaquants afin d'obtenir un accès admin.

Si vous gérez un site qui utilise Gutentor, confirmez la version du plugin installé et si vous permettez aux contributeurs de créer des posts ou aux éditeurs de prévisualiser du contenu non fiable.

Scénarios d'exploitation réalistes

Comprendre les chemins d'attaque vous aide à prioriser et à atténuer. Voici des scénarios plausibles qu'un attaquant pourrait utiliser pour tirer parti de cette vulnérabilité :

1. Escalade ciblée à travers le flux de travail éditorial
   • L'attaquant s'inscrit (ou utilise un compte existant) avec des permissions de niveau Contributeur.
   • L'attaquant crée un post ou un brouillon et insère un bloc HTML Gutentor contenant un payload malveillant.
   • Un éditeur ou un administrateur ouvre le post dans l'éditeur admin (ou en aperçu) et la charge utile s'exécute dans leur navigateur, permettant le vol de session ou l'action en leur nom.
2. Ingénierie sociale pour déclencher une action privilégiée
   • L'attaquant crée du contenu et envoie un lien décrivant une raison apparemment innocente pour qu'un admin/éditeur clique (par exemple, “Veuillez examiner ce brouillon”).
   • L'utilisateur privilégié suit le lien et la charge utile XSS stockée s'active.
3. Persistance multi-étapes + porte dérobée
   • Après l'exécution initiale, le XSS injecte un code supplémentaire (par exemple, pour ajouter un utilisateur admin ou télécharger un plugin de porte dérobée) — limité par ce qui peut être fait uniquement depuis le contexte du navigateur, mais faisable si la session admin est active et que le site manque de protections supplémentaires.
4. Vecteur d'attaque exposé au public
   • Si le site rend le bloc publiquement sans assainissement, les visiteurs pourraient également être affectés — mais cette vulnérabilité, telle que rapportée, met l'accent sur le vecteur admin/utilisateur privilégié.

En résumé : un contributeur peut créer du contenu qui attend qu'un utilisateur privilégié l'ouvre ; lorsque l'utilisateur privilégié le fait, l'attaquant obtient la capacité d'exécuter du JS dans le contexte de cet utilisateur.

Actions immédiates que vous devez prendre (premières 24 à 72 heures)

1. Mettez à jour le plugin vers 3.5.6 ou une version ultérieure (priorité maximale)
   • C'est la solution définitive. Si possible, mettez à jour immédiatement sur tous les environnements (production, staging).
   • Si vous ne pouvez pas mettre à jour immédiatement, mettez en œuvre les atténuations temporaires ci-dessous.
2. Contention si vous ne pouvez pas mettre à jour immédiatement
   • Restreindre temporairement la capacité des contributeurs : désactiver les nouvelles inscriptions de contributeurs ou révoquer les attributions de rôle de contributeur jusqu'à ce que vous ayez mis à jour.
   • Exiger que les brouillons des contributeurs soient examinés dans un environnement de staging d'abord.
   • Supprimez ou désactivez le bloc HTML Gutentor (si possible) via les paramètres du plugin ou les restrictions de l'éditeur de blocs.
3. Scanner pour du contenu suspect
   • Recherchez dans vos posts et le contenu des blocs des balises script, des gestionnaires d'événements (onmouseover, onclick), des URI javascript : et des charges utiles encodées. Consultez l'annexe pour des conseils de recherche sûrs et des requêtes WP-CLI.
4. Forcer la ré-authentification pour les utilisateurs privilégiés
   • Demandez aux administrateurs et aux éditeurs de se déconnecter et de se reconnecter après que vous ayez corrigé ou contenu le site. Cela aide à réduire la fenêtre de risque pour le vol de session.
5. Renforcer la surveillance et la journalisation
   • Surveillez les journaux d'activité des administrateurs, les créations de nouveaux utilisateurs, les modifications de plugins et les publications récemment éditées.
   • Utilisez les journaux de votre serveur web et les résultats des analyses de sécurité pour repérer les anomalies.
6. Si un compromis est suspecté
   • Isolez le site (page de maintenance) si vous détectez une activité malveillante dans l'administration ou des fichiers modifiés.
   • Suivez les procédures de réponse aux incidents (préservez les journaux, prenez un instantané du site, puis nettoyez).

La mise à jour est l'atténuation la plus simple et la plus efficace. Les autres étapes sont des compensations défensives pendant que vous mettez à jour.

Comment rechercher des indicateurs de compromission (IoCs) en toute sécurité

Lorsque vous recherchez un contenu d'exploitation possible, n'exécutez pas et ne chargez pas le contenu dans un navigateur. Utilisez des recherches basées sur du texte et des requêtes de base de données.

Conseils de recherche sécurisée :

• Utilisez wp-cli pour rechercher dans le contenu de la base de données des HTML suspects (non exécutables).
• Recherchez des balises script et des gestionnaires d'événements dans post_content et postmeta.

Exemples de commandes WP-CLI (à exécuter depuis un terminal avec un accès approprié) :

• Recherchez des publications pour “<script” :

  wp db query "SELECT ID, post_title, post_author FROM wp_posts WHERE post_content LIKE '%<script%';"

• Recherchez des attributs on* (onmouseover, onclick) :

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%onmouseover=%' OR post_content LIKE '%onclick=%';"

• Recherchez des blocs stockés liés à Gutentor :

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%gutentor%' AND (post_content LIKE '%<script%' OR post_content LIKE '%on%=%');"

Alternative : Exportez la base de données ou utilisez un dump texte et recherchez avec grep pour <script, onerror=, JavaScript :. Manipulez toujours les données exportées de manière sécurisée.

Si vous trouvez un contenu suspect, traitez-le comme un compromis potentiel. Ne prévisualisez pas les publications dans l'administration sans d'abord retirer ou isoler le bloc suspect.

Renforcement et modifications de configuration (court et long terme)

Court terme (appliquez immédiatement si possible) :

• Mettez à jour Gutentor vers 3.5.6 ou une version ultérieure.
• Limitez qui peut créer des publications ou utiliser des blocs (supprimez le rôle de contributeur là où il n'est pas nécessaire).
• Désactivez le bloc HTML de Gutentor pour les rôles non fiables si possible.
• Appliquez des mots de passe forts et activez l'authentification à deux facteurs pour tous les utilisateurs ayant des privilèges d'éditeur/admin.
• Assurez-vous que l'édition de fichiers via le tableau de bord WordPress est désactivée (définir('DISALLOW_FILE_EDIT', vrai);).
• Assurez-vous que les plugins et thèmes sont à jour et supprimez les plugins inutilisés.

A long terme :

• Appliquez le principe du moindre privilège : accordez uniquement aux rôles les capacités minimales requises.
• Utilisez des processus de révision de contenu : les brouillons des contributeurs doivent être conservés dans une file d'attente et examinés par des éditeurs de confiance dans un environnement sécurisé.
• Mettez en œuvre une journalisation et une alerte centralisées pour les activités administratives et les modifications de contenu.
• Maintenez un site de staging pour les tests de plugins ; ne mettez pas à jour uniquement en production.
• Effectuez des analyses automatisées périodiques pour détecter les XSS et les versions de plugins connus comme vulnérables.

Guide pour les développeurs : modèles de codage sécurisés pour le HTML de bloc et les entrées utilisateur brutes

Si vous développez des blocs Gutenberg ou maintenez des thèmes/plugins qui acceptent des entrées HTML, suivez ces modèles sécurisés :

• Nettoyez à l'entrée lorsque cela est approprié
  Pour le HTML soumis par les utilisateurs, utilisez wp_kses() ou wp_kses_post() avec des balises et des attributs strictement autorisés.
  Ne comptez pas sur la sanitation côté client — appliquez un filtrage côté serveur.
• Échappement à la sortie
  Échappez toujours les données lors du rendu : esc_html(), esc_attr(), esc_url(), ou wp_kses_post() selon le contexte.
  Pour les blocs qui rendent du HTML interne, envisagez de rendre du contenu nettoyé plutôt que du HTML brut.
• Utilisez des capacités et des nonces
  Validez les capacités des utilisateurs avant d'accepter et de stocker du contenu pouvant affecter le rendu de la page.
  Utiliser wp_verify_nonce() pour les soumissions de formulaires et vérifiez les arguments de capacité de l'API REST.
• Limitez les fonctionnalités dangereuses
  Si l'objectif d'un bloc ne nécessite pas de HTML brut, évitez de l'offrir. Fournissez des alternatives sûres (par exemple, du texte enrichi avec un formatage contrôlé).
  Si le HTML brut est nécessaire pour les éditeurs de confiance, limitez son utilisation aux rôles supérieurs.
• Stockage et balisage auditable
  Stockez les entrées brutes dans les métadonnées uniquement lorsque cela est nécessaire et documentez pourquoi cela est requis.
  Fournissez des outils d'interface utilisateur administrateur pour prévisualiser la sortie assainie.
• Journalisation et surveillance
  Enregistrez lorsque des utilisateurs privilégiés créent ou modifient du contenu contenant du HTML brut pour audit.

Appliquez ces modèles à tous les endroits acceptant du HTML ou des attributs arbitraires (shortcodes, attributs de bloc, postmeta).

Stratégie WAF et règles recommandées (patching virtuel)

Si vous ne pouvez pas mettre à jour immédiatement, utiliser un pare-feu d'application (WAF) ou un patch virtuel est une solution temporaire efficace. Voici des stratégies défensives qu'un WAF devrait mettre en œuvre pour bloquer ou atténuer les tentatives d'attaque ciblant ce XSS Gutentor.

Objectifs de haut niveau du WAF pour cette vulnérabilité :

• Bloquez la soumission de contenu dangereux semblable à des scripts dans les blocs HTML de Gutentor par des demandes de rôle de contributeur.
• Prévenez l'exploitation au moment du rendu en assainissant les réponses contenant des attributs suspects.
• Limitez le taux de comportement d'édition/soumission suspect de comptes non fiables.

Protections recommandées (règles conceptuelles — ajustez pour votre environnement) :

1. Bloquez les soumissions qui incluent 5. des balises ou des gestionnaires d'événements suspects dans les flux de création/modification de publications provenant de comptes de contributeurs ou de demandes non authentifiées.
   • Detect encoded script tags (e.g., script) and common obfuscations.
   • Faites correspondre le type de contenu et les chemins de requête qui gèrent la soumission de publications (wp-admin/post.php, points de terminaison REST).
2. Bloquez les attributs avec des gestionnaires d'événements “on” (onclick, onerror, onmouseover) dans le contenu soumis par des comptes à faible privilège.
3. Bloquez les URI “javascript:” dans les attributs href/src provenant de comptes à faible privilège.
4. Protégez les points de terminaison de rendu (pages publiques et points de terminaison de prévisualisation) en supprimant ou en neutralisant 5. les balises dans la réponse si elles apparaissent à l'intérieur des conteneurs de blocs Gutentor, ou en insérant des en-têtes de politique de sécurité du contenu (CSP) (voir ci-dessous).
5. Utilisez une règle WAF pour appliquer des politiques basées sur les capacités : si la demande est authentifiée en tant que Contributeur ou inférieur, validez ou assainissez activement des champs spécifiques (bloquez ou transformez les entrées dangereuses).
6. Implémentez un correctif virtuel pour la sortie spécifique du bloc Gutentor :
   • Détectez le balisage du bloc Gutentor dans la réponse et effectuez un filtrage de sortie côté serveur pour supprimer les scripts et les attributs on*.

Suggestion de politique de sécurité du contenu (CSP) :

Ajoutez une CSP stricte qui interdit les scripts en ligne pour les pages administratives lorsque cela est possible : Content-Security-Policy: default-src 'self'; script-src 'self' https:; object-src 'none'; — mais soyez prudent : une CSP trop stricte peut casser des plugins ou des fonctionnalités administratives ; testez d'abord sur la mise en scène.

Remarque : les règles WAF doivent être testées sur la mise en scène pour éviter les faux positifs. WP-Firewall fournit des options WAF gérées et de correctifs virtuels pour mettre en œuvre ces protections sans modifications immédiates du code (voir la section des fonctionnalités de WP-Firewall ci-dessous).

Liste de contrôle pour la surveillance, la réponse et le nettoyage

Si vous soupçonnez que cette vulnérabilité a été exploitée ou si vous trouvez un contenu suspect, suivez ces étapes prioritaires :

1. Instantané et sauvegarde
   • Créez immédiatement une sauvegarde complète (base de données + fichiers) et marquez-la comme immuable à des fins d'analyse judiciaire.
2. Contenir
   • Mettez le site en mode maintenance si une compromission active est suspectée.
   • Révoquez ou verrouillez les comptes utilisateurs suspects.
   • Faites tourner les identifiants administratifs et FTP.
3. Enquêter
   • Examinez les modifications récentes et les nouveaux articles pour détecter du HTML malveillant.
   • Vérifiez les nouveaux utilisateurs administratifs ajoutés, les plugins ou les tâches planifiées (entrées cron).
4. Remédier
   • Supprimez les blocs HTML malveillants ou assainissez-les.
   • Supprimez tous les scripts ou fichiers de porte dérobée ajoutés au serveur.
   • Réinstallez le plugin à partir d'une source propre si des fichiers sont modifiés.
5. Récupérer
   • Mettez à jour tous les plugins/thèmes/noyau vers des versions corrigées.
   • Renforcez les identifiants et activez l'authentification à deux facteurs.
   • Réactivez les services et continuez à surveiller.
6. Suite à l'incident
   • Faites tourner les secrets et les clés API qui pourraient être en mémoire.
   • Effectuez une analyse complète des logiciels malveillants et un audit de sécurité.
   • Communiquez avec les parties prenantes et documentez les détails de l'incident.

Si vous manquez de ressources de sécurité internes, envisagez de faire appel à un fournisseur de sécurité géré pour effectuer le nettoyage et le renforcement post-incident.

Comment WP-Firewall aide — protections immédiates et continues

Chez WP-Firewall, nous concevons nos services pour protéger les sites WordPress à plusieurs niveaux — du renforcement préventif au patching virtuel en temps réel et à la remédiation. Pour cette classe de vulnérabilité, nous recommandons une approche en couches :

• Gestion des correctifs : nous conseillons et automatisons les mises à jour lorsque cela est possible. Priorisez toujours le correctif du fournisseur (3.5.6 pour Gutentor).
• WAF géré : notre WAF peut déployer des correctifs virtuels qui bloquent les tentatives d'exploitation visant le bloc HTML de Gutentor, y compris les charges utiles encodées et obfusquées.
• Analyse et détection de logiciels malveillants : des analyses régulières aident à découvrir des scripts stockés ou des fichiers injectés avant que les attaquants ne puissent agir sur eux.
• Conseils en réponse aux incidents : listes de contrôle étape par étape et, à des niveaux de service plus élevés, assistance pratique pour supprimer les portes dérobées et sécuriser les comptes.
• Application du principe du moindre privilège et surveillance des rôles : conseils et surveillance des rôles des utilisateurs et de leurs activités pour réduire l'exposition au risque.

Nous proposons des plans gratuits et payants — le plan gratuit comprend des protections essentielles qui sont très pertinentes pour cette situation (pare-feu géré, WAF, scanner de logiciels malveillants, atténuation des risques OWASP Top 10). Si vous avez besoin d'une remédiation plus rapide ou d'un patching virtuel mensuel des vulnérabilités, nos plans payants offrent une atténuation automatisée et un support plus réactif.

Sécurisez votre site en quelques minutes — Plan gratuit WP-Firewall

Si vous recherchez une protection immédiate prouvée pendant que vous mettez à jour des plugins et auditez du contenu, le plan de base (gratuit) de WP-Firewall offre une couverture essentielle : un pare-feu géré, un WAF d'application, une protection contre la bande passante illimitée, un scanner de logiciels malveillants et une atténuation des risques OWASP Top 10 — le tout sans frais. Inscrivez-vous et activez la protection immédiatement à l'adresse : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si vous avez besoin d'une suppression automatisée des logiciels malveillants et de contrôles supplémentaires comme des listes noires/blanches d'IP, envisagez nos plans Standard ou Pro. Pour les équipes gérant plusieurs sites ou ayant besoin de patching virtuel et de support dédié, notre niveau Pro comprend des rapports mensuels et un patching virtuel automatique.)

Annexe : commandes rapides, requêtes et listes de contrôle

Attention : Ne prévisualisez jamais de publications suspectes dans l'administration sans d'abord les assainir.

Exemples de recherche de base de données sécurisée (WP-CLI) :

• Trouver des publications contenant “<script” :

  Requête wp db "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' ;"

• Trouver des publications contenant “onerror” ou d'autres attributs d'événements :

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%onerror=%' OR post_content LIKE '%onclick=%' OR post_content LIKE '%onmouseover=%';"

• Trouvez des références aux blocs Gutentor avec un contenu suspect :

  wp db query "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%gutentor%' AND (post_content LIKE '%<script%' OR post_content LIKE '%on%=%');"

Vérifications du tableau de bord WordPress :

• Utilisateurs → Tous les utilisateurs : recherchez les comptes de contributeur récemment créés, en particulier ceux avec des e-mails génériques.
• Articles → Tous les articles : filtrez par auteur pour vérifier les brouillons récents.
• Extensions → Extensions installées : confirmez la version du plugin Gutentor.

Liste de contrôle pour une remédiation sûre :

• Mettez à jour Gutentor vers 3.5.6+ sur la mise en scène, testez, puis déployez en production.
• Recherchez et supprimez les blocs suspects (ne les ouvrez pas dans l'aperçu admin).
• Faire tourner les mots de passe administrateurs et révoquer les sessions.
• Scannez le système de fichiers pour les fichiers PHP récemment modifiés/ajoutés.
• Re-scannez le site après remédiation.

Réflexions finales

Le XSS stocké dans les blocs de constructeur de contenu est un schéma récurrent dans l'écosystème WordPress car ces blocs offrent des fonctionnalités HTML flexibles tout en essayant d'équilibrer l'utilisabilité et la sécurité. Le CVE-2026-2951 de Gutentor est un rappel de la nature stratifiée du risque WordPress : un compte à faible privilège peut créer un contenu persistant, et une action d'admin non suspecte peut se transformer en une compromission sérieuse.

Si vous gérez des sites WordPress, votre action la plus prioritaire est de mettre à jour le plugin vulnérable vers la version corrigée (3.5.6). Si vous ne pouvez pas mettre à jour immédiatement, appliquez des mesures de confinement : restreignez les capacités des contributeurs, scannez le contenu suspect à l'aide de requêtes sûres et déployez une couche WAF (patching virtuel) pour bloquer les schémas d'exploitation courants.

WP-Firewall est conçu pour vous aider à combler le fossé entre la découverte et le patching avec des règles WAF gérées, des scans de malware et des conseils opérationnels plus clairs. Même le plan gratuit inclut des protections essentielles qui réduisent rapidement la fenêtre de risque pendant que vous mettez à jour et durcissez votre site.

Restez vigilant, appliquez le principe du moindre privilège et considérez le contenu pouvant contenir du HTML brut comme une entrée non fiable, sauf s'il provient de sources vérifiées.

Si vous souhaitez une liste de contrôle de remédiation succincte à remettre à un propriétaire de site ou à un hébergeur, téléchargez notre liste de contrôle imprimable d'une page depuis le tableau de bord WP-Firewall après vous être inscrit au plan gratuit.