Renforcer WordPress contre le contrôle d'accès défaillant//Publié le 2026-04-09//CVE-2026-4977

ÉQUIPE DE SÉCURITÉ WP-FIREWALL

UsersWP Vulnerability Image

Nom du plugin UsersWP
Type de vulnérabilité Contrôle d'accès brisé
Numéro CVE CVE-2026-4977
Urgence Faible
Date de publication du CVE 2026-04-09
URL source CVE-2026-4977

Contrôle d'accès défaillant dans UsersWP (≤ 1.2.58) — Ce que les propriétaires de sites WordPress doivent faire maintenant

Date: 10 avril 2026
CVE : CVE-2026-4977
Gravité: Faible (CVSS 4.3) — Privilège requis : Abonné

Une vulnérabilité récemment divulguée dans le plugin UsersWP (versions jusqu'à et y compris 1.2.58) permet à un utilisateur authentifié avec un accès de niveau Abonné de modifier des usermeta restreints via le htmlvar paramètre. Bien que la vulnérabilité soit classée comme de faible gravité, les problèmes de contrôle d'accès défaillant sont souvent une cible attrayante pour les attaquants car ils peuvent être combinés avec d'autres failles pour créer des compromissions plus importantes. Dans cet article, j'expliquerai quel est le problème, le risque réaliste pour votre site, comment détecter les abus et des atténuations pratiques — y compris des stratégies de patch virtuel immédiates que vous pouvez appliquer dès maintenant en utilisant un pare-feu d'application Web (WAF) ou des corrections au niveau du code.

Cet article est écrit du point de vue de WP-Firewall, un fournisseur de sécurité WordPress et un vendeur de WAF, et vise à donner aux administrateurs de sites des conseils clairs et utilisables. Le ton est pratique et direct — pas de discours commercial, juste des conseils d'experts.

Résumé exécutif — TL;DR

  • Ce qui s'est passé: UsersWP ≤ 1.2.58 contenait une condition de contrôle d'accès défaillant où un Abonné authentifié pouvait manipuler certaines métadonnées utilisateur via un htmlvar paramètre.
  • Impact: Faible en soi ; cependant, s'il est utilisé pour changer des usermeta sensibles (ou combiné avec d'autres vulnérabilités), un attaquant pourrait escalader ses privilèges, créer une persistance ou abuser des intégrations liées au compte.
  • Versions concernées : Versions UsersWP ≤ 1.2.58
  • Version corrigée : 1.2.59 — mettez à jour immédiatement si vous utilisez le plugin.
  • Si vous ne pouvez pas effectuer la mise à jour immédiatement : appliquez un patch virtuel au WAF (bloquez/inspectez les requêtes avec htmlvar pour des sessions à faible privilège), appliquez des vérifications de capacité côté serveur et mettez sur liste blanche les clés usermeta autorisées avant de mettre à jour.
  • Détection : Recherchez des requêtes vers les points de terminaison UsersWP portant un htmlvar paramètre initié par des comptes Abonnés ; vérifiez les changements de usermeta ; vérifiez les journaux pour des opérations d'écriture inattendues sur des clés sensibles comme wp_capabilities, rôles ou indicateurs de privilège personnalisés.

Qu'est-ce que le “Contrôle d'accès brisé” dans ce contexte ?

Le contrôle d'accès défaillant se produit lorsque l'application ne parvient pas à appliquer des vérifications d'autorisation appropriées, permettant aux utilisateurs authentifiés ou non authentifiés d'effectuer des actions qu'ils ne devraient pas pouvoir effectuer. Dans ce cas UsersWP :

  • Le plugin acceptait un htmlvar paramètre (couramment utilisé pour nommer une clé usermeta à mettre à jour) et le traitait sans autorisation ou validation suffisante pour la clé méta cible ou l'utilisateur cible.
  • Un utilisateur authentifié avec le rôle d'Abonné pouvait utiliser ce paramètre pour mettre à jour des usermeta qui devraient être restreints — soit pour lui-même de manière inappropriée, soit dans certains cas pour d'autres utilisateurs (selon la manière dont le plugin traitait la requête).
  • L'absence de vérifications de capacité, de vérification de nonce ou d'une liste blanche stricte des clés méta autorisées sont des causes profondes courantes de cette classe de bogue.

