Avis d'injection SQL du plugin Amelia//Publié le 2026-04-01//CVE-2026-4668

ÉQUIPE DE SÉCURITÉ WP-FIREWALL

Amelia Vulnerability Image

Nom du plugin Amelia
Type de vulnérabilité Injection SQL
Numéro CVE CVE-2026-4668
Urgence Faible
Date de publication du CVE 2026-04-01
URL source CVE-2026-4668

Avis de sécurité urgent : injection SQL dans Amelia (≤ 2.1.2) — Comment protéger votre site WordPress maintenant

Auteur: Équipe de sécurité WP-Firewall
Date: 2026-04-01

Résumé court : Une vulnérabilité critique d'injection SQL (CVE-2026-4668) affectant les versions d'Amelia ≤ 2.1.2 permet à un utilisateur authentifié avec un rôle de niveau manager de manipuler un paramètre ‘sort’ d'une manière qui peut entraîner une injection SQL. Cet avis explique ce que cela signifie, le véritable risque pour votre site, comment les attaquants pourraient l'exploiter, comment détecter si vous avez été ciblé, et des conseils d'atténuation et de récupération étape par étape du point de vue d'un pare-feu WordPress et du renforcement.

Table des matières

  • Aperçu de la vulnérabilité
  • Pourquoi l'injection SQL est dangereuse pour les sites WordPress
  • Qui est à risque et le modèle de menace réaliste
  • Comment le problème fonctionne (technique mais non-exploitant)
  • Comment les attaquants pourraient obtenir un avantage (vecteurs d'attaque)
  • Étapes immédiates pour protéger votre site (atténuations urgentes)
  • Comment le WAF de WP‑Firewall et ses fonctionnalités gérées atténuent cette vulnérabilité
  • Règles et exemples pratiques de WAF que vous pouvez appliquer maintenant
  • Meilleures pratiques de renforcement au-delà du WAF
  • Détection, criminalistique et réponse si vous soupçonnez une compromission
  • Liste de contrôle de récupération et de remédiation
  • Recommandations de prévention continue et de politique
  • Commencez à protéger votre site maintenant — Détails du plan gratuit WP‑Firewall (inscription)
  • Notes finales et ressources

Aperçu de la vulnérabilité

Des chercheurs en sécurité ont signalé une vulnérabilité d'injection SQL affectant le plugin de réservation Amelia pour WordPress (versions jusqu'à et y compris 2.1.2). La vulnérabilité a été attribuée à CVE‑2026‑4668 et est classée comme un problème d'injection (OWASP A3). Elle implique spécifiquement un manager authentifié (ou un rôle personnalisé équivalent avec des privilèges similaires) capable de contrôler un paramètre sort paramètre utilisé dans une requête de base de données sans une sanitation suffisante.

Faits importants

  • Versions de plugin affectées : ≤ 2.1.2
  • Version corrigée : 2.1.3 (mettez à jour immédiatement)
  • Condition préalable à l'attaque : l'attaquant doit contrôler un compte avec des privilèges de niveau gestionnaire (ou un rôle personnalisé avec les mêmes capacités)
  • Classification : Injection SQL (OWASP A3)
  • Score de référence CVSS utilisé par les chercheurs : 8.5 (gravité élevée)
  • CVE : CVE‑2026‑4668

Bien que la vulnérabilité nécessite un compte gestionnaire authentifié, cela ne la rend pas inoffensive. Les comptes gestionnaires sont courants pour le personnel, les sous-traitants tiers, et parfois compromis par la réutilisation des identifiants ou le phishing. Pour de nombreux sites, le rôle de gestionnaire a de larges capacités et est une cible attrayante.


Pourquoi l'injection SQL est dangereuse pour les sites WordPress

Au cœur de l'injection SQL, cela permet à un attaquant de changer l'intention d'une requête de base de données en injectant des métacaractères SQL, des mots-clés ou des clauses là où l'application s'attend uniquement à des données. Les conséquences sur un site WordPress peuvent inclure :

  • Extraction de données sensibles : enregistrements d'utilisateurs, e-mails, mots de passe hachés, données personnalisées stockées dans des tables de plugins, et configuration privée.
  • Modification ou suppression de données : changer les rôles des utilisateurs, supprimer du contenu ou corrompre les données des plugins.
  • Mouvement latéral : si la base de données stocke des secrets (clés API, jetons OAuth), les attaquants peuvent les utiliser pour pivoter.
  • Exécution de code à distance dans des attaques en chaîne : dans certaines architectures, la capacité d'écrire dans le système de fichiers ou de créer de nouveaux utilisateurs administrateurs peut conduire à l'exécution de code côté serveur.
  • Compromission complète du site : les attaquants peuvent créer des comptes administrateurs, insérer des portes dérobées ou utiliser le site pour héberger du phishing/malware.

