Atténuer l'authentification rompue des notifications de formulaire//Publié le 2026-05-18//CVE-2026-5229

ÉQUIPE DE SÉCURITÉ WP-FIREWALL

Form Notify Vulnerability Notification

Nom du plugin Notification de formulaire pour tous les formulaires
Type de vulnérabilité Authentification rompue
Numéro CVE CVE-2026-5229
Urgence Haut
Date de publication du CVE 2026-05-18
URL source CVE-2026-5229

Avis de sécurité urgent — Authentification rompue dans le plugin “Receive Notifications After Form Submitting – Form Notify for Any Forms” (CVE-2026-5229)

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-05-15
Mots clés: WordPress, Vulnérabilité, WAF, Sécurité des plugins, Réponse aux incidents

Un récent avis public sur les vulnérabilités a identifié un problème critique d'authentification rompue dans le plugin WordPress “Recevez des notifications après la soumission du formulaire – Notification de formulaire pour tous les formulaires” (versions <= 1.1.10). Le problème (CVE-2026-5229) permet aux attaquants non authentifiés de contourner l'authentification et de manipuler le comportement des notifications. La vulnérabilité a été attribuée d'un score CVSS de 9.8 et classée sous “Authentification rompue / Échecs d'identification et d'authentification” (OWASP A7).

Cet avis explique ce que cette vulnérabilité signifie pour les sites WordPress, comment les attaquants peuvent l'exploiter, comment détecter un compromis, et les étapes de remédiation immédiates et à long terme. En tant qu'opérateurs de WP‑Firewall (pare-feu et sécurité WordPress gérés), nous expliquons également comment un pare-feu d'application web et un patch virtuel peuvent réduire votre risque pendant que vous mettez à jour ou supprimez le plugin vulnérable.

Remarque : Cet article est rédigé du point de vue des praticiens de la sécurité WordPress. Si vous gérez des sites WordPress utilisant ce plugin, considérez cela comme une priorité urgente.

Résumé exécutif

  • Un contournement d'authentification de haute gravité (CVE-2026-5229) affecte les versions du plugin “Receive Notifications After Form Submitting – Form Notify for Any Forms” <= 1.1.10.
  • Une version corrigée est disponible dans la version 1.1.11. Mettez à jour immédiatement.
  • Les attaquants peuvent exploiter le bogue sans authentification, changeant potentiellement l'endroit où les notifications de formulaire sont livrées, créant des portes dérobées, ou pivotant vers des privilèges plus élevés selon la configuration du site.
  • Les atténuations immédiates incluent la mise à jour du plugin, la désactivation ou la suppression du plugin si la mise à jour n'est pas possible, le déploiement de règles WAF pour bloquer les modèles d'exploitation, et la surveillance des indicateurs de compromis.
  • Les clients de WP‑Firewall peuvent activer les protections de pare-feu gérées et le patching virtuel pour réduire l'exposition lors de la remédiation.

En quoi consiste exactement cette vulnérabilité ?

À un niveau élevé, le plugin expose des fonctionnalités qui manipulent le comportement des notifications de soumission de formulaire. En raison de contrôles d'authentification et de vérification inappropriés, une requête non authentifiée peut déclencher la fonctionnalité de notification du plugin ou changer des paramètres internes qui contrôlent les destinataires des notifications ou le flux de traitement. Le défaut est classé comme Authentification rompue (échecs d'identification ou d'authentification) — ce qui signifie que les vérifications du plugin qui devraient authentifier ou autoriser qui peut invoquer certaines fonctions sont contournables.

Propriétés clés :

  • Affecte les versions du plugin : <= 1.1.10
  • Corrigé dans : 1.1.11
  • CVE : CVE-2026-5229
  • CVSS : 9.8 (Critique / Élevé)
  • Privilège requis : Aucun — les attaquants non authentifiés peuvent l'exploiter

Parce que l'attaquant n'a besoin d'aucune session utilisateur valide ou de crédentiels, tout site WordPress accessible au public avec le plugin vulnérable installé est à risque.

Pourquoi cela importe : impact pratique

