Nom du plugin	Plugin promotionnel Linux
Type de vulnérabilité	XSS stocké
Numéro CVE	CVE-2025-7668
Urgence	Moyen
Date de publication du CVE	2025-08-15
URL source	CVE-2025-7668

Plugin promotionnel Linux (<=1.4) — CSRF leading to Stored XSS (CVE-2025-7668): What WordPress Site Owners Must Do Now

Publié : 15 août 2025
CVE : CVE-2025-7668
Gravité: Niveau moyen — CVSS 7.1
Versions concernées : <= 1,4
Version corrigée : N/A (au moment de la rédaction)

Résumé: Une vulnérabilité du plugin Linux Promotional (versions jusqu'à la 1.4 incluse) permet à des attaquants non authentifiés d'exploiter une faille de type CSRF (Cross-Site Request Forgery) et d'exécuter des scripts intersites (XSS) stockés. Cette vulnérabilité pouvant être exploitée sans authentification et laissant des traces persistantes dans la base de données du site, elle représente un risque pratique modéré à élevé pour l'intégrité du site et la sécurité des utilisateurs. Cet article explique le problème, présente des scénarios d'attaque réalistes, décrit comment détecter une compromission, propose des mesures d'atténuation à court terme (dont l'application de correctifs virtuels) et des recommandations de renforcement de la sécurité à long terme, adaptées aux administrateurs WordPress.

---

Aperçu rapide pour les propriétaires de sites web occupés

• Ce qui s'est passé: Un point de terminaison d'entrée dans le plugin accepte et stocke du contenu contrôlé par un attaquant sans protection CSRF appropriée ni échappement de sortie, permettant ainsi aux charges utiles XSS stockées de persister et de s'exécuter dans les navigateurs des visiteurs et/ou des administrateurs.
• Qui est concerné : Sites utilisant le plugin promotionnel Linux en version 1.4 ou antérieure.
• Risque immédiat : Les attaquants peuvent injecter du code JavaScript qui s'exécute dans les navigateurs des victimes. Cela peut entraîner un vol de session, une élévation de privilèges, l'installation de logiciels malveillants par téléchargement furtif, la redirection du trafic, des actions d'administrateur malveillantes ou la création de portes dérobées.
• Action immédiate recommandée : Si vous utilisez l'extension, désactivez-la et mettez le site en mode maintenance jusqu'à ce que vous puissiez l'analyser et le nettoyer complètement. Si vous ne pouvez pas désactiver l'extension immédiatement, activez un pare-feu applicatif web (WAF) ou un patch virtuel pour bloquer les failles de sécurité.
• À long terme : Surveillez les mises à jour des plugins proposées par le développeur ; dès leur disponibilité, testez-les et appliquez-les. Renforcez la sécurité de votre site : authentification à deux facteurs, principe du moindre privilège, sauvegardes régulières, cookies CSP et SameSite, et pare-feu applicatif web (WAF) géré.

---

Description technique — fonctionnement de la vulnérabilité

Cette vulnérabilité se présente sous la forme d'une chaîne de défaillance en deux étapes :

1. Vulnérabilité CSRF (Cross-Site Request Forgery) : Le plugin accepte les requêtes de modification d'état (par exemple, l'enregistrement de contenu promotionnel, d'options ou de données administratives) sans vérifier un jeton nonce spécifique à l'utilisateur ni un jeton CSRF robuste. En l'absence de protection CSRF adéquate, un attaquant peut contraindre le navigateur d'une victime à soumettre des requêtes exécutant des actions sur le site.
2. XSS stocké : Le plugin stocke du contenu fourni par l'attaquant dans la base de données, puis l'affiche sur les pages (interface publique, interface d'administration ou les deux) sans l'échapper ni le nettoyer correctement. Lorsque ce contenu est consulté, le code JavaScript malveillant s'exécute dans le contexte du site.

Le risque critique survient lorsque des attaquants non authentifiés peuvent déclencher l'action de stockage (comme indiqué). Cela signifie que la charge utile est conservée sans nécessiter d'identifiants de la victime et sera accessible aux visiteurs ou aux administrateurs, ce qui rend le problème plus grave qu'une simple attaque XSS par réflexion.

Points techniques clés :

• Privilège requis : Non authentifié — un attaquant n'a pas besoin d'être connecté.
• Persistance: Les failles XSS stockées restent dans la base de données et s'exécuteront pour tout utilisateur consultant la ou les pages concernées.
• Vecteurs d'attaque : Les campagnes malveillantes pourraient placer la charge utile à des endroits affichés sur des pages publiques ou des écrans d'administration ; si elles sont exécutées dans des navigateurs d'administration, les attaquants peuvent exploiter les failles XSS pour effectuer des actions authentifiées (créer des comptes d'administrateur, modifier du contenu, injecter des portes dérobées).
• Exploitabilité : Forte vulnérabilité en situation réelle car l'exploitation peut être automatisée : les attaquants peuvent placer des charges utiles qui s'exécutent à chaque chargement d'une page.

---

Scénarios d'attaque réalistes et leurs impacts

L'utilisation d'une faille XSS stockée combinée à une attaque CSRF ouvre la voie à plusieurs chaînes d'attaques. Voici des scénarios réalistes que les attaquants pourraient exploiter :

• Défiguration de sites et hameçonnage : Injecter du code JavaScript modifiant le contenu ou affichant des superpositions pour usurper les identifiants des visiteurs ou diffuser de fausses publicités nuit à la confiance et peut porter atteinte à l'image de marque.
• Redirections malveillantes et fraude publicitaire : Ajoutez des scripts qui redirigent le trafic vers des sites arbitraires ou injectez des scripts d'affiliation/publicitaires pour monétiser la faille.
• Détournement de session et prise de contrôle par l'administrateur : Si la charge utile est affichée sur les pages d'administration ou aux utilisateurs connectés, un attaquant peut exfiltrer des cookies, des jetons CSRF ou effectuer des actions via le navigateur de l'administrateur (créer de nouveaux utilisateurs administrateurs, modifier les thèmes/plugins).
• Distribution de logiciels malveillants : Injecter du code qui charge des mineurs de cryptomonnaie externes, des logiciels malveillants ou des kits de téléchargement furtif, ce qui affecte vos utilisateurs et peut entraîner le blacklistage de votre site.
• Portes dérobées persistantes : Utiliser XSS pour injecter ou déclencher des modifications côté serveur (en combinaison avec d'autres failles de plugin ou des fonctionnalités d'administration non sécurisées) afin de maintenir un accès à long terme.

Même avec un CVSS moyen, l'impact concret sur l'entreprise peut être grave : une seule charge utile XSS stockée sur un site à fort trafic peut causer des dommages considérables rapidement.

---

Comment détecter si votre site est affecté ou déjà compromis ?

La détection est essentielle et doit être systématique. Vous trouverez ci-dessous des étapes pratiques de détection et des exemples de requêtes. Effectuez toujours une sauvegarde avant toute modification.

1. Inventaire: Vérifiez si le plugin promotionnel Linux est installé et quelle est sa version.
• Dans l'administration WordPress : Extensions > Extensions installées.
• Sur le système de fichiers : wp-content/plugins/linux-promotional-plugin ou des noms de dossiers similaires.
2. Recherchez dans la base de données les balises de script suspectes ou les charges utiles encodées :
• Vérifier les emplacements de stockage courants :
  • wp_posts (contenu_post)
  • wp_postmeta
  • wp_options (valeur_option)
  • Tableaux spécifiques au plugin (le cas échéant)
• Exemples de requêtes SQL (à exécuter via phpMyAdmin, wp-cli ou votre client de base de données) :

-- Recherche des balises de script littérales : SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%'

3. Examinez les paramètres du plugin et les pages de contenu promotionnel : Recherchez les blocs HTML inattendus, les scripts intégrés ou les iframes étranges, aussi bien dans l'interface publique que dans l'interface d'administration.
4. Consultez les modifications récentes et les dates de modification des fichiers :
• Sur le serveur : vérifiez la date de modification des fichiers critiques et des fichiers inattendus dans les dossiers wp-content/uploads, wp-content/plugins et theme.
• Exemple de commande wp-cli :

# Trouver les fichiers PHP/JS récemment modifiés : find /chemin/vers/votre/site -type f \( -iname '*.php' -o -iname '*.js' \) -mtime -7 -ls

5. Journaux Web et journaux d'accès :
• Recherchez dans les journaux du serveur Web les requêtes POST adressées aux points de terminaison du plugin ou les requêtes contenant des paramètres suspects aux alentours de la période où le plugin était actif.
• Identifier les référents externes répétés qui précèdent la création de la charge utile, ou les requêtes avec des charges utiles importantes injectées.
6. Détection côté navigateur :
• Utilisez la fonction « Afficher la source » sur les pages concernées pour les scripts intégrés ou les portions de code obfusquées.
• Chargez la page dans une fenêtre de navigation privée et examinez le panneau réseau et le DOM à la recherche d'éléments injectés.

Si vous trouvez des preuves de scripts stockés ou de modifications suspectes, considérez que le site a été compromis et suivez les étapes de confinement et de nettoyage ci-dessous.

---

Confinement immédiat : que faire en premier (0–24 heures)

1. Mettez le site en mode maintenance. Cela réduit les dommages et les risques pendant votre enquête.
2. Désactivez le plugin (recommandé jusqu'à ce qu'il soit prouvé sûr ou qu'un correctif officiel soit disponible).
3. Si vous ne pouvez pas mettre le plugin hors ligne, activez un WAF géré ou un correctif virtuel pour bloquer le trafic d'exploitation. Les règles virtuelles doivent :
   • Bloquez les requêtes POST vers les points de terminaison du plugin avec des charges utiles suspectes (balises script, eval, URI javascript).
   • Bloquer les requêtes présentant des schémas de charge utile XSS typiques et des encodages suspects.
   • Appliquer SameSite et interdire les requêtes POST inter-origines vers les points de terminaison qui effectuent des modifications d'état.
4. Renouvelez les identifiants des comptes administrateurs et de service si vous soupçonnez une utilisation récente de comptes administrateurs ou le chargement de pages d'administration. Exigez des mots de passe robustes et l'authentification à deux facteurs.
5. Conservez les journaux et un instantané forensique : effectuez des sauvegardes du serveur (images disque ou au moins des sauvegardes de la base de données), sauvegardez les journaux du serveur Web et conservez une copie des fichiers affectés pour analyse.
6. Informez les parties prenantes (propriétaires du site, service juridique/communication, hébergeur) si une exposition publique est probable.

---

Nettoyage et récupération : étape par étape

Si le site est compromis, le nettoyage doit être méthodique. La précipitation augmente le risque de manquer une porte dérobée.

1. Sauvegarde : effectuez une sauvegarde complète (fichiers + base de données) et stockez-la hors ligne. Ne travaillez jamais sur l’unique copie.
2. Identifier et supprimer les charges utiles malveillantes :
   • Utilisez les recherches SQL ci-dessus pour localiser les charges utiles XSS stockées et supprimer ou nettoyer les lignes infectées.
   • Supprimez les fichiers de plugins ou de thèmes suspects qui ne faisaient pas partie des distributions officielles.
   • Recherchez les fichiers PHP dans les dossiers d'uploads ou de thèmes (des cachettes fréquentes pour les logiciels malveillants).
3. Réinstallez l'extension concernée depuis une source officielle et fiable après avoir vérifié la publication d'un correctif officiel. Si aucun correctif n'est disponible, laissez l'extension désactivée.
4. Faites pivoter toutes les clés et tous les secrets :
   • Modifier les mots de passe administrateur.
   • Régénérer les clés dans wp-config.php: AUTH_KEY, SECURE_AUTH_KEY, LOGGED_IN_KEY, NONCE_KEY, etc.
   • Rotation des clés API utilisées par les services tiers.
5. Vérifiez la présence de mécanismes de persistance supplémentaires :
   • Nouveaux utilisateurs administrateurs : auditez attentivement utilisateurs_wp.
   • Tâches planifiées : vérifier options_wp pour les entrées cron et wp_get_schedules.
   • Fichiers de thème/plugin modifiés : à comparer avec des versions fonctionnelles connues.
6. Mesures de renforcement (voir section ultérieure) : activer l’authentification à deux facteurs, restreindre l’accès administrateur par adresse IP lorsque cela est possible, appliquer une politique de sécurité du contenu.
7. Surveillance : renforcer la journalisation et la surveillance pendant au moins 30 jours après le nettoyage. Surveiller tout changement suspect.
8. Envisagez une intervention professionnelle en cas d'incident si la compromission est complexe ou si une exfiltration de données est suspectée.

---

Comment un pare-feu d'applications Web (WAF) et le correctif virtuel peuvent aider dès maintenant

En l'absence de correctif officiel, un pare-feu d'applications web (WAF) géré avec correctifs virtuels constitue la solution la plus rapide pour bloquer les exploitations. Voici comment un WAF efficace peut vous protéger contre ce problème spécifique :

• Signature and behavior-based blocking: WAFs can block requests containing script tags, suspicious encodings, or typical XSS payload structures (e.g., %3Cscript%3E or javascript: URIs).
• Règles d'atténuation CSRF : un WAF peut bloquer les requêtes POST inter-origines vers les points de terminaison administratifs en appliquant des vérifications de référent, en bloquant les modèles de trafic CSRF probables et en rejetant les requêtes sans en-têtes d'origine valides.
• Modèles de sécurité positifs : pour les terminaux qui attendent de petits champs de texte (par exemple, le titre d’une promotion), le WAF peut bloquer les charges utiles importantes ou les caractères de contrôle inattendus.
• Correctif virtuel : si le nom du point de terminaison du plugin et les noms des paramètres sont connus, le WAF peut appliquer une règle ciblée pour bloquer ou nettoyer les requêtes qui tentent d’écrire des données d’entrée de type script dans la base de données.
• Déploiement rapide : les règles WAF peuvent être déployées en quelques secondes ou minutes après la découverte d’une vulnérabilité, ce qui est crucial lorsque les fournisseurs n’ont pas encore publié de correctif.

Chez WP-Firewall, nous appliquons une approche similaire : nous surveillons les nouvelles vulnérabilités, créons des correctifs virtuels ciblés et les déployons auprès de nos clients afin qu’ils soient protégés avant même la publication d’un correctif officiel du fournisseur. Cette approche réduit considérablement la fenêtre d’attaque.

Note: Le patch virtuel est une couche de protection, et non un substitut aux correctifs du fournisseur. Dès que ce dernier publie un correctif officiel, appliquez-le sans tarder.

---

Exemples pratiques de règles WAF (à titre indicatif, ne pas copier sans discernement)

Vous trouverez ci-dessous des exemples de règles conceptuelles. Mettez-les en œuvre à l'aide de votre pare-feu ou de votre WAF géré. Il est impératif de tester les règles au préalable sur un environnement de test afin d'éviter les faux positifs.

1. Bloquer les requêtes POST vers le point de terminaison de sauvegarde du plugin contenant des balises de script :
   • Condition : la méthode HTTP est POST et l’URI de la requête contient « /wp-admin/admin-post.php » OU « /wp-admin/admin-ajax.php » (ou un point de terminaison spécifique au plugin).
   • Condition de la charge utile : le corps de la requête correspond à l’expression régulière (?je)(
   • Action : Bloquer / renvoyer une erreur 403
2. Appliquer l'exigence Referer/SameSite aux points de terminaison modifiant l'état :
   • Condition : Méthode HTTP == POST ET RequestURI correspond au point de terminaison du plugin ET (En-tête Origin manquant OU En-tête Referer manquant OU Origin ne correspond pas à votre site)
   • Action : Bloquer
3. Limiter la longueur et le nombre de caractères pour les paramètres spécifiques connus pour stocker le texte promotionnel :
   • Condition : La longueur du paramètre est supérieure au seuil attendu OU contient des caractères interdits comme < > scénario
   • Action : Nettoyer (si pris en charge) ou bloquer

Important: Adaptez les règles aux noms des paramètres et aux points de terminaison du plugin. Des règles trop générales peuvent perturber le bon fonctionnement du plugin.

---

Recommandations de renforcement — réduire les risques futurs

Cette vulnérabilité met en lumière des problèmes récurrents de sécurité dans WordPress : une protection CSRF insuffisante, un encodage de sortie inadéquat et une confiance excessive accordée aux données saisies par l’utilisateur. Appliquez les mesures suivantes pour limiter les risques à l’avenir.

1. Maintenez tous vos éléments à jour : noyau, thèmes et extensions. Abonnez-vous à la surveillance des vulnérabilités pour recevoir des alertes rapides.
2. Réduire la surface d'attaque :
   • Supprimez les plugins et thèmes inutilisés.
   • Utilisez un nombre minimal d'utilisateurs administrateurs et appliquez le principe du moindre privilège.
   • Limiter l'installation des plugins aux sources de confiance.
3. Renforcer les contrôles d'accès :
   • Exigez des mots de passe robustes et activez l'authentification à deux facteurs pour tous les utilisateurs administrateurs.
   • Verrouillez XML-RPC ou désactivez-le s'il n'est pas nécessaire.
   • Utilisez la liste blanche d'adresses IP pour wp-admin lorsque cela est possible.
4. En-têtes de sécurité HTTP :
   • Configurez la politique de sécurité du contenu (CSP) pour réduire l'impact des attaques XSS.
   • Définir X-Content-Type-Options : nosniff, X-Frame-Options : SAMEORIGIN.
   • Assurez-vous que les cookies sont configurés comme HttpOnly, Secure et avec SameSite=strict/lax selon le cas.
5. Bonnes pratiques pour les développeurs de plugins (fournisseurs et équipes de développement) :
   • Utilisez toujours les nonces WordPress pour les requêtes modifiant l'état.
   • Nettoyer les données en entrée (sanitize_text_field, wp_kses) et échapper les caractères spéciaux en sortie (esc_html, esc_attr, wp_kses_post) en fonction du contexte.
   • Vérifiez les types et les longueurs attendus pour chaque paramètre.
6. Plans de sauvegarde et de récupération :
   • Conserver des sauvegardes testées (hors site et immuables si possible).
   • Effectuez des exercices de restauration périodiques pour vous assurer du bon fonctionnement des sauvegardes.
7. Surveillance et journalisation :
   • Activer la journalisation du serveur et de l'application.
   • Utilisez la surveillance de l'intégrité des fichiers pour détecter les modifications non autorisées.

---

Liste de contrôle de réponse aux incidents (concis)

• [ ] Mettre le site hors ligne / passer en mode maintenance.
• [ ] Sauvegarde des fichiers et de la base de données.
• [ ] Désactivez le plugin vulnérable.
• [ ] Rechercher et supprimer les charges utiles malveillantes stockées (base de données + fichiers).
• [ ] Renouvelez tous les identifiants d'administrateur et les clés API.
• [ ] Reconstruisez ou réinstallez tous les fichiers de base/plugins/thème modifiés à partir de sources fiables.
• [ ] Appliquez le WAF / correctif virtuel en attendant la mise à jour officielle.
• [ ] Analysez le site avec un scanner de logiciels malveillants et un antivirus côté serveur.
• [ ] Surveillez le trafic, les journaux et le système de fichiers pour détecter toute récurrence.
• [ ] Une fois le nettoyage effectué, remettez le site en place et poursuivez la surveillance.

---

Surveillance et vérification à long terme

Après le nettoyage, surveiller toute réinfection. Pratiques recommandées :

• Contrôles quotidiens de l'intégrité des fichiers pendant 30 jours.
• Audits hebdomadaires ou bihebdomadaires de la base de données pour les nouvelles balises de script.
• Analyse régulière des vulnérabilités des thèmes/plugins.
• Examinez les intégrations tierces et les journaux d'accès pour détecter les accès anormaux.

Si l'incident a entraîné une exposition de données clients, veuillez suivre les procédures de notification légales et réglementaires en vigueur dans votre juridiction.

---

Pourquoi la mise à jour virtuelle rapide est importante : une brève étude de cas

On observe fréquemment un schéma similaire : divulgation d’une vulnérabilité → analyse et exploitation automatisées en quelques heures → compromission généralisée des sites qui n’ont pas été protégés rapidement.

Lorsque le fournisseur du plugin tarde à publier un correctif, le patch virtuel est la seule option pragmatique pour réduire drastiquement l'exploitation pendant que le développeur prépare un correctif définitif. Une simple règle ciblée bloquant les charges utiles de type script ou imposant des contrôles CSRF en périphérie peut stopper instantanément des milliers de tentatives d'exploitation.

---

Communication : que dire aux utilisateurs et aux parties prenantes ?

Si votre site a été publiquement affecté :

• Soyez transparent mais mesuré. Indiquez que vous avez subi un incident de sécurité, expliquez les mesures prises et confirmez si des données utilisateur ont été exposées (uniquement si vous l'avez confirmé par une analyse des journaux et une investigation numérique).
• Encouragez les utilisateurs à changer leur mot de passe si leurs identifiants ont été compromis.
• Veuillez fournir une chronologie de l'incident et les mesures correctives que vous avez mises en œuvre.

En cas de doute persistant, envisagez de fournir aux utilisateurs des conseils pour vérifier toute activité suspecte sur leurs comptes et recommandez-leur de changer leurs mots de passe.

---

Notes aux développeurs (pour les auteurs de plugins)

Si vous êtes responsable du code du plugin, assurez-vous de :

• Utilisez les nonces WordPress pour toutes les requêtes modifiant l'état (gestionnaires admin_post, admin_ajax, soumissions de formulaires).
• Appliquer les contrôles de capacité : vérifier current_user_can() pour toute action qui devrait être restreinte.
• Nettoyez toutes les entrées via la fonction de nettoyage appropriée et échappez la sortie en fonction du contexte (HTML, JS, URL).
• Évitez de stocker du code HTML brut sauf si cela est absolument nécessaire ; si vous devez absolument le stocker, utilisez un sous-ensemble sécurisé via wp_kses avec une liste blanche stricte.
• Tester le comportement en matière d'accès inter-origines et de CSRF dans le cadre des tests de mise en production.

---

Ressources et références

• Identifiant CVE : CVE-2025-7668
• Date de publication : 15 août 2025
• Type de vulnérabilité : CSRF → XSS stocké (A7 dans la classification OWASP Top 10)
• Recommandation CVSS : traiter comme une priorité d’atténuation immédiate même avec un score moyen en raison de la persistance non authentifiée.

(Les liens vers les avis techniques ou les démonstrations de faisabilité publiés par des fournisseurs externes sont intentionnellement omis ici — consultez vos flux de sécurité officiels et les canaux de vos fournisseurs.)

---

Protégez votre site dès maintenant ! Protection gérée gratuite avec WP-Firewall

Titre: Démarrez une protection gratuite avec le forfait de base de WP-Firewall

Si ce n'est pas déjà fait, protégez votre site WordPress avec la formule Basic (gratuite) de WP-Firewall. Elle offre une protection essentielle et constamment mise à jour : un pare-feu géré, un pare-feu applicatif web (WAF) robuste, une couverture de bande passante illimitée, l'analyse des logiciels malveillants et la protection contre les 10 principales vulnérabilités OWASP. Ainsi, même si le développeur d'une extension n'a pas encore publié de correctif, le déploiement de correctifs virtuels et les règles WAF ciblées peuvent bloquer les tentatives d'exploitation et garantir la sécurité de votre site. Des options supérieures sont disponibles si vous souhaitez bénéficier de la suppression automatique des logiciels malveillants, de la gestion des listes noires/blanches d'adresses IP, de rapports de sécurité mensuels ou encore d'un déploiement de correctifs virtuels complet et de services de sécurité gérés.

Inscrivez-vous et activez la protection de base ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Recommandations finales — actions prioritaires pour les propriétaires de sites

1. Si vous avez installé le plugin vulnérable : désactivez-le immédiatement ou appliquez une règle WAF pour bloquer les requêtes d’écriture vers ses points de terminaison.
2. Sauvegardez votre site (fichiers + base de données) dès maintenant avant d'effectuer des modifications.
3. Analysez la base de données à la recherche de balises de script stockées ; supprimez tout contenu malveillant trouvé.
4. Renouvelez les identifiants d'administrateur et activez l'authentification à deux facteurs.
5. Mettez en place un système de correctifs virtuels via un WAF géré jusqu'à ce que le fournisseur du plugin publie un correctif vérifié.
6. Lorsqu'une mise à jour officielle du plugin est disponible, consultez le journal des modifications et appliquez la mise à jour après avoir confirmé qu'elle corrige la vulnérabilité ; continuez à surveiller la présence de contenu malveillant résiduel.
7. Adoptez les mesures de renforcement décrites ci-dessus afin de réduire les risques de problèmes similaires à l'avenir.

---

Si vous avez besoin d'aide pour évaluer l'exposition aux menaces, créer des règles WAF adaptées à votre site ou effectuer un nettoyage suite à une analyse forensique, les équipes d'intervention et de sécurité gérée de WP-Firewall sont à votre disposition. Nos règles gérées peuvent être déployées immédiatement afin de réduire la durée d'une attaque pendant que vous menez vos investigations et corrigez les problèmes en toute sécurité.

Restez prudents et vérifiez dès aujourd'hui votre inventaire de plugins.