Thème MyMedi (< 1.7.7) XSS réfléchi (CVE-2026-25351) : Ce que les propriétaires de sites WordPress doivent savoir et comment se protéger

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-03-21
Mots clés: WordPress, Thème, XSS, Vulnérabilité, WAF, Sécurité

Résumé : Une vulnérabilité de Cross‑Site Scripting (XSS) réfléchi affectant le thème WordPress MyMedi (corrigée dans 1.7.7, CVE‑2026‑25351) peut permettre à un attaquant d'injecter et d'exécuter des scripts malveillants dans les navigateurs des visiteurs via des liens conçus. Cet article explique le risque, l'impact dans le monde réel, les options de détection et de mitigation, ainsi que les actions étape par étape que les propriétaires de sites et les développeurs devraient entreprendre — y compris comment WP‑Firewall peut immédiatement protéger votre site pendant que vous appliquez le correctif officiel.

TL;DR

• Vulnérabilité : Cross‑Site Scripting (XSS) réfléchi dans les versions du thème MyMedi antérieures à 1.7.7 (CVE‑2026‑25351).
• Gravité : Moyenne (CVSS 7.1).
• Affecte : Thème MyMedi < 1.7.7 (Les développeurs de thèmes ont corrigé cela dans 1.7.7).
• Vecteur d'attaque : Création d'une URL qui, lorsqu'elle est visitée ou cliquée par un utilisateur, provoque l'exécution d'un script dans son navigateur (interaction de l'utilisateur requise).
• Actions immédiates : Mettez à jour le thème vers 1.7.7 ou une version ultérieure. Si vous ne pouvez pas mettre à jour immédiatement, appliquez un WAF/correctif virtuel, renforcez le site et surveillez les journaux pour des demandes suspectes.
• WP‑Firewall peut fournir une mitigation immédiate et gérée avec des règles pour bloquer les charges utiles XSS courantes et les entrées suspectes pendant que vous mettez à jour.

Que s'est-il passé ? Une explication en termes simples

Le 20 mars 2026, un problème XSS réfléchi affectant le thème WordPress MyMedi (versions antérieures à 1.7.7) a été divulgué publiquement et a reçu le CVE‑2026‑25351. Un XSS réfléchi se produit lorsque des données fournies dans une requête HTTP (par exemple, des paramètres de chaîne de requête ou un champ de formulaire) sont incluses dans une réponse de page sans une désinfection ou un encodage appropriés, et un attaquant peut créer une URL qui provoque l'exécution de JavaScript injecté dans le navigateur d'une victime.

Caractéristiques clés de ce problème MyMedi :

• La vulnérabilité est réfléchie, pas stockée — le contenu malveillant est retourné immédiatement dans la réponse de la page et n'est pas enregistré dans la base de données.
• Elle peut être déclenchée par un attaquant non authentifié, mais l'exploitation réussie nécessite une interaction de l'utilisateur (par exemple, la victime clique sur un lien conçu).
• La vulnérabilité permet l'exécution de JavaScript arbitraire dans le contexte du site, ce qui peut entraîner le vol de session, la prise de contrôle de compte, le phishing ou la diffusion de charges utiles malveillantes aux visiteurs.

Parce que le XSS réfléchi peut être utilisé dans des campagnes de phishing à grande échelle, il est considéré comme un risque sérieux pour les utilisateurs de thèmes, en particulier les sites avec des connexions administratives ou des boutiques.

Vue d'ensemble technique (non-exploitative)

Le XSS réfléchi suit généralement ce schéma :

1. L'application accepte des entrées de la requête (paramètre de requête, champ de formulaire, en-tête de référent, etc.).
2. Cette entrée est réfléchie dans la réponse HTML du serveur sans désinfection appropriée ni encodage de sortie.
3. L'attaquant crée une URL contenant le script malveillant intégré dans l'entrée.
4. Lorsque un utilisateur visite l'URL, le navigateur reçoit du HTML contenant le script injecté et l'exécute dans le contexte du site.

Pour les versions MyMedi < 1.7.7 :

• Le thème avait un endroit dans son pipeline de sortie qui renvoyait les données de la requête dans le HTML sans échapper/encoder pour le contexte dans lequel il était utilisé.
• Le mainteneur du produit a publié la version 1.7.7 qui corrige l'échappement/l'encodage incorrect.