Les vulnérabilités d'authentification rompue sont régulièrement utilisées dans des campagnes d'exploitation de masse. Les impacts pratiques varient selon la manière dont le plugin s'intègre au site, mais les risques courants dans le monde réel incluent :

  • Modification non autorisée des destinataires de notification de formulaire : un attaquant peut changer les adresses e-mail ou les points de terminaison webhook pour intercepter des pistes, des e-mails de réinitialisation de mot de passe ou des données de formulaire.
  • Transfert de messages : des données sensibles soumises par les utilisateurs pourraient être exfiltrées.
  • Déclenchement d'actions qui dépendent du plugin : par exemple, si le plugin déclenche des hooks côté serveur, les attaquants peuvent l'utiliser pour exécuter ou enchaîner d'autres actions.
  • Empreinte pour une compromission ultérieure : les attaquants peuvent modifier des paramètres, créer des utilisateurs administrateurs fantômes via des vulnérabilités en chaîne, ou ajouter des portes dérobées persistantes.
  • Campagnes de spam et dommages à la réputation : les notifications de formulaire automatisées pourraient être abusées pour envoyer des e-mails de spam ou de phishing depuis votre domaine.
  • Exploitation à grande échelle : parce que la vulnérabilité est non authentifiée, des scanners et des bots automatisés peuvent cibler rapidement des milliers de sites.

Les sites contenant des données sensibles (informations clients, données de pistes, formulaires capturant des identifiants, ou intégrations avec des CRM) sont à risque immédiat.

Scénarios d'exploitation de haut niveau (ce que les attaquants pourraient faire)

Nous décrirons des flux d'attaque réalistes sans fournir de code d'exploitation étape par étape.

  1. Énumération et ciblage
    • L'attaquant scanne les sites WordPress pour identifier les installations avec la version vulnérable du plugin.
    • Une fois trouvée, l'attaquant envoie des requêtes HTTP élaborées aux points de terminaison publics du plugin qui gèrent la configuration des notifications ou déclenchent des notifications.
  2. Manipulation des notifications
    • En utilisant le point de terminaison non authentifié, l'attaquant définit un destinataire de notification qu'il contrôle (e-mail ou webhook).
    • Les soumissions de formulaires suivantes — y compris les formulaires soumis par des utilisateurs légitimes — sont transférées à l'attaquant.
  3. Exfiltration de données
    • L'attaquant déclenche des soumissions de formulaires (ou attend des soumissions légitimes) pour capturer le contenu des formulaires (par exemple, formulaires de contact, formulaires de demande, soumissions de CV).
  4. Exploitation en chaîne
    • Avec le contrôle des notifications, les attaquants collectent des e-mails administratifs, des jetons de réinitialisation, ou des liens vers des pages de phishing pour tromper les administrateurs de site.
    • Ils peuvent utiliser d'autres vulnérabilités de plugin ou des identifiants faibles connus pour obtenir un accès administrateur.
  5. Abus massif
    • Les campagnes automatisées peuvent abuser du système pour utiliser votre domaine pour des spams par email ou du phishing.

Comme les actions ne nécessitent aucune authentification préalable, une exploitation automatisée rapide est attendue. Traitez tout site avec le plugin vulnérable comme urgent.

Indicateurs de compromission (IoCs) et ce qu'il faut rechercher

Si vous soupçonnez que votre site pourrait être ciblé ou compromis, vérifiez ce qui suit :

  • Destinataires de notifications inattendus :
    • Vérifiez les paramètres du plugin pour des adresses email ou des URL de webhook que vous ne reconnaissez pas.
    • Passez en revue les enregistrements de la base de données pour des destinataires récemment ajoutés ou des adresses inhabituelles.
  • Modifications suspectes des options du plugin :
    • Recherchez des changements dans wp_options avec des valeurs option_name liées au plugin ou des horodatages de configuration de notification qui ne correspondent pas à votre activité d'administrateur.
  • Connexions sortantes soudaines ou pics dans les emails sortants :
    • Journaux de mail montrant des emails de notification de formulaire à des adresses ou domaines jamais vus auparavant.
    • Volume anormal d'emails de formulaire de contact.
  • Fichiers ou tâches cron inattendus :
    • Recherchez des fichiers PHP inconnus dans wp-content/uploads, wp-content/plugins ou d'autres répertoires écrits.
    • Vérifiez les événements programmés (wp_cron) pour de nouvelles tâches inattendues.
  • Nouveaux comptes administrateurs ou comptes modifiés :
    • Passez en revue wp_users et wp_usermeta pour des utilisateurs inattendus ou des élévations de privilèges.
  • Journaux d'accès du serveur web :
    • Requêtes vers des points de terminaison spécifiques au plugin autour du moment d'activité suspecte.
    • Requêtes POST avec des charges utiles inhabituelles vers des chemins de plugin connus.
  • Webhooks externes inhabituels :
    • Systèmes tiers recevant des webhooks que vous n'avez pas configurés.

