| Nom du plugin | Formulaire Popup LotekMedia |
|---|---|
| Type de vulnérabilité | Scripts intersites (XSS) |
| Numéro CVE | CVE-2026-2420 |
| Urgence | Faible |
| Date de publication du CVE | 2026-03-11 |
| URL source | CVE-2026-2420 |
Avis de sécurité urgent — XSS stocké dans le plugin Formulaire Popup LotekMedia (≤ 1.0.6) et que faire ensuite
Date: 7 mars 2026
CVE : CVE-2026-2420
Gravité: Faible (Patchstack / score de recherche : CVSS 5.9)
Logiciels concernés : Formulaire Popup LotekMedia (plugin WordPress) — versions ≤ 1.0.6
Privilège requis pour déclencher : Administrateur (authentifié)
Résumé
Une vulnérabilité de Cross Site Scripting (XSS) stockée a été découverte dans le plugin Formulaire Popup LotekMedia pour WordPress (versions jusqu'à 1.0.6). Un utilisateur privilégié avec accès administrateur peut stocker du contenu de script malveillant via les paramètres du plugin. Ce payload peut ensuite être rendu dans des pages ou des écrans d'administration et exécuté dans le navigateur des visiteurs ou d'autres utilisateurs, permettant à un attaquant d'exécuter du JavaScript arbitraire dans le contexte du site.
Cet article est rédigé du point de vue de WP-Firewall — un fournisseur de sécurité WordPress et WAF géré — et vise à donner des conseils pratiques, techniques et non techniques aux propriétaires de sites, administrateurs et développeurs sur l'évaluation des risques, la détection, l'atténuation et le renforcement à long terme. Si vous gérez un site utilisant ce plugin, lisez ce guide complet et agissez rapidement.
Qu'est-ce que le XSS stocké et pourquoi cela importe-t-il pour les sites WordPress
Le XSS stocké (persistant) se produit lorsque du JavaScript malveillant est enregistré sur le serveur (par exemple, dans les paramètres du plugin, les commentaires ou un champ de base de données) et inclus ultérieurement dans une page web sans échappement correct de la sortie. Lorsque la victime charge cette page, le script malveillant s'exécute dans le navigateur de la victime, avec les privilèges du site. Les conséquences dépendent du contexte et de l'intention :
- vol de jeton de session ou de cookie (si les cookies ne sont pas marqués HttpOnly),
- prise de contrôle de compte (si le script effectue des actions authentifiées),
- redirection vers des sites contrôlés par l'attaquant ou des pages de phishing,
- injection de contenu et défiguration,
- persistance en installant des portes dérobées ou en déposant des webshells via des requêtes administratives falsifiées,
- ou utilisation dans le cadre d'une attaque plus large pour pivoter à l'intérieur d'une organisation.
Parce que cette découverte spécifique nécessite des privilèges d'administrateur pour injecter le payload, les voies d'exploitation ressemblent généralement à :
- un attaquant contrôle déjà un compte administrateur (via vol de credentials, phishing, mot de passe réutilisé, ingénierie sociale), ou
- un attaquant trompe un administrateur pour qu'il effectue une action (par exemple, cliquer sur un lien conçu uniquement pour les administrateurs ou accepter un payload malveillant dans un formulaire), ou
- un processus tiers compromis (CI/CD, installateur de plugin) avec des capacités administratives injecte du contenu.
Même si les utilisateurs non administrateurs ne peuvent pas créer le payload stocké, la présence de cette vulnérabilité est toujours grave : les comptes administrateurs sont des cibles de grande valeur, et le XSS stocké peut transformer un administrateur compromis en un compromis complet du site avec un impact large.
Empreinte technique du problème (niveau élevé)
D'après l'avis disponible :
- Le plugin enregistre des données provenant des paramètres du plugin qui peuvent contenir du HTML/JavaScript non assaini.
- Ces données sont ensuite affichées sur des pages (ou des écrans d'administration) sans échappement ni assainissement appropriés.
- La vulnérabilité est un modèle classique de “ sauvegarde sans assainissement — rendu sans échappement ”, appliqué aux champs de paramètres/options.
Les modèles de code courants qui mènent à cela incluent :
- l'affichage direct des options du plugin dans les modèles (par exemple,
echo $options['popup_html'];) sansechapper_html/esc_attr/esc_urlouwp_kses. - stocker les entrées utilisateur non filtrées des formulaires d'administration (même si soumises par un administrateur) sans
assainir_*appels. - supposer que les données fournies par l'administrateur sont sûres et donc ne pas échapper avant l'affichage.
Note: Je ne publierai pas de charges utiles d'exploitation ou de chaînes d'exploitation étape par étape — ce serait irresponsable. Ce guide se concentre sur la détection, la containment et la remédiation sûres.
Scénarios d'exploitation — qui est à risque et comment un attaquant pourrait utiliser cela
- Flux de travail administrateur compromis
- Si un attaquant obtient des identifiants d'administrateur (phishing, remplissage de credentials), il peut ajouter un extrait malveillant dans les paramètres du plugin. Cet extrait sera ensuite rendu aux visiteurs ou à d'autres utilisateurs administrateurs.
- Ingénierie sociale administrateur
- Un attaquant crée un lien ou un e-mail qui incite un administrateur à cliquer et à soumettre une charge utile malveillante dans un formulaire de paramètres (par exemple, une requête POST falsifiée). Comme le plugin ne nettoie pas les champs, la charge utile est stockée.
- Intégrations tierces malveillantes
- Si le site s'intègre à une automatisation tierce ayant un accès de niveau administrateur (scripts de déploiement, éditeurs externes), le tiers pourrait involontairement (ou malicieusement) insérer des charges utiles.
Impact potentiel après un XSS stocké réussi :
- Voler des cookies de session ou effectuer des actions dans le contexte administrateur (créer de nouveaux utilisateurs, changer des paramètres).
- Livrer d'autres malwares aux visiteurs du site.
- Persister une porte dérobée avec une requête assistée par CSRF effectuée par le script injecté.
- Injecter une interface de suivi / phishing malveillante pour récolter des identifiants auprès des visiteurs du site.
Comme le XSS stocké s'exécute dans un navigateur, l'impact total dépend de ce que la session du navigateur peut faire — si la victime est un administrateur ou un utilisateur privilégié, le risque est accru.
Actions immédiates pour les propriétaires / administrateurs de site (premières 24 heures)
Si votre site utilise LotekMedia Popup Form et que la version est ≤ 1.0.6, suivez ces étapes immédiatement :
- Identifier les sites touchés
- Vérifiez dans l'administration WordPress > Plugins et notez si LotekMedia Popup Form (ltm-popup-form) est installé et si la version est ≤ 1.0.6.
- Désactivez temporairement ou désactivez le plugin.
- Si un correctif ou une version sécurisée n'est pas encore disponible, désactivez le plugin jusqu'à ce qu'un correctif du fournisseur soit publié. La désactivation empêche la sauvegarde de nouvelles entrées et peut arrêter le rendu du HTML généré par le plugin dans certains cas.
- Limiter l'accès Administrateur
- Réduire temporairement le nombre de comptes avec des capacités administratives.
- Imposer des mots de passe forts pour tous les comptes administrateurs (utiliser des phrases de passe uniques ou un gestionnaire de mots de passe).
- Activer l'authentification à deux facteurs (2FA) pour les utilisateurs administrateurs.
- Si possible, restreindre l'accès administrateur par IP (liste blanche) ou limiter l'accès à un VPN.
- Auditer les compromissions
- Vérifier les nouveaux comptes administrateurs ou suspects.
- Examiner les changements récents des paramètres des plugins et voir si des champs contiennent des balises script ou du HTML inattendu.
- Rechercher dans wp_options, post meta et d'autres tables de la base de données pour “<script”, “onerror=”, “javascript:” ou d'autres sous-chaînes suspectes. (Utiliser des requêtes de base de données sûres et faire une sauvegarde d'abord.)
- Vérifier les journaux du serveur pour des requêtes POST inhabituelles vers les points de terminaison administratifs des plugins.
- Faites tourner les identifiants et les clés
- Si vous soupçonnez une compromission, changez les mots de passe administrateurs, faites tourner les clés et tokens API, et mettez à jour les identifiants FTP/SSH.
- Sauvegarde
- Effectuez une sauvegarde complète (fichiers et base de données) avant d'apporter des modifications majeures afin de pouvoir analyser un état connu comme bon.
- Scannez le site
- Exécutez une analyse de malware et un contrôle d'intégrité pour détecter les webshells, les fichiers principaux modifiés ou d'autres changements.
- Surveillez les comportements suspects côté client.
- Utilisez un navigateur pour afficher les pages publiques (dans un environnement sûr) et vérifiez si des pop-ups, des redirections ou du contenu injecté inattendus apparaissent.
Si vous ne pouvez pas effectuer les étapes vous-même ou si vous préférez une approche gérée, contactez immédiatement un fournisseur de sécurité de confiance.
Remédiation à moyen terme (jours à semaines).
- Appliquez le correctif du fournisseur
- Lorsque le développeur du plugin publie une version corrigée, mettez à jour immédiatement. Si le plugin reste non corrigé pendant une période déraisonnable, envisagez de le supprimer ou de le remplacer par une alternative maintenue.
- Nettoyez le contenu injecté.
- Supprimez tout contenu malveillant enregistré dans les paramètres du plugin ou d'autres emplacements persistants. Nettoyez soigneusement ou supprimez le HTML des champs de paramètres qui ne sont pas intentionnellement de confiance.
- Si vous n'êtes pas sûr des champs affectés, restaurez les paramètres à partir d'une sauvegarde propre (avant l'infection) après avoir pleinement confirmé que la sauvegarde est propre.
- Examinez et réparez.
- Recherchez des signes supplémentaires de compromission (nouveaux fichiers, tâches planifiées, thèmes/plugins modifiés).
- Vérifiez l'intégrité des fichiers de base de WordPress, des thèmes et des plugins par rapport à des copies fraîches provenant de WordPress.org ou de packages de fournisseurs.
- durcissement
- Assurez-vous que tous les autres plugins et thèmes sont à jour.
- Appliquez le principe du moindre privilège : accordez des droits d'administrateur uniquement aux comptes qui en ont réellement besoin.
- Utilisez des journaux centralisés et des alertes pour détecter des actions administratives suspectes.
- Ajoutez des en-têtes de politique de sécurité du contenu (CSP) pour atténuer l'impact des scripts injectés (exemple : interdire les scripts en ligne ou n'autoriser que les scripts de vos domaines de confiance). Notez que le CSP nécessite des tests minutieux car il peut casser des fonctionnalités légitimes.
Prévention à long terme et conseils de développement.
Pour les auteurs de plugins et les équipes de développement, prévenir cette classe de vulnérabilité nécessite une combinaison de gestion sécurisée des entrées, d'échappement des sorties et de vérifications de capacité appropriées :
- Assainissez à l'entrée, échappez à la sortie
- Lors de l'enregistrement : utilisez.
assainir_champ_texte(),sanitize_textarea_field(),assainir_email(),intval(), ou des fonctions de désinfection personnalisées en fonction du type d'entrée attendu. - Si le plugin doit stocker un HTML limité, utilisez
wp_kses()avec une liste autorisée stricte plutôt que de stocker du HTML arbitraire. - À la sortie : échappez toujours avec
esc_html(),esc_attr(),zone_texte_esc(),esc_url()ouwp_kses_post()selon le contexte.
- Lors de l'enregistrement : utilisez.
- Utilisez l'API des paramètres WordPress
- L'API des paramètres inclut des structures intégrées pour la validation et la désinfection. Profitez-en pour standardiser le traitement des options.
- Utilisez des vérifications de capacité et des nonces
- Vérifiez toujours
current_user_can('manage_options')(ou capacité appropriée) etwp_verify_nonce()sur les soumissions de formulaires administratifs pour s'assurer que seules les demandes autorisées et prévues sont traitées.
- Vérifiez toujours
- Évitez de supposer que l'entrée de l'administrateur est sûre
- Les administrateurs peuvent être trompés ; ne considérez jamais les données fournies par l'administrateur comme implicitement fiables.
- Encodez correctement les données pour le contexte de sortie
- Faites la distinction entre le contexte des attributs, le contexte HTML, le contexte JavaScript lors de l'échappement. Utilisez la bonne fonction d'échappement pour chacun.
- Journalisation et suivi des modifications
- Conservez une trace des modifications de configuration et de qui les a effectuées. Cela aide à détecter les activités suspectes et soutient la réponse aux incidents.
Détection : quoi rechercher (indicateurs de compromission – IOC)
Si vous soupçonnez une exploitation, recherchez les signes suivants :
- Présence de balises script, de gestionnaires d'événements en ligne (onerror=, onload=), ou d'URI javascript : dans les options du plugin (table wp_options) ou les métadonnées des publications.
- Redirections ou pop-ups inattendus sur des pages publiques.
- Nouveaux utilisateurs administrateurs ajoutés autour du moment des changements suspects.
- Tâches planifiées suspectes (entrées wp_cron) qui exécutent un code inconnu.
- Fichiers de cœur ou de thème modifiés, en particulier les fichiers contenant des appels eval(), base64_decode() ou include() vers des fichiers inconnus.
- Pics de trafic anormaux ou chaînes d'agent utilisateur inhabituelles dans les journaux.
- Anomalies de connexion (tentatives échouées suivies d'une connexion admin réussie depuis des IP inhabituelles).
Si un IOC est trouvé, exécutez immédiatement les étapes de confinement : désactiver le plugin, faire tourner les identifiants, restaurer à partir de sauvegardes propres si nécessaire, et effectuer une analyse judiciaire approfondie.
Patching virtuel avec un WAF : comment WP-Firewall peut aider
Lorsque des correctifs immédiats du fournisseur ne sont pas encore disponibles, le patching virtuel (règles WAF) offre le moyen le plus rapide de réduire le risque d'exploitation en bloquant les charges utiles malveillantes au niveau HTTP avant qu'elles n'atteignent le chemin de code vulnérable.
Techniques clés de patching virtuel que nous appliquons ou recommandons :
- Bloquer les requêtes POST/PUT vers les points de terminaison admin de plugins connus, sauf si elles proviennent d'IP de confiance ou avec un contexte de session admin valide. Par exemple, limiter les requêtes à /wp-admin/options.php ou aux points de terminaison admin de plugins personnalisés uniquement aux sessions admin authentifiées.
- Filtrer les modèles d'entrée suspects avant que le serveur ne les traite. Les règles peuvent détecter et bloquer les charges utiles contenant :
- , onerror=, onload=, javascript :
- Formes codées de ces jetons (par exemple, script)
- Bloquer les requêtes qui incluent du JavaScript en ligne dans des champs de formulaire destinés au texte brut.
- Appliquer un en-tête de politique de sécurité de contenu (CSP) strict via WAF pour interdire les scripts en ligne et n'autoriser que le JS provenant d'hôtes de confiance — cela réduit l'impact de tout script en ligne injecté.
- Limiter le taux et les flux CAPTCHA/2FA pour les pages admin afin de réduire la probabilité d'attaques automatisées.
- Ajouter des signatures virtuelles qui recherchent des paramètres vulnérables connus du plugin lorsqu'ils sont vus en combinaison avec une entrée suspecte.
Les clients de WP-Firewall (y compris ceux du plan gratuit) bénéficient de protections WAF gérées qui peuvent rapidement bloquer des modèles malveillants connus pendant qu'un correctif officiel est publié et testé. Nos règles gérées sont ajustées pour minimiser les faux positifs tout en maximisant la protection contre les véritables modèles d'attaque.
Note: Les patches virtuels ne remplacent pas un correctif approprié du plugin. Ce sont une mesure temporaire de réduction des risques lorsque le correctif n'est pas encore déployé.
Manuel de réponse aux incidents sécurisé
Si vous trouvez des preuves d'exploitation, suivez cette liste de contrôle :
- Contenir
- Désactivez le plugin vulnérable.
- Bloquer l'accès admin depuis des IP non fiables.
- Appliquez des règles WAF pour bloquer les entrées suspectes.
- Préserver les preuves
- Copier les journaux, les instantanés de base de données et les instantanés du système de fichiers pour un examen judiciaire.
- Assurez-vous que les sauvegardes sont isolées pour éviter la réinfection.
- Éradiquer
- Supprimez les charges utiles malveillantes des paramètres du plugin et d'autres emplacements persistants.
- Remplacez tous les fichiers de base/thème/plugin modifiés par des copies propres provenant de sources officielles.
- Supprimez tous les utilisateurs inconnus, les tâches planifiées ou les fichiers indésirables.
- Récupérer
- Restaurez à partir d'une sauvegarde connue et bonne si le site est trop compromis pour être nettoyé.
- Faites tourner les identifiants pour tous les comptes administrateurs et les clés API.
- Réactivez les services après avoir confirmé que l'environnement est propre.
- Actions post-incident
- Réalisez un post-mortem : comment le compte admin a-t-il été compromis (phishing, mot de passe faible, tiers) ?
- Renforcez les processus pour prévenir la récurrence : appliquez l'authentification à deux facteurs, réduisez le nombre d'administrateurs, mettez en œuvre des politiques de mots de passe forts.
- Surveillez de près toute récurrence pendant une période (par exemple, 30 à 90 jours) après le nettoyage.
Si vous n'êtes pas sûr de la façon de procéder, engagez un professionnel de la sécurité qui peut effectuer une analyse forensique complète et une remédiation.
Vérifications pratiques de la base de données et des fichiers (étapes sûres)
- Recherchez des artefacts de script dans la table des options :
- Exemple de vérification sûre (exécutez sur une copie en lecture seule de la base de données) :
SELECT option_name, option_value FROM wp_options WHERE option_value LIKE '%<script%'; - Remplacez wp_options par votre préfixe de table.
- Exemple de vérification sûre (exécutez sur une copie en lecture seule de la base de données) :
- Inspectez les paramètres du plugin via la page d'administration du plugin — examinez chaque champ pour détecter un HTML inattendu ou des scripts en ligne.
- Vérifiez les répertoires de téléchargements et de plugins pour des fichiers récemment modifiés. Si des fichiers sont inconnus ou suspects, inspectez-les avec soin sur une machine isolée.
Prenez toujours une sauvegarde avant d'apporter des modifications et préférez travailler sur une copie ou un environnement de staging lorsque cela est possible.
Liste de contrôle pour les développeurs pour corriger ce bug (pour les mainteneurs de plugins)
- Identifiez chaque endroit qui enregistre des données fournies par l'administrateur et appliquez une désinfection appropriée lors de l'enregistrement.
- Identifiez chaque endroit qui sort des données stockées et assurez-vous d'une échappement approprié pour le contexte (HTML, attribut, URL, JS).
- Évitez de stocker du HTML fourni par l'utilisateur brut — si le HTML est requis, utilisez
wp_kses()avec une liste d'autorisation sécurisée (très restrictive). - Ajoutez des tests unitaires et d'intégration qui affirment que les charges utiles malveillantes sont supprimées ou échappées.
- Passez en revue les points de terminaison administratifs pour les vérifications de capacité (
l'utilisateur actuel peut), les nonces et les privilèges appropriés. - Envisagez d'ajouter une journalisation des modifications des paramètres critiques afin que les propriétaires de sites puissent suivre qui a changé quoi et quand.
Communiquez la correction de manière transparente avec des notes de version qui incluent le CVE et les instructions de mise à niveau correctes.
Politique de sécurité du contenu (CSP) — une couche d'atténuation efficace
Une CSP correctement mise en œuvre peut réduire considérablement l'impact des XSS en interdisant les scripts en ligne et en ne permettant que les scripts provenant de sources autorisées. Exemples de directives (doivent être testées en profondeur avant la production) :
default-src 'self';script-src 'self' https://trusted.cdn.example.com;// éviter ‘unsafe-inline’object-src 'none';frame-ancestors 'self';base-uri 'self';
La CSP est un puissant contrôle de défense en profondeur, mais elle ne peut pas remplacer une désinfection et un échappement appropriés côté serveur.
Pourquoi vous ne devriez pas attendre le correctif : réduisez la surface d'attaque maintenant
Bien que cette vulnérabilité nécessite qu'un administrateur stocke la charge utile, les comptes administratifs peuvent être compromis. Les attaquants utilisent souvent de petits plugins négligés comme vecteur pour escalader. Réduire la surface d'attaque et limiter l'exposition des administrateurs maintenant empêche un possible compromis en chaîne :
- Supprimez les plugins et thèmes inutilisés.
- Utilisez l'authentification à deux facteurs et l'authentification basée sur l'appareil pour les administrateurs.
- Limitez les comptes administrateurs et utilisez la séparation des rôles (éditeur, auteur) pour les tâches de contenu routinières.
- Surveillez les journaux et activez les alertes pour les comportements administratifs suspects.
Commencez à protéger votre site maintenant — Plan gratuit WP-Firewall
Protégez votre site immédiatement — Commencez WP-Firewall Gratuit
Si vous souhaitez une protection gérée immédiate pendant que vous gérez le plugin et obtenez le correctif du fournisseur, envisagez de vous inscrire au plan gratuit WP-Firewall. Le niveau gratuit fournit des protections essentielles de pare-feu géré et une couverture des règles WAF pour aider à bloquer les modèles d'injection connus et inconnus pendant que vous remédiez.
Inscrivez-vous ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Ce que le plan gratuit fournit
- Basique (gratuit) — Protection essentielle
- Pare-feu géré avec mises à jour continues des règles
- Bande passante illimitée pour le trafic protégé
- Pare-feu d'application Web (WAF) pour bloquer les modèles d'injection courants
- Scanner de logiciels malveillants pour détecter des fichiers et des charges utiles suspects.
- Atténuation des 10 principaux risques de l'OWASP
Options de mise à niveau (si vous souhaitez plus d'automatisation et de support)
- Standard ($50/an) — Ajoute la suppression automatique des logiciels malveillants et des contrôles de liste noire/blanche d'IP (jusqu'à 20 IP).
- Pro ($299/an) — Ajoute des rapports de sécurité mensuels, un correctif virtuel automatique des vulnérabilités et des modules complémentaires premium comme un support dédié et des services gérés.
Si vous traitez une vulnérabilité de plugin comme le problème du formulaire Popup de LotekMedia, le plan gratuit vous donne un WAF géré et une base de scan pendant que vous corrigez la cause profonde — et les mises à niveau ajoutent de l'automatisation qui fait gagner du temps lors des incidents.
Foire aux questions (FAQ)
Q : Si la vulnérabilité nécessite des privilèges administratifs, pourquoi est-ce urgent ?
R : Les comptes administratifs sont des cibles de grande valeur. Un attaquant qui hameçonne ou compromet autrement un administrateur peut insérer un payload qui affecte de nombreux visiteurs ou d'autres utilisateurs administrateurs. Cela transforme un compromis de compte unique en un problème à l'échelle du site.
Q : Puis-je simplement “ assainir à la sortie ” et en rester là ?
R : L'assainissement des entrées et l'échappement des sorties sont nécessaires. Assainissez à l'enregistrement pour éviter de polluer le stockage avec du contenu malveillant ; échappez à la sortie pour garantir qu'aucun contenu dangereux n'atteigne le navigateur même si le stockage contient des données inattendues.
Q : Le correctif virtuel / WAF est-il suffisant ?
R : Le correctif virtuel est une atténuation immédiate mais pas une solution permanente. Il achète du temps et réduit la surface d'attaque pendant que vous appliquez un correctif approprié au niveau du code et suivez un processus complet de remédiation.
Q : Comment savoir si le plugin est corrigé ?
R : Un correctif sûr devrait inclure :
- Assainissement approprié lors de l'enregistrement,
- Échappement approprié lors du rendu,
- Tests démontrant la fermeture de vulnérabilité,
- Notes de version faisant référence au CVE et décrivant la correction.
Notes de clôture : vigilance et voie à suivre
Les écosystèmes WordPress incluent inévitablement de nombreux plugins tiers, et des problèmes de sécurité occasionnels sont inévitables. La réponse saine est une identification rapide, une containment soigneuse et une remédiation systématique. Ce XSS stocké de LotekMedia Popup Form est réparable — mais cela nécessite une action de la part des propriétaires de sites et des mainteneurs de plugins. Si vous hébergez des sites avec plusieurs administrateurs, ou si votre organisation dépend de contributeurs externes, profitez de ce moment pour renforcer les contrôles administratifs et durcir l'environnement.
Si vous souhaitez une protection gérée immédiate pendant que vous suivez les étapes de remédiation ci-dessus, le plan gratuit de WP-Firewall fournit une base de protection WAF gérée et de scan qui peut réduire considérablement la fenêtre de risque. Vous pouvez vous inscrire en toute sécurité ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Si vous avez besoin d'aide pour le triage, l'analyse judiciaire ou la remédiation complète, WP-Firewall propose des services gérés et un support d'incidents pour une gamme de besoins — des correctifs virtuels rapides à la récupération complète du site et à la sécurité gérée continue.
Restez en sécurité, gardez vos plugins à jour et traitez l'accès administrateur comme la ressource critique qu'il est.
— L'équipe de sécurité de WP-Firewall