Ce n'est pas une vulnérabilité d'exécution de code à distance complète ou de prise de contrôle de base de données en soi, c'est pourquoi elle a reçu un score CVSS plus bas. Mais le contrôle d'accès défaillant est dangereux car il augmente la surface d'attaque pour l'escalade de privilèges et la persistance.

Pourquoi même une vulnérabilité de gravité “ faible ” mérite de l'attention

De nombreux propriétaires de sites ignorent les alertes de faible gravité. C'est une erreur. Considérez :

  • Chaînage d'attaques : Un contrôle d'accès défaillant de faible gravité peut être combiné avec d'autres faiblesses (mots de passe faibles, rôles mal configurés, un thème ou un point de terminaison de plugin vulnérable) pour escalader les privilèges.
  • Automatisation : Même les contrôles de faible niveau sont attrayants pour une exploitation de masse automatisée s'ils sont faciles à détecter. Les bots ne se soucient pas des nuances.
  • Intégrité des données : La modification non autorisée des métadonnées — telles que les indicateurs de visibilité de profil, les balises de contournement de 2FA ou les clés d'intégration personnalisées — peut avoir des conséquences à long terme.
  • Conformité et confiance : Toute modification non autorisée des données utilisateur peut nuire à la confiance des clients et, pour certaines entreprises, soulever des préoccupations réglementaires.

Ainsi, les mises à jour et les atténuations doivent être prioritaires en fonction de votre modèle de menace — mais ne l'ignorez pas.

Comment un attaquant abuserait typiquement de cette vulnérabilité (niveau élevé)