Si vous trouvez l'un des éléments ci-dessus, considérez le site comme potentiellement compromis et suivez la section de réponse aux incidents ci-dessous.

Étapes immédiates : une liste de contrôle priorisée

  1. IDENTIFIER
    • Faites l'inventaire de tous les sites WordPress que vous gérez.
    • Identifiez tout site avec le plugin vulnérable installé (<= 1.1.10).
  2. PATCHER / RETIRER (Priorité #1)
    • Mettez à jour le plugin vers 1.1.11 ou une version ultérieure immédiatement.
    • Si vous ne pouvez pas mettre à jour immédiatement, désactivez le plugin ou retirez-le jusqu'à ce que vous puissiez mettre à jour.
  3. RESTRICT (Priorité #2)
    • Si la mise à jour immédiate n'est pas possible, bloquez l'accès aux points de terminaison publics du plugin au niveau du serveur web ou du WAF.
    • Désactivez l'accès public aux points de terminaison de traitement des formulaires si possible (par exemple, restreindre par IP ou exiger une authentification).
  4. SURVEILLER (Priorité #3)
    • Surveillez les e-mails sortants et les webhooks pour des adresses inhabituelles.
    • Inspectez les journaux du serveur web pour des POST suspects contre les points de terminaison du plugin.
    • Activez la journalisation détaillée pendant une période.
  5. ANALYSER (Priorité #4)
    • Effectuez une analyse complète des logiciels malveillants du site web et des vérifications d'intégrité des fichiers.
    • Analysez la base de données et le système de fichiers pour des fichiers nouveaux ou modifiés et des entrées suspectes.
  6. IDENTIFIANTS (Priorité #5)
    • Réinitialisez les mots de passe administrateur et éditeur (de préférence appliquez des réinitialisations de mot de passe).
    • Faites tourner les clés API et les identifiants qui ont pu être exposés.
  7. ENQUÊTER & REMÉDIER (Priorité #6)
    • Si vous détectez une compromission, suivez la liste de contrôle de réponse à l'incident ci-dessous.
    • Restaurer à partir d'une sauvegarde propre connue si nécessaire.
  8. DOCUMENTER
    • Conservez un enregistrement de toutes les actions entreprises, des délais et des résultats pour référence future ou conformité.

Correction permanente recommandée

  • Mettez à jour le plugin vers la version 1.1.11 (ou ultérieure) immédiatement. Le correctif du fournisseur résout le contournement d'authentification.
  • Après la mise à jour :
    • Ré-auditez les paramètres du plugin pour vous assurer que les destinataires de notification et les webhooks sont corrects.
    • Relancez les analyses de logiciels malveillants et vérifiez l'intégrité des fichiers.
    • Si vous avez temporairement supprimé le plugin, vérifiez le comportement du plugin mis à jour dans un environnement de staging avant de le réactiver en production.

Si l'éditeur du plugin est injoignable ou si vous ne pouvez pas appliquer le correctif, envisagez de remplacer le plugin par une alternative maintenue, ou retirez les fonctionnalités inutiles et ajoutez une atténuation côté serveur.

Comment un pare-feu d'application Web (WAF) aide — correction virtuelle immédiate

Un WAF ne peut pas remplacer la mise à jour du plugin, mais il peut réduire considérablement le risque pendant que vous remédiez en appliquant des correctifs virtuels ciblés. WP‑Firewall fournit des protections WAF gérées qui peuvent être déployées instantanément sur les sites affectés.

Exemples de stratégies d'atténuation WAF :

  1. Bloquez l'accès aux points de terminaison vulnérables
    • Si le plugin expose un point de terminaison PHP public spécifique ou un chemin URL, créez une règle pour bloquer ou contester les demandes à celui-ci, sauf celles provenant de plages IP de confiance.
    • Exemple (pseudo-règle) :
      • Condition : L'URI de la demande correspond à /wp-content/plugins/form-notify/.* OU d'autres points de terminaison de plugin
      • Action : Bloquer / Retourner 403
  2. Bloquez les combinaisons de paramètres suspects
    • Si l'exploitation repose sur des paramètres POST spécifiques ou des clés de charge utile JSON, bloquez les demandes contenant ceux-ci lorsqu'elles proviennent d'utilisateurs non authentifiés.
    • Exemple (pseudo-règle) :
      • Condition : POST contient le paramètre notifier_à OU définir_destinataire ET cookie wordpress_logged_in n'est PAS présent
      • Action : Bloquer
  3. Limiter le taux et défier les tentatives à haute fréquence
    • Appliquer des limitations de taux ou des défis CAPTCHA aux points de terminaison du plugin pour interrompre les tentatives de scan automatisé et d'exploitation de masse.
  4. Supprimer ou assainir les destinations de webhook sortants
    • Pour les sites où des webhooks sortants sont utilisés et routés via du code côté serveur, un proxy ou une liste blanche peut empêcher la communication avec des hôtes externes inconnus.
  5. Signatures de patch virtuel
    • Créer des signatures WAF pour des modèles de charge utile d'exploitation connus observés dans la nature (sans publier les détails d'exploitation publiquement), et bloquer les demandes correspondant à ces signatures.
  6. Journalisation et alertes
    • Journaliser les demandes refusées avec des charges utiles complètes (lorsque cela est autorisé par les politiques de confidentialité) et alerter les propriétaires de sites lorsqu'une tentative bloquée se produit.

Important: Lors de la création de règles WAF, éviter les faux positifs qui perturbent la fonctionnalité légitime. Nous recommandons de tester les règles sur une instance de staging lorsque cela est possible. L'action immédiate la plus efficace pour la plupart des propriétaires de sites est d'activer le patch fourni par le fournisseur (1.1.11) et d'utiliser les protections WAF comme couche de défense temporaire.

Exemples de modèles de règles WAF (pseudo-code)

Ci-dessous se trouvent des règles illustratives que vous pouvez adapter pour votre WAF (mod_security, Nginx, interface WAF cloud). Ce sont des exemples — ne pas coller en production sans test.

1) Bloquer l'accès direct aux points de terminaison d'administration du plugin depuis des utilisateurs non authentifiés

2) Bloquer les demandes qui tentent de définir des destinataires de notification depuis des sources non authentifiées

3) Défi (CAPTCHA) pour les demandes à haute fréquence

4) Bloquer les destinations de webhook sortants suspectes (basé sur un proxy)

Encore une fois, ce sont des règles de haut niveau. Utilisez les noms de paramètres exacts et les modèles URI que votre plugin utilise et validez dans un environnement de test.

Liste de contrôle d'analyse (si vous pensez avoir été compromis)

  1. Isolez le site
    • Mettre le site en mode maintenance ou restreindre l'accès par IP pendant l'enquête.
  2. Conserver les bûches
    • Préserver les journaux du serveur web, PHP-FPM, des mails et des applications. Ne pas écraser les journaux.
  3. Rassembler des indicateurs
    • Lister les IP qui ont envoyé des tentatives d'exploitation.
    • Enregistrer les charges utiles et les horodatages des requêtes.
  4. Scannez à la recherche de web shell/backdoors
    • Exécuter des vérifications d'intégrité des fichiers ; rechercher des fichiers récemment modifiés, du PHP obfusqué suspect ou des fichiers avec des autorisations de fichier inhabituelles.
  5. Audit des comptes d'utilisateurs
    • Rechercher de nouveaux utilisateurs administrateurs, des modifications des utilisateurs existants ou des rôles suspects.
  6. Examiner les e-mails/webhooks
    • Vérifier les journaux de messagerie pour des messages transférés vers des adresses inconnues.
  7. Révoquez les identifiants compromis
    • Réinitialiser les mots de passe administrateurs et faire tourner les clés pour les services externes.
  8. Nettoyez ou restaurez
    • S'il existe des preuves de compromission, restaurer à partir d'une sauvegarde propre effectuée avant la compromission, puis appliquer des correctifs et durcir la sécurité.
    • Si la restauration n'est pas possible, nettoyer les fichiers et durcir l'accès avec précaution, et vérifier l'intégrité.
  9. Surveillance post-incident
    • Augmenter la surveillance pendant au moins 30 jours et scanner de manière proactive pour une réintroduction.
  10. Signalez et communiquez
    • Informer les parties prenantes, et si applicable, notifier les clients si une exposition de données a eu lieu.

Recommandations de durcissement pour les sites WordPress (au-delà de ce plugin)

  • Gardez le cœur de WordPress, les plugins et les thèmes à jour selon un calendrier régulier.
  • Limiter l'accès administrateur par IP ou authentification à deux facteurs (2FA) pour les utilisateurs privilégiés.
  • Utiliser des mots de passe uniques et forts ainsi qu'un gestionnaire de mots de passe.
  • Limiter l'installation de plugins et n'utiliser que des plugins activement maintenus provenant de sources fiables.
  • Scanner régulièrement à la recherche de logiciels malveillants et exécuter une surveillance de l'intégrité des fichiers.
  • Assurer le principe du moindre privilège : donner aux utilisateurs uniquement les capacités dont ils ont besoin.
  • Sauvegarder votre site quotidiennement ou plus fréquemment si le contenu change souvent, et conserver les sauvegardes hors site.
  • Surveiller les connexions sortantes inhabituelles et les volumes d'e-mails.
  • Utilisez HTTPS et HSTS pour protéger les données en transit.

Comment WP‑Firewall aide lors de vulnérabilités comme CVE-2026-5229

En tant que fournisseur de sécurité WordPress géré, WP‑Firewall vous aide à plusieurs étapes :

  • Détection : l'intelligence continue sur les vulnérabilités associe les avis publics aux sites installés dans votre flotte afin que vous puissiez prioriser les mises à jour.
  • Patching virtuel : notre WAF géré peut déployer rapidement des règles ciblées pour bloquer les tentatives d'exploitation sur vos sites.
  • Analyse : des analyses programmées de logiciels malveillants et d'intégrité identifient les fichiers suspects et les changements de configuration.
  • Réponse aux incidents : des manuels de remédiation basés sur les meilleures pratiques minimisent les temps d'arrêt et vous aident à récupérer rapidement.
  • Atténuation pour OWASP Top 10 : notre pare-feu géré contient des défenses contre les classes d'attaques courantes pertinentes pour cette vulnérabilité (authentification cassée, injection, etc.).
  • Vérification par étapes : lorsqu'un fournisseur publie un correctif, nous pouvons surveiller et valider le comportement des plugins et conseiller sur un rythme de mise à jour sûr.

Bien qu'un WAF réduise l'exposition et puisse prévenir de nombreuses attaques automatisées, il ne remplace pas l'application des mises à jour du fournisseur. L'approche combinée — correctif plus WAF — est le chemin le plus sûr.

Requêtes de détection pratiques et recherches de journaux (exemples)

Utilisez ces requêtes d'exemple dans des analyseurs de journaux (par exemple, ELK, Splunk) pour trouver des activités suspectes. Remplacez form-notify par le chemin réel du plugin s'il est différent.

1) Détecter les POST vers les points de terminaison des plugins