Même lorsqu'un exploit nécessite une authentification, l'impact reste sévère car les menaces à l'authentification (phishing, mots de passe réutilisés, compromission de sous-traitants) sont courantes.


Qui est à risque — modèle de menace réaliste

Vous devez considérer tout site exécutant les versions vulnérables du plugin Amelia comme potentiellement à risque si l'une des conditions suivantes est vraie :

  • Le site utilise Amelia ≤ 2.1.2.
  • Le site a des utilisateurs de niveau gestionnaire (ou un rôle personnalisé équivalent aux privilèges de gestionnaire).
  • Les comptes gestionnaires sont partagés, ont des mots de passe faibles ou réutilisés, ou manquent d'authentification multi-facteurs (MFA).
  • Le site accepte les inscriptions de gestionnaires invités (rare, mais possible dans des déploiements multisites ou personnalisés).
  • Les employés, sous-traitants ou intégrations tiers peuvent accéder aux comptes de niveau gestionnaire.

Même si votre site a peu de visiteurs, des campagnes d'exploitation de masse ciblent des milliers de sites, indépendamment du trafic. Une fois qu'un seul compte de gestionnaire est compromis, l'attaquant peut tenter l'injection.


Comment le problème fonctionne (explication technique, non-exploitative)

Selon les rapports de vulnérabilité, un paramètre d'entrée nommé paramètre sort (utilisé pour trier des listes ou des requêtes dans les écrans du gestionnaire de plugins) est passé dans une requête de base de données sans désinfection et/ou validation appropriées. Si ce paramètre est incorporé directement dans un SQL COMMANDER PAR clause ou d'autres fragments SQL, un attaquant ayant la capacité de définir paramètre sort pourrait insérer des fragments SQL supplémentaires.