J'éviterai de publier du code d'exploitation, mais voici un flux d'attaque de haut niveau afin que vous puissiez renforcer la sécurité de manière appropriée :

  1. Enregistrez un compte ou utilisez un compte d'abonné existant pour vous connecter.
  2. Trouvez le point de terminaison UsersWP qui accepte le htmlvar paramètre (c'est généralement une route de mise à jour de profil front-end, un gestionnaire de formulaire ou une action AJAX).
  3. Soumettez une demande contenant htmlvar défini sur une clé méta que l'attaquant souhaite changer. Si le plugin met à jour les métadonnées utilisateur directement sans vérifications de permission et sans valider quelles métas peuvent être modifiées, le changement sera appliqué.
  4. Si l'attaquant peut cibler des clés méta qui influencent les rôles/capacités, ou des jetons d'intégration, il peut escalader ou persister. Sinon, il pourrait toujours changer des détails de profil ou des indicateurs qui pourraient être exploités plus tard.

Ce qui rend cela dangereux, ce n'est pas seulement ce qui peut être changé immédiatement — mais ce que ce changement permet par la suite.

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

Si vous soupçonnez un abus ou souhaitez chasser de manière proactive, recherchez :

  • des requêtes HTTP vers les points de terminaison UsersWP (points de terminaison de formulaire front-end ou gestionnaires admin-ajax) avec htmlvar le paramètre présent dans les charges utiles POST ou GET.
  • Demandes où ID de l'utilisateur ou un paramètre similaire est présent et diffère de l'utilisateur authentifié (tentatives de modifier d'autres utilisateurs).
  • Changements inattendus dans usermeta dans la base de données WordPress — examinez le usermeta table pour des modifications ou des paramètres inhabituels qui n'étaient pas attendus.
  • Nouveaux utilisateurs administrateurs, rôles modifiés ou autorisations altérées.
  • Augmentations des requêtes provenant d'IP uniques ou d'un ensemble d'IP soumettant de nombreuses demandes de mise à jour de profil.
  • Tout script suspect téléchargé par un plugin/thème ou événements planifiés inhabituels (hooks wp_cron ajoutés par un code de plugin inconnu) qui apparaissent après la période pendant laquelle htmlvardes requêtes de style - sont observées.

Collectez des journaux, prenez des instantanés et préservez les preuves avant d'apporter des modifications de remédiation si vous êtes dans un incident en direct.

Actions immédiates (ordre recommandé)

  1. Mettez à jour UsersWP immédiatement vers la version 1.2.59 ou ultérieure. C'est la solution définitive — à condition que les auteurs du plugin aient mis en œuvre des vérifications d'autorisation appropriées et des contrôles de clé méta.
  2. Si vous ne pouvez pas mettre à jour immédiatement, mettez en œuvre un patch virtuel au niveau du WAF. Bloquer ou filtrer les requêtes contenant le htmlvar paramètre (ou bloquer spécifiquement les POST vers les points de terminaison de profil UsersWP des comptes Abonnés) est une solution temporaire efficace.
  3. Auditez les changements de usermeta et les rôles. Si vous voyez des changements indésirables, revenez à une sauvegarde connue comme bonne ou restaurez des valeurs usermeta spécifiques à partir des sauvegardes.
  4. Faites tourner toutes les identifiants ou jetons d'intégration stockés dans usermeta ou les options de plugin si vous soupçonnez qu'ils ont été accédés.
  5. Vérifiez les fichiers et téléchargements de plugin/thème pour des portes dérobées si vous voyez des signes de compromission.
  6. Appliquez des politiques de mot de passe fortes, activez l'authentification à deux facteurs pour les utilisateurs privilégiés et examinez les rôles des utilisateurs pour le moindre privilège.

La mise à jour est la solution à long terme — mais le patching virtuel et la surveillance atténuent le risque dans la fenêtre critique.

Comment WP-Firewall protège les sites de cette classe de vulnérabilités

Chez WP-Firewall, nous combinons plusieurs couches pour réduire la probabilité que le contrôle d'accès défaillant dans un plugin soit exploité :

  • Correctif virtuel (règles WAF) : Nous pouvons déployer des règles qui inspectent les charges utiles des requêtes et bloquent les modèles suspects — par exemple, les requêtes contenant un paramètre nommé htmlvar qui est utilisé pour écrire des usermeta. Cela empêche l'exploitation de masse pendant que vous mettez à jour les plugins.
  • Règles conscientes des rôles : Notre WAF peut appliquer différentes règles en fonction de l'état de la session. Par exemple, bloquer les abonnés d'accéder aux points de terminaison réservés aux éditeurs/admins, et bloquer les requêtes POST avec des paramètres qui affectent les usermeta à moins que la session n'appartienne à un utilisateur ayant les capacités requises.
  • Détection d'anomalies : Nous suivons des séquences de requêtes inhabituelles — comme de nombreuses mises à jour de profil en peu de temps — et levons des alertes ou limitons automatiquement les contrevenants.
  • Intégrité des fichiers et analyse des logiciels malveillants : Si une exploitation trouve un moyen de persister, notre analyse recherche des fichiers modifiés, des événements planifiés inattendus et des modèles de porte dérobée courants.
  • Alertes de mise à jour automatiques et recommandations de patching gérées : Nous poussons des conseils de patching prioritaires afin que vous puissiez mettre à jour rapidement et en toute sécurité.

Si vous utilisez un service de sécurité qui inclut le patching virtuel, vous bénéficiez d'une protection immédiate sans modifier le code du site — idéal pour les sites sur hébergement géré ou lorsque les mises à jour de plugins nécessitent des tests.

Concepts de règles WAF d'exemple que vous pouvez utiliser pour le patching virtuel

Ci-dessous se trouvent des exemples conceptuels que vous pouvez adapter à votre WAF. Ne les collez pas en production sans test. Ils sont intentionnellement conservateurs : détecter et bloquer les requêtes qui tentent d'utiliser htmlvar depuis des sessions à faible privilège ou en dehors des formulaires attendus.

ModSecurity (conceptuel) :

# Bloquer les POST contenant un paramètre htmlvar vers les points de terminaison UsersWP"

Remarques :

  • La règle ci-dessus est un modèle — ajustez-la pour correspondre aux points de terminaison exacts de UsersWP sur votre installation.
  • Vous devez vous assurer que les formulaires légitimes ne sont pas bloqués (par exemple, si votre site utilise légitimement un htmlvar champ dans un flux sécurisé).

Règle de style WP-Firewall (conceptuelle) :

  • Bloquez toute demande aux points de terminaison UsersWP où :
    • Méthode HTTP = POST
    • Paramètre htmlvar soit présent
    • La session n'appartient pas à un utilisateur avec des capacités modifier_utilisateurs (ou est non authentifiée)
  • Action : Bloquer + enregistrer + alerter

Si vous exécutez un WAF géré, activer une signature de règle prête à l'emploi pour cette vulnérabilité est l'approche la plus rapide.

Comment durcir le code du plugin — conseils côté développeur

Si vous ou votre équipe de développement maintenez une copie du site (ou l'auteur du plugin), la bonne approche est :

  1. Ajouter des vérifications d'autorisation strictes :
    • Utilisez des vérifications de capacité WordPress : current_user_can( 'edit_user', $target_user_id ) avant de mettre à jour les usermeta pour un autre utilisateur.
    • Assurez-vous que seuls les utilisateurs ayant la capacité appropriée peuvent modifier des clés sensibles.
  2. Vérifiez les nonces lors des soumissions de formulaires et des appels AJAX :
    • Utiliser vérifier_admin_référent() ou wp_verify_nonce() selon ce qui est approprié pour les gestionnaires front-end/AJAX.
  3. Mettez sur liste blanche les clés méta autorisées :
    • Maintenez une liste explicite de clés méta qui peuvent être modifiées via des formulaires front-end. N'acceptez jamais des clés méta arbitraires provenant de l'entrée utilisateur.
  4. Assainissez et validez les valeurs :
    • Pour chaque clé méta autorisée, appliquez des routines d'assainissement et de validation appropriées. Ne rédigez pas aveuglément le HTML soumis dans la base de données.
  5. Évitez de permettre la modification des rôles/capacités via les usermeta :
    • N'acceptez jamais d'entrée pour changer wp_capabilities ou des clés méta définissant des rôles à partir de formulaires front-end.

Extrait de liste de contrôle PHP exemple (modèle sûr) :

function safe_userswp_update_user_meta( $user_id, $meta_key, $meta_value ) {
    // 1. Check nonce (assumes nonce name 'userswp_update_nonce' and field 'userswp_nonce')
    if ( ! isset( $_POST['userswp_nonce'] ) || ! wp_verify_nonce( $_POST['userswp_nonce'], 'userswp_update_nonce' ) ) {
        return new WP_Error( 'invalid_nonce', 'Invalid nonce' );
    }

    // 2. Capability check: only allow editing own profile or if current user can edit users
    $current = wp_get_current_user();
    if ( intval( $user_id ) !== $current->ID && ! current_user_can( 'edit_user', $user_id ) ) {
        return new WP_Error( 'not_allowed', 'You are not allowed to edit this user' );
    }

    // 3. Whitelist meta keys
    $allowed_meta_keys = array( 'first_name', 'last_name', 'description', 'twitter_handle' );
    if ( ! in_array( $meta_key, $allowed_meta_keys, true ) ) {
        return new WP_Error( 'meta_not_allowed', 'This meta key is not allowed' );
    }

    // 4. Sanitize value based on key
    $sanitized = sanitize_text_field( $meta_value );

    // 5. Update meta
    update_user_meta( $user_id, $meta_key, $sanitized );

    return true;
}

Ce modèle évite d'accepter des clés méta arbitraires et nécessite une autorisation appropriée et une vérification de nonce.

Conseils de détection — quoi auditer dès maintenant

Si vous évaluez si vous avez été ciblé, suivez ces étapes :

  • Audit de base de données :
    • Dump des usermeta pour une période récente et inspectez les clés inhabituelles ou les valeurs modifiées.
    • Vérifier meta_clé valeurs qui affectent les rôles ou les intégrations.
  • Journaux du serveur :
    • Recherchez des requêtes vers les points de terminaison UsersWP avec htmlvar présent. Regardez les cookies de session authentifiés et les IP.
  • Journaux WordPress :
    • Si vous avez une journalisation d'activité (plugin de piste d'audit ou journalisation WP-Firewall), recherchez les mises à jour de usermeta initiées par des comptes d'abonnés.
  • Revue du système de fichiers :
    • Recherchez des changements récents dans wp-content/uploads, les répertoires de plugins et les fichiers PHP inconnus dans les répertoires écrits.
  • Tâches planifiées :
    • Contrôler wp_options.option_name LIKE '%cron%' et wp-cron horaires pour des hooks et des rappels inattendus.

Créez une chronologie : corrélez toute requête HTTP suspecte avec des changements ultérieurs de usermeta ou de fichiers.

Réponse à l'incident : que faire si vous trouvez des changements malveillants

  1. Mettez le site en mode maintenance / restreignez temporairement l'accès si le site est activement compromis.
  2. Prenez un instantané de tout (base de données + fichiers) pour l'analyse judiciaire.
  3. Revenez à une sauvegarde propre avant l'incident si possible.
  4. Faites tourner les mots de passe pour les comptes affectés ; forcez la réinitialisation des mots de passe pour tous les administrateurs et éventuellement pour tous les utilisateurs si une persistance est suspectée.
  5. Révoquez et faites tourner toutes les clés API / jetons trouvés dans usermeta ou options.
  6. Supprimez la persistance : tous les comptes administrateurs inconnus, les tâches cron inattendues ou les fichiers malveillants.
  7. Appliquez le correctif / mettez à jour le plugin vers 1.2.59 ou une version ultérieure.
  8. Appliquez les règles WAF pour bloquer le vecteur d'attaque pendant que vous confirmez la remédiation complète.
  9. Re-scannez à la recherche de logiciels malveillants / portes dérobées et vérifiez l'intégrité des fichiers.
  10. Si vous ne pouvez pas supprimer complètement l'intrusion, envisagez de restaurer sur un hôte propre ou de demander une réponse professionnelle à l'incident.

Documentez chaque étape que vous prenez et conservez les journaux pour une analyse future.

Recommandations pratiques pour les opérateurs de site

  • Corrigez rapidement : Mettez à jour UsersWP vers 1.2.59 immédiatement. Les plugins sont un point d'entrée fréquent pour les attaquants - gardez-les à jour.
  • Testez les mises à jour d'abord en staging si vous gérez un site de production avec des intégrations personnalisées ; appliquez ensuite en production.
  • Activez l'hygiène des rôles :
    • Examinez régulièrement les comptes utilisateurs et supprimez les comptes inutilisés ou de test.
    • Limitez l'accès des abonnés aux API ou points de terminaison qui permettent des modifications au-delà des modifications de profil.
  • Utilisez un WAF avec des capacités de patching virtuel :
    • Bloquez les modèles d'exploitation pendant que vous testez et déployez des correctifs.
    • Configurez des règles qui tiennent compte des rôles ; bloquez les utilisateurs à faible privilège des points de terminaison à haut risque.
  • Appliquez des nonces et des capacités :
    • Les plugins et thèmes doivent toujours vérifier les nonces et current_user_can() avant de faire des modifications de la base de données.
  • Maintenir des journaux et des alertes :
    • Enregistrer les mises à jour des métadonnées utilisateur et alerter sur les changements inhabituels réduit le temps moyen de détection (MTTD).
  • Sauvegardes et récupération :
    • Maintenir des sauvegardes automatisées et testées qui incluent à la fois des fichiers et la base de données.
  • Tests de sécurité :
    • Scanner et auditer régulièrement votre site WordPress et ses plugins pour des vulnérabilités connues.
  • Principe du moindre privilège : Accorder uniquement aux utilisateurs les capacités dont ils ont besoin.

Scénarios d'exemple et analyse des risques (réaliste)

Scénario A — Défiguration de profil et spam :
Un abonné modifie son description ou bio avec des liens spam. Impact : principalement réputationnel, mais nuisible si le site permet que le contenu utilisateur soit indexé ou affiché publiquement. Récupération : revenir aux métadonnées et modérer le contenu.

Scénario B — Jeton d'intégration modifié :
Si le site stocke des jetons d'intégration dans les métadonnées utilisateur et qu'un attaquant les écrase, il peut accéder à des systèmes tiers. Impact : moyen à élevé (dépend de l'intégration). Récupération : faire tourner les jetons et auditer les journaux des tiers.

Scénario C — Tentative d'escalade de rôle :
Si le plugin permettait de définir wp_capabilities via des mises à jour de métadonnées (ce qui ne devrait pas être le cas), un attaquant pourrait essayer d'ajouter administrateur un rôle pour lui-même. Impact : élevé. Heureusement, dans de nombreuses configurations modernes, l'attribution de rôle est protégée par d'autres vérifications — mais vérifiez toujours. Récupération : supprimer les comptes indésirables, faire tourner les identifiants administratifs, restaurer à partir de la sauvegarde si nécessaire.

Même si la vulnérabilité est de faible gravité selon le CVSS, les scénarios B et C démontrent comment des problèmes en chaîne augmentent l'impact. Priorisez les atténuations qui réduisent ces chaînes (WAF + patching + rotation des jetons).

Comment prioriser cela dans votre registre des risques.

  • Très petits blogs sans enregistrements d'utilisateurs : Priorité basse — mettez à jour quand cela est pratique.
  • Sites d'adhésion, blogs multi-auteurs ou sites avec intégrations tierces : Priorité moyenne — appliquez le patch virtuel WAF et mettez à jour immédiatement.
  • Sites de commerce électronique, basés sur l'abonnement ou de grande valeur : Haute priorité — appliquez les mises à jour et le patch virtuel immédiatement ; effectuez un audit approfondi pour une éventuelle exploitation.

Si votre site accepte des enregistrements, traite les données de profil comme significatives, ou stocke des secrets d'intégration dans usermeta — agissez rapidement.

Une liste de contrôle pratique pour les prochaines 24 heures

  • Mettez à jour le plugin UsersWP vers 1.2.59.
  • Si vous ne pouvez pas mettre à jour maintenant, activez une règle WAF bloquant htmlvar les requêtes vers les points de terminaison UsersWP.
  • Audit usermeta pour des changements suspects au cours des 30 derniers jours.
  • Faites tourner tous les jetons ou identifiants stockés dans usermeta ou les options du plugin.
  • Appliquez des mots de passe forts et activez l'authentification à deux facteurs pour les comptes privilégiés.
  • Assurez-vous que les sauvegardes sont récentes et testées.
  • Activez ou examinez la journalisation des points de terminaison de mise à jour de profil et des changements dans usermeta.
  • Scannez les fichiers pour des fichiers PHP inattendus ou des fichiers de plugin/thème modifiés.

Cette liste de contrôle est actionnable et conçue pour réduire rapidement l'exposition. Le patch virtuel via WAF peut vous donner du temps pour tester en toute sécurité les mises à jour de plugins.

Protégez votre site instantanément — obtenez WP-Firewall Basic gratuitement

Si vous souhaitez une protection immédiate pendant que vous appliquez des correctifs et rattrapez les mises à jour, essayez le plan Basic (Gratuit) de WP-Firewall. Il comprend une protection essentielle : un pare-feu géré, une bande passante illimitée, des règles WAF, un scan de malware et une atténuation contre les risques OWASP Top 10. Inscrivez-vous au plan gratuit pour obtenir une couche gérée qui peut bloquer les tentatives d'exploitation comme celles ciblant le UsersWP htmlvar paramètre pendant que vous déployez la mise à jour du plugin : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Pour les équipes qui ont besoin de plus d'automatisation et d'une remédiation plus rapide, nos plans payants offrent un retrait automatique de malware, un blacklistage/whitelistage d'IP, des rapports de sécurité mensuels et un patch virtuel automatique — mais le plan Basic est un excellent point de départ sans coût pour améliorer immédiatement votre posture de sécurité.

Dernières réflexions — la défense en profondeur bat la panique de dernière minute.

Les vulnérabilités de contrôle d'accès brisé comme le UsersWP htmlvar sont un rappel que la sécurité est stratifiée : l'hygiène du code, des vérifications d'autorisation rigoureuses, des correctifs en temps opportun, le patching virtuel WAF et la surveillance se combinent pour protéger votre site. Faites d'abord les choses évidentes — mettez à jour les plugins, scannez et configurez une règle WAF — puis passez à des améliorations continues (audits de rôle, hygiène des jetons et journalisation).

Si vous souhaitez de l'aide pour évaluer l'exposition, déployer un patch virtuel ou configurer des protections WAF précises pour ce vecteur, l'équipe de WP-Firewall peut vous aider. Commencez par mettre à jour vers la version du plugin corrigée ; puis déployez une règle WAF pour bloquer htmlvar les motifs, auditez les usermeta et faites tourner les identifiants qui pourraient avoir été exposés.

Restez en sécurité et proactif — les petites étapes que vous prenez maintenant vous éviteront de gros maux de tête plus tard.

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™