2) Détecter des destinataires de notification inhabituels dans les journaux de mail

3) Détecter les changements d'options de plugin dans les journaux d'audit MySQL;

4) Detect new admin users
SELECT ID, user_login, user_email, user_registered FROM wp_users WHERE ID IN (SELECT user_id FROM wp_usermeta WHERE meta_key = 'wp_capabilities' AND meta_value LIKE '%administrator%') ORDER BY user_registered DESC;

Ces requêtes aident à établir si la vulnérabilité a été exploitée contre votre site.

Communications et conformité

  • Si l'exploitation a entraîné une exposition de données (informations de contact, e-mails ou données personnelles), vérifiez les exigences de notification de violation de données applicables dans votre juridiction et préparez la divulgation si nécessaire.
  • Tenez les clients et les parties prenantes informés du calendrier de détection, de confinement, de remédiation et de vérification.
  • Préservez les artefacts judiciaires au cas où une intervention des forces de l'ordre ou d'un tiers serait nécessaire.

Nouveau : Obtenez une protection gratuite immédiate avec WP‑Firewall

Protégez votre site WordPress dès aujourd'hui avec notre plan de base (gratuit) — idéal pour des protections essentielles immédiates pendant que vous appliquez des correctifs. Le plan de base comprend une couverture de pare-feu gérée, une bande passante illimitée, un WAF, une analyse de logiciels malveillants et une atténuation des risques OWASP Top 10 — tout ce dont vous avez besoin pour fermer les vecteurs d'attaque les plus courants et réduire l'exposition immédiate.