Points clés à retenir (pas de code d'exploitation) :

  • La vulnérabilité est un échec de validation des entrées : le plugin devrait mettre en liste blanche les champs de tri autorisés ou valider strictement le paramètre, mais ce n'est pas le cas.
  • Parce que le paramètre est utilisé directement dans un contexte SQL, l'injection de jetons SQL peut altérer la logique de la requête.
  • Les privilèges requis réduisent mais n'éliminent pas le risque car des comptes avec le rôle requis existent largement.

Si vous êtes un développeur de plugin ou de thème, le bon modèle de défense est de ne jamais inclure d'entrées HTTP directement dans les instructions SQL. Utilisez toujours des listes blanches pour les noms de tri/champs ou paramétrez les requêtes lorsque cela est possible.


Comment les attaquants pourraient tirer parti de cette vulnérabilité

Un attaquant doit généralement atteindre l'une des préconditions suivantes :

  • Contrôler (ou compromettre) un compte de niveau gestionnaire.
  • Tromper un gestionnaire légitime pour qu'il clique sur un lien conçu tout en étant authentifié (attaque par lien stocké/conçu).
  • Exploiter d'autres vulnérabilités ou utiliser des identifiants volés pour obtenir un accès de gestionnaire.

Une fois que l'attaquant a accès au gestionnaire, les actions potentielles sont :

  • Exfiltrer des tables d'utilisateurs ou des tables de plugins qui stockent des données personnelles ou des configurations.
  • Modifier des enregistrements de base de données pour élever les privilèges ou créer des utilisateurs administrateurs persistants.
  • Corrompre ou supprimer les données de réservation et de rendez-vous qui peuvent avoir un impact direct sur les opérations commerciales.
  • Insérer du contenu malveillant ou des portes dérobées dans les paramètres stockés qui mènent ensuite à un compromis du back-end.

Les attaquants combinent souvent l'injection SQL avec d'autres techniques ; par exemple, utiliser l'injection SQL pour récupérer une clé API, puis appeler l'API pour créer un utilisateur administrateur ou télécharger un plugin.


Étapes immédiates pour protéger votre site (atténuations urgentes)

Appliquez ce qui suit dans cet ordre exact lorsque cela est possible. Priorisez d'abord les étapes rapides et réversibles.

  1. Mettez à jour le plugin vers la version corrigée (2.1.3) immédiatement.
    • C'est la seule solution permanente. Si vous pouvez mettre à jour maintenant, faites-le.
  2. Si vous ne pouvez pas mettre à jour immédiatement, désactivez temporairement le plugin Amelia.
    • Désactivez le plugin depuis l'administration WordPress ou via CLI : wp plugin désactiver ameliabooking
    • Si Amelia gère des réservations en direct et que vous ne pouvez pas désactiver, restreignez l'accès du gestionnaire (étapes ci-dessous).
  3. Auditez les comptes de gestionnaires et à privilèges élevés.
    • Forcez les réinitialisations de mot de passe pour tous les comptes de gestionnaires.
    • Appliquez ou activez l'authentification multifactorielle pour les comptes de gestionnaires et d'administrateurs.
    • Supprimez ou suspendez les comptes de gestionnaires inutilisés.
  4. Restreignez l'accès à la zone d'administration WordPress.
    • Limitez l'accès à wp-admin à une liste blanche d'IP de confiance en utilisant votre panneau de contrôle d'hébergement, la configuration du serveur web (.htaccess/nginx) ou une règle de pare-feu.
    • Si vous utilisez un fournisseur d'identité (SSO), assurez-vous que seuls les utilisateurs de confiance sont dans le groupe administrateur.
  5. Ajoutez des vérifications de capacité strictes.
    • Si vous exécutez des rôles personnalisés, vérifiez qu'ils n'héritent pas des capacités de niveau gestionnaire.
  6. Sauvegardez maintenant
    • Prenez une nouvelle sauvegarde complète (fichiers + DB) avant d'apporter des modifications ou des mises à jour majeures.
  7. Appliquez des règles WAF temporaires.
    • Utilisez un pare-feu d'application web pour bloquer les valeurs de paramètres suspectes paramètre sort (voir des exemples pratiques ci-dessous).
  8. journaux de surveillance
    • Surveillez les appels inhabituels aux points de terminaison qui acceptent paramètre sort ou les requêtes SQL inhabituelles dans les journaux de la base de données (journaux des requêtes lentes).

Ces étapes ferment les vecteurs d'attaque immédiats les plus courants pendant que vous organisez un correctif complet et un audit.


Comment le WAF de WP‑Firewall et ses fonctionnalités gérées atténuent cette vulnérabilité

Chez WP‑Firewall, nous concevons notre WAF et nos services gérés pour minimiser la fenêtre d'exposition et réduire le risque pendant que les propriétaires de sites appliquent des correctifs officiels. Voici comment nos couches aident :

  • Patching virtuel : nos ingénieurs en règles peuvent déployer un correctif virtuel qui intercepte et assainit ou bloque les valeurs de paramètres malveillantes paramètre sort pour les points de terminaison vulnérables. Cela réduit le risque même lorsqu'un plugin ne peut pas être mis à jour immédiatement.
  • Inspection ciblée des paramètres : plutôt que de bloquer de manière globale, le WAF peut inspecter uniquement le paramètre sort paramètre et appliquer des règles contextuelles pour bloquer les métacaractères SQL et les mots-clés suspects.
  • Application de la politique : nous recommandons et pouvons appliquer une liste blanche de champs de tri valides pour les points de terminaison du plugin, ce qui empêche le passage de champs inconnus.
  • Limitation des requêtes et détection des anomalies de comportement : des tentatives répétées de manipulation du même paramètre ou des séquences de requêtes inhabituelles déclenchent des blocages et des alertes.
  • Renforcement des comptes gérés : protections supplémentaires pour les comptes de gestion tels que l'application de l'authentification multifacteur, la liste blanche des adresses IP pour l'accès administrateur, et la surveillance de l'élévation temporaire.
  • Analyse et nettoyage des logiciels malveillants : si un attaquant exploite la vulnérabilité, le scanner aide à localiser le contenu injecté et les indicateurs de compromission (IOC).
  • Surveillance et alertes : surveillance continue des tentatives d'injection réussies ou bloquées, avec journaux et conseils de remédiation.

Si vous gérez un site WordPress en production et ne pouvez pas appliquer de correctif immédiatement, un WAF avec correctif virtuel est l'une des solutions d'atténuation les plus rapides et les plus efficaces.


Règles et exemples pratiques de WAF que vous pouvez appliquer maintenant

Voici des exemples défensifs que vous pouvez utiliser dans votre pare-feu (hôte, WAF de plugin ou passerelle centralisée). L'objectif est de bloquer les valeurs suspectes dans le paramètre sort paramètre tout en permettant des valeurs bénignes.

Important: ce sont des règles défensives pour réduire le risque. Ne comptez pas uniquement sur le WAF — mettez à jour le plugin comme solution principale.

  1. Règle pseudo-niveau élevé (logique)
    • Cible : toute demande aux points de terminaison utilisés par l'interface admin du plugin (où paramètre sort est acceptée).
    • Condition : paramètre de demande paramètre sort contient des jetons ou des mots-clés de contrôle SQL.
    • Action : bloquer la demande et alerter l'admin.
  2. Exemple de règle regex (serveur web ou WAF)
    (?i)(?:\b(select|union|insert|update|delete|drop|alter|truncate|exec|--|;)\b|[\'\"\`\(\)\x00])

    Explication:

    • (?i) = insensible à la casse
    • Correspond aux mots-clés SQL courants et aux caractères dangereux comme les guillemets, les accents graves, les parenthèses, le caractère de contrôle 0x00, les commentaires et le point-virgule.
    • Si vous inspectez uniquement le paramètre sort paramètre, cela réduit les faux positifs.
  3. Approche de liste blanche de champ (recommandée)
    • Extraire paramètre sort param et n'autoriser que les valeurs connues comme bonnes : par exemple. paramètre, titre, statut, créé_le, mis_à_jour_le.
    • Exemple de règle en pseudocode :
    allowed = ["date","titre","statut","créé_le","mis_à_jour","nom"]
    • Avantages : Bien plus sûr que de détecter des jetons malveillants ; la liste blanche n'autorise que les valeurs attendues.
  4. Limitation de taux et vérifications de session
    • Limiter le nombre de requêtes pouvant modifier les paramètres de requête par session ou par IP dans une petite fenêtre.
    • Si un compte de gestionnaire effectue soudainement des appels de tri répétés avec des valeurs suspectes, signalez-le.
  5. Bloquer l'utilisation directe de COMMANDER PAR dans les paramètres
    • Si le plugin s'attend uniquement à un nom de colonne, bloquez toute valeur contenant un espace ou des mots réservés SQL.
  6. Protéger les points de terminaison administratifs avec des vérifications supplémentaires
    • Ajouter une liste d'autorisation IP pour les pages administratives sensibles.
    • Exiger que des jetons MFA soient présents pour les requêtes pertinentes.

Si vous utilisez un WAF qui prend en charge l'inspection des paramètres d'URL ou le patching virtuel, demandez à votre fournisseur de créer une règle ciblant les points de terminaison administratifs d'Amelia et spécifiquement de nettoyer ou de bloquer paramètre sort Valeurs de paramètres suspectes.


Meilleures pratiques de renforcement au-delà du WAF

Bien que le WAF vous donne du temps, vous devriez renforcer votre site WordPress pour réduire la probabilité qu'un compte de gestionnaire soit compromis et pour réduire l'impact si une exploitation se produit.

  1. Principe du moindre privilège
    • Limiter les comptes de gestionnaire/admin uniquement à ceux qui en ont vraiment besoin.
    • Utiliser des rôles et des capacités granulaires ; éviter de donner des droits de niveau gestionnaire à plusieurs employés.
  2. Exiger l'authentification multi-facteurs
    • Exiger MFA pour tous les comptes élevés (gestionnaire/admin).
    • Utiliser des mots de passe à usage unique basés sur le temps (TOTP) ou des jetons matériels.
  3. Hygiène des mots de passe
    • Exiger des mots de passe forts et éviter les identifiants partagés.
    • S'intégrer à un gestionnaire de mots de passe et faire tourner les mots de passe après des événements suspects.
  4. Surveillance et alertes
    • Activez la journalisation des actions administratives et des requêtes DB inhabituelles.
    • Envoyez des alertes pour la création de nouveaux comptes administratifs, les changements de rôle et les connexions à privilèges élevés depuis de nouvelles adresses IP.
  5. Limitez l'accès à wp-admin
    • Mettez en liste blanche l'IP de la zone wp-admin si vous avez des adresses IP statiques.
    • Utilisez un VPN ou un SSO pour accéder aux zones administratives lorsque cela est pratique.
  6. Renforcement de la base de données
    • Utilisez un utilisateur de base de données qui a uniquement les privilèges nécessaires à WordPress. Évitez de donner des permissions larges sur le système de fichiers/base de données à l'utilisateur de la base de données.
    • Effectuez des sauvegardes régulières, stockez-les hors site et vérifiez les restaurations.
  7. Inventaire des plugins et politique de mise à jour
    • Maintenez un inventaire des plugins actifs et des versions.
    • Mettez en œuvre une politique de mise à jour pour les plugins et un processus de test/staging.
    • Évitez d'utiliser des plugins abandonnés ou des plugins qui ne suivent pas des modèles de codage sécurisés.
  8. Pratiques de développement (pour les auteurs de plugins/thèmes)
    • Toujours mettre en liste blanche les champs de tri et les noms de colonnes plutôt que l'interpolation brute.
    • Utilisez des instructions préparées et des requêtes paramétrées.
    • Nettoyez et validez toutes les entrées, pas seulement celles provenant de points de terminaison non authentifiés.

Détection, criminalistique et réponse si vous soupçonnez une compromission

Si vous soupçonnez que quelqu'un a exploité cette vulnérabilité sur votre site, traitez l'incident comme urgent et suivez les étapes suivantes dans l'ordre :

  1. Isolez et préservez
    • Si possible, mettez le site hors ligne ou placez-le en mode maintenance pour arrêter d'autres dommages.
    • Conservez les journaux (serveur web, application, DB) et les instantanés de fichiers pour une analyse judiciaire.
  2. Identifiez le vecteur
    • Recherchez des valeurs inhabituelles dans les journaux de requêtes (en particulier les valeurs passées à paramètre sort).
    • Recherchez dans les journaux de la base de données des SELECT, UNION ou écritures inattendues provenant de sessions administratives.
    • Examinez les journaux d'action de l'administrateur pour des changements de rôle inattendus ou de nouveaux comptes.
  3. Rotation des identifiants et des sessions
    • Forcez les réinitialisations de mot de passe pour tous les comptes de gestionnaire et d'administrateur.
    • Invalidez les sessions actives et les jetons API.
  4. Effectuez une analyse complète des logiciels malveillants et de l'intégrité.
    • Vérifiez les fichiers principaux modifiés, les plugins suspects, les nouveaux utilisateurs administrateurs ou les webshells.
    • Vérifiez les sommes de contrôle par rapport à une distribution WordPress propre et à des fichiers de plugins connus.
  5. Restaurez à partir d'une sauvegarde propre connue (si nécessaire).
    • Si l'intégrité des données est incertaine, restaurez à partir d'une sauvegarde effectuée avant la compromission suspectée.
    • Après la restauration, assurez-vous que le plugin vulnérable est mis à jour et que toutes les mesures de durcissement sont en place.
  6. Nettoyez et renforcez
    • Supprimez tous les utilisateurs, plugins ou fichiers suspects découverts lors de l'examen judiciaire.
    • Appliquez tous les correctifs et mettez en œuvre un patch virtuel WAF pendant l'enquête.
  7. Rapport et document
    • Enregistrez la chronologie, les indicateurs, les actions entreprises et contactez votre hébergeur ou fournisseur de sécurité pour obtenir de l'aide.
    • Si des données personnelles ont été exposées, consultez les exigences légales concernant les notifications de violation.
  8. Surveillance post-incident
    • Maintenez une surveillance accrue pendant des semaines après l'incident car les attaquants peuvent déployer des portes dérobées retardées.

Liste de contrôle de récupération et de remédiation (référence rapide).

  • Mettez à jour le plugin Amelia vers 2.1.3 (ou la dernière version).
  • Désactivez Amelia si vous ne pouvez pas mettre à jour immédiatement.
  • Forcez les réinitialisations de mot de passe et activez l'authentification multifactorielle pour les comptes de gestionnaire/admin.
  • Examinez et supprimez les rôles de gestionnaire inutilisés.
  • Appliquez un patch virtuel WAF pour bloquer les malveillants. paramètre sort Valeurs de paramètres suspectes.
  • Prenez et sécurisez une sauvegarde fraîche des fichiers + DB.
  • Scannez le site à la recherche de logiciels malveillants et de fichiers anormaux.
  • Examinez la base de données pour des entrées ou des modifications suspectes.
  • Faites tourner les clés API et les jetons stockés dans la DB ou les fichiers.
  • Vérifiez que tous les plugins et thèmes sont à jour et proviennent de sources réputées.
  • Mettez en œuvre le principe du moindre privilège pour les comptes utilisateurs de la DB.
  • Documentez les actions et préparez un rapport post-incident.

Recommandations de prévention continue et de politique

Cette vulnérabilité rappelle que les logiciels partout peuvent avoir des défauts. Réduisez le risque futur avec des politiques :

  • Appliquez un rythme de mise à jour strict pour les plugins avec une matrice de responsabilité (qui met à jour, quand).
  • Maintenez un inventaire des plugins montrant l'exposition et la criticité.
  • Exigez l'authentification multi-facteurs pour tous les comptes WordPress élevés.
  • Utilisez une authentification forte, un système d'authentification unique (SSO) et des contrôles d'identité centralisés pour les équipes.
  • Utilisez une approche de sécurité en couches : WAF + gestion des correctifs + sauvegardes + surveillance.
  • Effectuez périodiquement des tests de pénétration et des revues de code pour les plugins personnalisés.

Commencez à protéger votre site maintenant — Plan gratuit WP‑Firewall (Facile à démarrer)

Titre du plan disponible : Secure Starter — WP‑Firewall Basic (Gratuit)

Si vous souhaitez un moyen immédiat et facile d'ajouter une couche de protection pendant que vous corrigez et renforcez votre site, le plan Basic gratuit de WP‑Firewall peut vous aider. Il comprend une protection essentielle de pare-feu gérée, le WAF, un scan de logiciels malveillants, une bande passante illimitée et une atténuation axée sur le Top 10 de l'OWASP — tout ce dont vous avez besoin pour arrêter rapidement de nombreuses attaques automatiques et opportunistes sans frais.

Pourquoi le plan Basic aide maintenant

  • WAF géré : Nous pouvons déployer des règles qui examinent et bloquent les comportements suspects. paramètre sort valeurs de paramètres pour les points de terminaison administratifs.
  • Analyseur de logiciels malveillants : Détecte les fichiers d'artefacts post-exploitation ajoutés par les attaquants.
  • Les 10 principales mesures d'atténuation selon l'OWASP : Protège contre les risques courants d'injection et de contrôle d'accès pendant que vous appliquez des correctifs.

Inscrivez-vous et protégez votre site avec le plan de base gratuit ici :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si vous avez besoin de niveaux plus élevés de remédiation automatisée ou de correctifs virtuels, nos plans Standard et Pro offrent la suppression automatique des logiciels malveillants, le blacklistage/whitelistage des IP, des rapports de sécurité mensuels et des correctifs virtuels automatiques — tous conçus pour réduire les risques et la charge administrative.)


Notes finales et ressources

Pour résumer :

  • Mettez à jour Amelia vers 2.1.3 immédiatement — c'est la solution définitive.
  • Si vous ne pouvez pas mettre à jour tout de suite, mettez le plugin hors ligne ou renforcez l'accès aux fonctionnalités de niveau gestionnaire.
  • Utilisez un WAF qui peut appliquer un correctif virtuel au paramètre sort paramètre (de préférence basé sur la liste blanche).
  • Renforcez les comptes, appliquez l'authentification multifacteur, faites tourner les identifiants et conservez des sauvegardes.

Si vous souhaitez une aide directe pour mettre en œuvre des règles WAF d'urgence, effectuer un nettoyage de site ou confirmer si votre site présente des indicateurs de compromission, notre équipe de sécurité est disponible pour aider avec la réponse aux incidents et la protection gérée.

Restez en sécurité et considérez cet avis comme une tâche de maintenance urgente — plus vous appliquez des correctifs et renforcez, plus votre risque est faible.

— Équipe de sécurité WP-Firewall


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.