Important: Dans le développement moderne de WordPress, l'approche correcte est :

• Valider et assainir l'entrée tôt en utilisant des fonctions comme sanitize_text_field(), wp_kses_post() pour le HTML autorisé lorsque cela est approprié, et esc_url_raw() pour les URLs.
• Échapper les données à la sortie en utilisant la bonne fonction d'échappement pour le contexte : esc_html(), esc_attr(), esc_js(), esc_url(), etc.

Pourquoi cela importe : risques et scénarios du monde réel

Le XSS réfléchi n'est pas seulement un problème théorique. Voici des impacts concrets et réalistes pour un site utilisant un thème MyMedi vulnérable :

• Vol de données d'identification : Si des administrateurs ou des éditeurs sont trompés en cliquant sur un lien malveillant tout en étant connectés, un script pourrait exfiltrer des cookies ou des jetons d'authentification (à moins que les cookies ne soient HttpOnly et que d'autres atténuations existent).
• Détournement de session : L'accès aux cookies de session peut permettre aux attaquants de se faire passer pour des utilisateurs.
• Phishing persistant : L'attaquant peut afficher de fausses pages administratives ou des formulaires de paiement pour récolter des identifiants ou des détails de paiement.
• Malware à la volée : Les scripts peuvent rediriger les utilisateurs vers des pages malveillantes externes, afficher des publicités ou charger du malware supplémentaire.
• Dommages à la réputation et au SEO : Les pages de malware ou de phishing peuvent entraîner un blacklistage par les moteurs de recherche et les fournisseurs de sécurité, nuisant au trafic et aux affaires.

Étant donné que l'exploitation nécessite seulement un lien conçu et une interaction de l'utilisateur, les campagnes de phishing à grande échelle peuvent rapidement atteindre de nombreux visiteurs du site.

Qui doit agir

Si votre site utilise le thème MyMedi et que la version du thème est antérieure à 1.7.7, vous êtes concerné. Priorisez :

• Les sites de commerce électronique avec des clients connectés.
• Les sites avec plusieurs rôles d'utilisateur (administrateurs, éditeurs).
• Sites publics à fort trafic où de nombreux utilisateurs pourraient cliquer sur un lien malveillant.
• Sites intégrés avec l'authentification unique (SSO) ou des systèmes de paiement tiers.

Si vous êtes un développeur ou une agence gérant des sites clients, priorisez les notifications et la remédiation des clients.

Liste de contrôle immédiate pour les propriétaires de sites (étape par étape)

Suivez cette liste de contrôle pratique et priorisée pour sécuriser rapidement votre site.

1. Confirmez votre version
   • Dans l'administration WordPress, allez dans Apparence → Thèmes → MyMedi et vérifiez la version.
   • Ou ouvrez l'en-tête style.css du thème pour confirmer la version.
2. Mettre à jour le thème
   • Mettez à jour MyMedi vers la version 1.7.7 ou ultérieure immédiatement. C'est la solution définitive pour la vulnérabilité.
   • Si vous avez modifié les fichiers du thème directement, appliquez la mise à jour de manière contrôlée : sauvegardez d'abord et réappliquez les personnalisations en utilisant un thème enfant.
3. Si vous ne pouvez pas mettre à jour immédiatement, appliquez des contrôles compensatoires (voir ci-dessous)
   • Activez une règle de pare-feu d'application Web (WAF) pour bloquer les charges utiles XSS réfléchies.
   • Ajoutez une politique de sécurité du contenu (CSP) pour réduire l'impact des scripts injectés (voir les conseils CSP ci-dessous).
   • Renforcez les indicateurs de cookie : assurez-vous que les cookies importants sont HttpOnly et Secure.
4. Recherchez les compromis
   • Scannez les fichiers du site pour des changements inattendus (fichiers PHP inconnus, fichiers de thème modifiés).
   • Vérifiez le contenu de la base de données pour du HTML/JS injecté (par exemple, dans les publications, options, contenu des widgets).
   • Examinez les journaux du serveur et d'accès pour des chaînes de requête suspectes ou des tentatives répétées.
5. Réinitialisez les identifiants si vous soupçonnez une compromission
   • Forcez les réinitialisations de mot de passe pour les administrateurs si vous trouvez des preuves d'activité malveillante.
   • Révoquez et faites tourner toutes les clés API, jetons ou secrets clients SSO utilisés par le site.
6. Tester après remédiation
   • Testez les flux critiques (connexion, paiement, formulaires) depuis un navigateur incognito et vérifiez qu'aucun script inattendu n'est présent.
   • Reconstruisez les caches et les actifs CDN si applicable.
7. Surveillez et signalez
   • Gardez un œil sur les journaux et les événements WAF pour des tentatives correspondant à la vulnérabilité.
   • En cas de compromission, suivez un plan d'intervention en cas d'incident et informez les utilisateurs concernés si une exposition des données est possible.

Contrôles compensatoires et stratégies WAF (ce que recommande WP‑Firewall)

Bien que la mise à jour vers 1.7.7 soit la solution correcte à long terme, un patch virtuel immédiat et des règles WAF peuvent réduire l'exposition pendant que vous planifiez et déployez des mises à jour.

Stratégies WAF efficaces pour les XSS réfléchis :

• Bloquez les caractères suspects dans les chaînes de requête et les en-têtes dans des contextes bien définis :
  • Les marqueurs XSS courants sont , script, onerror, onload, javascript:, data:, eval(, document.cookie, location=, innerHTML — mais évitez le blocage naïf qui pourrait casser des fonctionnalités légitimes (par exemple, si votre site utilise légitimement des URI de données).
• Utilisez des règles sensibles au contexte :
  • Si un paramètre est censé être numérique, bloquez les caractères non numériques.
  • Si un paramètre est un slug, autorisez uniquement [a‑z0‑9‑_].
• Normalisez et décodez les entrées avant d'appliquer des signatures :
  • De nombreuses techniques d'évasion reposent sur l'encodage URL ou les entités HTML. Les règles WAF doivent inspecter les valeurs décodées.
• Limitez le taux ou défiez les requêtes suspectes :
  • Pour les modèles de requêtes à haut risque, présentez un CAPTCHA ou bloquez si un seuil est dépassé.
• Bloquez les agents utilisateurs malveillants connus et les scrapers tentant de sonder les paramètres.

WP‑Firewall peut déployer des règles gérées qui :

• Détectent et bloquent les modèles XSS réfléchis sans révéler les détails de l'exploitation.
• Appliquez un patch virtuel à la périphérie (avant que les requêtes malveillantes n'atteignent WordPress).
• Enregistrez et alertez-vous sur les événements bloqués afin que vous puissiez examiner les tentatives d'exploitation.

Note: Le patching virtuel n'est pas un substitut à la mise à jour du thème — il achète du temps et réduit la surface d'attaque pendant que vous appliquez le patch.

Recommandations de durcissement pour les développeurs et les auteurs de thèmes

Si vous êtes un développeur maintenant des thèmes personnalisés (ou contribuant à MyMedi), appliquez les pratiques de codage sécurisé suivantes :

1. Nettoyez l'entrée à la source
   • Utilisez sanitize_text_field(), sanitize_email(), esc_url_raw() pour les données entrantes avant traitement.
   • Pour le HTML qui doit être accepté, utilisez wp_kses() ou wp_kses_post() avec une liste autorisée stricte.
2. Échappez la sortie pour le contexte correct
   • Texte du corps HTML : esc_html()
   • Valeurs d'attributs : esc_attr()
   • URLs : esc_url()
   • Contextes JavaScript : wp_json_encode() ou esc_js()
   • Lors de l'écho de données dans du JavaScript en ligne, utilisez toujours wp_localize_script() ou encodez les données du serveur en JSON et échappez-les en conséquence.
3. Préférez la validation côté serveur à la validation côté client
   • La validation côté client améliore l'expérience utilisateur mais peut être facilement contournée. Validez à nouveau sur le serveur.
4. Évitez d'écho les variables de requête brutes
   • Ne faites jamais confiance à $_GET, $_POST, $_REQUEST ou aux en-têtes directement ; nettoyez et échappez avant la sortie.
5. Utilisez des nonces pour les points de terminaison d'action
   • Pour les actions qui changent d'état, exigez toujours un nonce valide pour prévenir les CSRF menant à des attaques en chaîne.
6. Implémentez CSP pour une atténuation supplémentaire
   • Une politique de sécurité de contenu (CSP) stricte peut limiter les sources d'exécution des scripts. Exemple :
     Content‑Security‑Policy : default‑src 'self' ; script‑src 'self' https://trusted.cdn.example ; object‑src 'none' ; base‑uri 'self' ;
   • La CSP est une défense en profondeur et doit être testée soigneusement (elle peut casser des scripts tiers).
7. Tests de sécurité dans CI/CD
   • Incluez des analyses SAST/DAST dans votre intégration continue pour détecter les modèles de sortie non sécurisés.
   • Utilisez des tests automatisés qui vérifient l'échappement correct des variables dans les modèles.

Comment détecter une tentative d'exploitation (quoi rechercher dans les journaux)

Détecter une tentative d'exploitation XSS réfléchie nécessite de rechercher des modèles suspects dans les journaux du serveur web, les journaux d'application, les journaux WAF et les analyses. Les indicateurs incluent :

• Des requêtes contenant des mots-clés de script dans les chaînes de requête :
  • Exemples de motifs : script=, , script, javascript:, onerror=, onload=.
• Plusieurs requêtes vers la même page avec des paramètres de requête inhabituels provenant d'adresses IP inconnues.
• Des entrées où l'en-tête referer est vide ou provient d'origines inattendues en combinaison avec des chaînes de requête suspectes.
• Des pics inhabituels dans les réponses 4xx ou 5xx liés au même point de terminaison.
• Journaux WAF montrant des modèles bloqués étiquetés XSS ou entrée suspecte.

Configurez des règles pour alerter sur :

• Toute chaîne de requête contenant des chevrons ou des pseudo-protocoles JavaScript.
• Requêtes avec des valeurs de paramètres longues ou fortement encodées.
• Un volume élevé de chaînes de requête uniques ciblant le même point de terminaison dans une courte fenêtre de temps.

Réponse et récupération : si vous soupçonnez un compromis

1. Isoler
   • Mettez le site hors ligne (mode maintenance) si le compromis est sévère et que vous avez besoin de temps pour le nettoyage.
   • Remplacez les pages publiques par un message statique sûr pendant l'enquête.
2. Triage
   • Identifier les fichiers compromis et les horodatages. Comparer avec les sauvegardes et les originaux de thème/plugin.
   • Vérifier la présence de nouveaux utilisateurs administrateurs, de fichiers de thème modifiés, de fichiers PHP inconnus dans les répertoires de téléchargements ou de thèmes.
3. Nettoyer
   • Supprimer les fichiers injectés et restaurer à partir d'une sauvegarde connue et bonne si disponible.
   • Réinstaller le thème MyMedi à partir d'une source vérifiée (après mise à jour vers 1.7.7).
   • Changer tous les mots de passe administratifs et forcer une réinitialisation pour tous les utilisateurs si nécessaire.
4. Renforcer
   • Appliquer les mesures de sécurité énumérées précédemment (règles WAF, CSP, durcissement des cookies).
   • S'assurer que les permissions de fichiers sont strictes (par exemple, wp-config.php non modifiable par l'utilisateur du serveur web).
5. Reconstruire la confiance
   • Si des données ou des utilisateurs ont été affectés, préparer des notifications comme l'exige la loi et les meilleures pratiques.
   • Soumettre à nouveau le site propre aux moteurs de recherche et aux listes noires de sécurité s'il a été précédemment signalé.
6. Post-mortem et leçons apprises
   • Effectuer un examen pour améliorer la gestion des correctifs, la fréquence des sauvegardes et la surveillance.

Pourquoi le patching virtuel et les services de pare-feu gérés sont importants en ce moment

Même lorsque le fournisseur publie un correctif, de nombreux sites restent non corrigés pendant des jours, des semaines ou plus en raison de personnalisations incompatibles, d'un manque de tests ou de restrictions d'hébergement. Le patching virtuel (règles WAF qui bloquent le modèle d'attaque) offre une protection immédiate dans cette fenêtre.

Avantages du patching virtuel :

• Protection instantanée sans modifier le code du site.
• Règles granulaires adaptées au modèle de vulnérabilité.
• Surveillance et visibilité sur les tentatives d'exploitation.
• Temps de planifier et de tester la mise à jour officielle avec un risque minimal.

Le jeu de règles géré de WP-Firewall est conçu pour :

• Détecter les charges utiles XSS réfléchies à travers les contextes.
• Bloquer ou défier les demandes potentiellement malveillantes (défi CAPTCHA/JS).
• Réduisez les faux positifs en utilisant des règles spécifiques au contexte et aux paramètres.

Encore une fois, le patching virtuel est une solution temporaire ; la mise à jour du thème doit être appliquée dès que possible.

Exemple de liste de contrôle de durcissement de la sécurité (opérationnel)

• Confirmez la version du thème ; mettez à jour MyMedi vers 1.7.7 ou une version ultérieure.
• Appliquez les règles gérées par WP‑Firewall pour XSS lors du patching.
• Activez des indicateurs de cookie stricts : HttpOnly, Secure, SameSite.
• Configurez une politique de sécurité du contenu (CSP) et testez d'abord en mode Rapport‑Uniquement.
• Scannez les changements et les logiciels malveillants ; restaurez les fichiers compromis à partir de la sauvegarde.
• Faites tourner les identifiants administratifs et API s'il y a des preuves de compromission.
• Passez en revue les rôles des utilisateurs ; supprimez les comptes administratifs inutilisés.
• Activez la journalisation et les alertes pour les modèles de requêtes suspects.
• Conservez des sauvegardes et testez les procédures de restauration.

Notes pour les développeurs : modèles de templating sécurisés

Lors de l'affichage de données dynamiques dans les modèles de thème, suivez ces modèles :

• Pour la sortie de texte brut :
  echo esc_html( $variable );
• Pour les valeurs d'attribut :
  echo esc_attr( $variable );
• Pour les URL :
  echo esc_url( $url );
• Lors de la localisation des scripts :
  wp_localize_script( 'script-handle', 'wpData', array( 'nonce' => wp_create_nonce( 'action' ) ) );
  Préférez wp_json_encode() pour insérer du JSON dans des scripts en ligne plutôt que la concaténation.
• Lors de l'autorisation de HTML sécurisé :
  echo wp_kses_post( $html );
  Ou spécifiez un ensemble explicite de balises/attributs autorisés avec wp_kses().

Éviter :
echo $variable; // sans échappement
Imprimer des entrées non fiables directement dans JavaScript ou des gestionnaires d'événements en ligne.

Politique de sécurité du contenu (CSP) — un point de départ pratique

Une CSP peut réduire considérablement les conséquences des XSS en empêchant l'exécution de scripts en ligne et en limitant les sources. Utilisez l'approche par en-tête ; commencez avec une politique indulgente en mode Report‑Only et resserrez progressivement.

Exemple (commencez par Report‑Only) :

En-tête :
Content‑Security‑Policy‑Report‑Only: default‑src 'self'; script‑src 'self' https://trusted.cdn.example; object‑src 'none'; base‑uri 'self'; report‑uri https://csp.example/report

Lorsque vous êtes confiant, appliquez :
Content‑Security‑Policy: default‑src 'self'; script‑src 'self' https://trusted.cdn.example; object‑src 'none'; base‑uri 'self'; report‑uri https://csp.example/report

Remarques :

• La CSP peut casser des scripts tiers et certaines fonctionnalités de plugin ; testez soigneusement en staging.
• Les CSP basées sur des nonce sont plus flexibles pour les scripts en ligne mais nécessitent une génération et une insertion de nonce cohérentes.

Foire aux questions

Q : Mon site utilise déjà un CDN — cela me protège-t-il ?
UN: Les CDN peuvent fournir un cache et une atténuation DDoS ; certains CDN offrent des fonctionnalités WAF. Mais le problème principal est la sortie non sécurisée dans le thème. Un CDN seul ne corrige pas les XSS au niveau du thème à moins que le WAF ne bloque les requêtes malveillantes.

Q : Si la vulnérabilité nécessite une interaction utilisateur, est-ce moins grave ?
UN: Pas nécessairement. L'interaction utilisateur est souvent obtenue par le biais de campagnes de phishing ou d'ingénierie sociale qui peuvent atteindre de nombreux utilisateurs. Si des administrateurs ou des utilisateurs privilégiés cliquent sur un lien conçu, les conséquences peuvent être graves.

Q : Les plugins peuvent-ils causer des problèmes similaires ?
UN: Oui. Les XSS réfléchis et stockés peuvent exister dans des thèmes, des plugins ou du code personnalisé. Appliquez les mêmes principes de désinfection et d'échappement dans tout le code.

Q : Dois-je désactiver les commentaires ou le contenu soumis par les utilisateurs ?
UN: Pas nécessairement. Au lieu de cela, assainissez et échappez correctement le contenu et envisagez des paramètres de modération qui réduisent l'exposition.

Exemple de script de détection (sûr, non-exploitant)

Ci-dessous se trouve une recherche de motif en lecture seule que vous pouvez exécuter contre les journaux d'accès pour trouver des chaînes de requête suspectes — ceci est uniquement pour la détection et ne fournit pas de détails sur les exploits.

Commande (Linux) :
grep -E -i '(|<|javascript:|onerror|onload|document\.cookie|eval\()' /var/log/nginx/access.log | less

Interprétation :

• Cela recherche des marqueurs communs souvent présents dans les tentatives de XSS après décodage d'URL.
• Cela renverra des faux positifs ; examinez attentivement les correspondances avant de prendre des mesures.

À propos de l'approche de WP‑Firewall

Nous fournissons une protection en couches :

• Règles WAF gérées adaptées aux thèmes et plugins WordPress.
• Patching virtuel pour bloquer rapidement les motifs à haut risque.
• Analyse de logiciels malveillants et assistance à la remédiation pour les sites infectés.
• Alertes et rapports exploitables pour aider les propriétaires de sites à prioriser et appliquer des correctifs.

Notre philosophie est pratique : prévenir les attaques à la périphérie, vous aider à mettre en œuvre des pratiques sécurisées dans le code et garantir que vous disposez de contrôles opérationnels pour détecter et récupérer des incidents.

Protégez votre site aujourd'hui — Commencez avec WP‑Firewall Gratuit

Nous comprenons que de nombreux propriétaires de sites ont besoin d'une protection immédiate et fiable sans perturber les opérations. WP‑Firewall propose un plan gratuit de base qui fournit des défenses essentielles que vous pouvez activer en quelques minutes :

• Protection essentielle : pare-feu géré, bande passante illimitée, WAF, scanner de logiciels malveillants et atténuation des 10 principaux risques OWASP.
• Idéal pour les propriétaires de sites qui souhaitent des défenses proactives pendant qu'ils coordonnent les mises à jour et les tests.

Si vous préférez plus d'automatisation et des fonctionnalités de sécurité supplémentaires, nous proposons également des niveaux payants avec suppression automatique des logiciels malveillants, un meilleur contrôle sur les listes noires/blanches d'IP, des rapports mensuels détaillés, un patching virtuel automatique des vulnérabilités et des options premium telles que la gestion de compte dédiée et des services de sécurité gérés.

Inscrivez-vous ou consultez le plan gratuit et les options de mise à niveau ici :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Recommandations finales — que faire dès maintenant

1. Vérifiez la version de votre thème MyMedi ; si < 1.7.7, mettez à jour vers 1.7.7 immédiatement.
2. Si vous ne pouvez pas mettre à jour immédiatement, activez les règles gérées de WP‑Firewall pour XSS et activez la surveillance.
3. Analysez votre site à la recherche de signes de compromission ; si vous en trouvez, suivez les étapes de récupération ci-dessus.
4. Renforcez les modèles de thème et suivez les meilleures pratiques d'échappement/nettoyage.
5. Abonnez-vous à un service de surveillance des vulnérabilités et tenez un inventaire des thèmes/plugins et de leurs versions.

Rester sécurisé est une combinaison de correctifs rapides, de défenses périmétriques intelligentes et de bonnes pratiques de codage. Si vous avez besoin d'aide pour évaluer l'exposition, déployer un ensemble de règles WAF ou effectuer un nettoyage, notre équipe de sécurité WP‑Firewall peut vous aider à protéger votre site WordPress rapidement et en toute sécurité.

Si vous le souhaitez, nous pouvons :

• Fournissez une liste de contrôle courte et adaptée à votre environnement d'hébergement spécifique.
• Effectuez une analyse gratuite du site et fournissez un résumé immédiat des risques.
• Aidez à créer un processus de mise à jour par étapes pour les mises à jour de thème qui préserve les personnalisations.

Contactez notre équipe de sécurité via votre console WP‑Firewall ou inscrivez-vous au plan gratuit pour commencer :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/