En savoir plus et inscrivez-vous au plan gratuit à :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Nous recommandons d'activer les protections de pare-feu et le patching virtuel sur tout site utilisant le plugin vulnérable jusqu'à ce que vous mettiez à jour vers la version 1.1.11.)

Recommandations à long terme et meilleures pratiques

  1. Programme de gestion des correctifs
    • Mettez en œuvre un rythme de mise à jour formel pour le cœur, les plugins et les thèmes. Priorisez les mises à jour de sécurité et les CVE critiques.
  2. Mises à jour de staging et de test
    • Testez les plugins et les mises à jour en staging avant le déploiement en production, mais ne laissez pas les tests retarder les correctifs de sécurité critiques.
  3. Moindre privilège et paramètres par défaut sécurisés
    • Réduisez le nombre de plugins pouvant modifier le comportement du site pour les communications externes (emails, webhooks).
  4. Renforcez les flux de notification
    • Exigez une confirmation d'administrateur secondaire pour les changements de destinataires de notification lorsque cela est possible.
    • Appliquez des listes autorisées pour les cibles de webhook.
  5. Livres de procédures d'incidents
    • Maintenez des livres de jeu clairs pour la réponse aux vulnérabilités, y compris les rôles et responsabilités, les listes de notification et les procédures de sauvegarde.
  6. Surveillance continue
    • Surveillance continue et alertes pour les vulnérabilités de haute gravité dans les plugins installés.

Exemple de calendrier de récupération post-incident (recommandé)

  1. Jour 0 (détection)
    • Identifiez les sites affectés, isolez-les si nécessaire, déployez une règle WAF pour bloquer les vecteurs d'exploitation.
    • Mettez à jour le plugin vers 1.1.11 sur tous les systèmes impactés.
  2. Jour 1
    • Exécutez des analyses complètes de logiciels malveillants et d'intégrité.
    • Faites tourner les identifiants administratifs et les clés API.
    • Auditez les journaux de mail et les webhooks externes.
  3. Jour 2–7
    • Examinez les sauvegardes et restaurez les données affectées si nécessaire.
    • Augmentez la surveillance et collectez les journaux pour un examen judiciaire.
    • Communiquez avec les parties prenantes.
  4. Jour 7–30
    • Continuez la surveillance élevée ; vérifiez qu'il n'y a pas de réintroductions.
    • Mettez en œuvre des étapes de durcissement à long terme.

Derniers mots — pourquoi vous devriez agir maintenant

Les contournements d'authentification non authentifiés sont le type de vulnérabilité préféré des attaquants : ils ne nécessitent aucune identification et peuvent être rapidement armés. Si vous avez le plugin vulnérable installé, vous devez prioriser la mise à jour vers 1.1.11 dès maintenant. Utilisez des contrôles de protection (WAF, limitation de taux, liste blanche) lors de la mise à jour, et effectuez un audit minutieux pour détecter des signes d'exploitation.

Si vous gérez plusieurs sites, traitez cela comme une vulnérabilité de flotte et appliquez des correctifs cohérents sur chaque site affecté. Combinez le correctif avec une atténuation proactive du WAF pour minimiser les risques pendant la fenêtre de mise à jour.

Si vous avez des questions ou souhaitez de l'aide pour appliquer des atténuations sur de nombreux sites, notre équipe de sécurité est disponible pour aider avec le patching virtuel, le scanning et la réponse aux incidents.

Références et lectures complémentaires

Si vous souhaitez de l'aide pour trier les sites affectés, déployer des règles WAF temporaires, ou obtenir un scan automatisé sur votre flotte WordPress

Notre équipe de sécurité chez WP‑Firewall peut vous aider. Inscrivez-vous au plan de base (gratuit) pour une couverture de protection immédiate et voyez comment le patching virtuel et le WAF géré peuvent vous donner du temps pour patcher en toute sécurité :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

wordpress security update banner

Recevez gratuitement WP Security Weekly 👋
S'inscrire maintenant!!

Inscrivez-vous pour recevoir la mise à jour de sécurité WordPress dans votre boîte de réception, chaque semaine.

Nous ne spammons pas ! Lisez notre politique de confidentialité pour plus d'informations.

Contactez-nous pour planifier une consultation gratuite sur la sécurité WordPress

Contactez-nous

WP-Pare-feu
6/F, The Rays, 71 Hung To Road, Kwun Tong, Kowloon, Hong Kong

Caractéristiques Tarifs Blog Se connecter
politique de confidentialité Conditions d'utilisation Documents Affilier

© 2026 WP-Firewall™