Nom du plugin	Learnify
Type de vulnérabilité	Inclusion de fichiers locaux
Numéro CVE	CVE-2025-60085
Urgence	Haut
Date de publication du CVE	2026-04-25
URL source	CVE-2025-60085

Inclusion de Fichiers Locaux Critique dans le Thème Learnify (≤ 1.15.0) — Étapes Immédiates pour les Propriétaires de Sites WordPress

2026-04-25 | Équipe de Sécurité WP‑Firewall

Résumé

Une vulnérabilité critique d'Inclusion de Fichiers Locaux (LFI) a été divulguée dans le thème WordPress Learnify affectant les versions ≤ 1.15.0 (CVE-2025-60085). Le problème permet aux attaquants non authentifiés d'inclure et d'afficher des fichiers locaux depuis le serveur web. La vulnérabilité signalée a une gravité élevée (CVSS 8.1) et peut être exploitée à grande échelle — permettant aux attaquants de divulguer des fichiers sensibles tels que wp-config.php, des fichiers d'environnement, ou tout fichier lisible côté serveur. Cela peut entraîner la divulgation de données d'identification, la compromission de la base de données et la prise de contrôle complète du site en fonction de l'environnement.

Si vous utilisez Learnify ou des sites qui l'utilisent, lisez ce post attentivement. Nous expliquons ce que signifie la vulnérabilité, comment les attaquants en abusent, comment détecter des signes d'exploitation, et le processus de mitigation et de réponse aux incidents étape par étape que nous recommandons. Nous montrons également des règles WAF pratiques et des conseils de durcissement du serveur pour réduire immédiatement la surface d'attaque.

---

Qu'est-ce que l'inclusion de fichiers locaux (LFI) ?

L'Inclusion de Fichiers Locaux (LFI) est une classe de vulnérabilité dans les applications web qui se produit lorsque des entrées contrôlées par l'utilisateur sont utilisées pour sélectionner et inclure des fichiers sur le serveur sans validation appropriée. Dans un site basé sur PHP, par exemple, cela pourrait ressembler à :

• include($_GET['template']);
• require_once($_REQUEST['page']);

Si un attaquant peut contrôler l'entrée qui détermine quel fichier est inclus, il peut pointer l'application vers des fichiers locaux arbitraires et forcer le serveur à lire et à afficher leur contenu. Conséquences courantes :

• Divulgation de secrets (identifiants de base de données, clés API).
• Collecte d'informations pour préparer d'autres attaques.
• Dans les environnements qui permettent des wrappers dangereux (php://input, php://filter) ou où l'inclusion de fichiers distants est activée, l'exécution de code à distance (RCE) peut être possible.

LFI peut être exploité en utilisant des chaînes de traversée simples (../../../../) et des techniques de wrapper (php://filter) pour lire des fichiers en toute sécurité dans des contextes où l'inclusion directe ne permettra pas d'imprimer le contenu du fichier.

---

Pourquoi cette LFI Learnify est dangereuse

Faits clés concernant cet incident :

• Affecte les versions du thème Learnify ≤ 1.15.0.
• CVE : CVE-2025-60085.
• Privilège requis : aucun (non authentifié).
• CVSS : 8.1 (Élevé).
• Aucun correctif officiel du fournisseur n'est disponible pour le moment (les propriétaires de sites doivent appliquer des atténuations).

Pourquoi ce LFI particulier est un problème de haute priorité :

1. Non authentifié : Un attaquant n'a pas besoin de credentials pour tenter d'exploiter.
2. Facile à automatiser : Les vérifications LFI peuvent être effectuées par des scanners automatisés sur des milliers de sites.
3. Fichiers cibles sensibles : WordPress stocke les identifiants de base de données et les sels dans wp-config.php, ce qui rend ce fichier une cible privilégiée.
4. Chaînage : LFI peut être chaîné avec d'autres erreurs de configuration (permissions de fichiers faibles, répertoires de plugins/thèmes écrits, wrappers PHP dangereux) pour escalader vers RCE ou installation de backdoor persistante.

En raison de ces facteurs, les sites exécutant les versions vulnérables de Learnify doivent agir immédiatement.

---

Détails techniques (comment les attaquants exploitent généralement LFI)

Bien que le nom exact du paramètre vulnérable puisse varier entre les versions de thème, le schéma d'exploitation pour LFI suit des étapes communes. Ci-dessous, nous expliquons la méthode générale qu'un attaquant utiliserait — afin que vous puissiez la reconnaître et vous en défendre.

1. Trouver le point d'entrée
   – L'attaquant recherche des fichiers de thème qui appellent inclure, exiger, fichier_get_contents, ou des fonctions similaires avec des variables influencées par les valeurs GET/POST/cookie.
   – Exemple de schéma risqué : include( $theme_dir . '/' . $_GET['tpl'] );
2. Traversée de chemin
   – L'attaquant soumet des charges utiles contenant des séquences de traversée :
       – ../../../../etc/passwd
       – ../../../../wp-config.php
   – De nombreux serveurs empêchent la lecture de fichiers en renvoyant des erreurs lors de l'inclusion de fichiers binaires. Les attaquants utilisent alors des wrappers.
3. Utilisation de wrappers pour lire des fichiers (technique courante)
   – php://filter/convert.base64-encode/resource=path/to/file — applique un filtre pour encoder en base64 un fichier lorsqu'il est inclus, le rendant imprimable dans les réponses.
   – Exemple de charge utile :
       – ?tpl=php://filter/convert.base64-encode/resource=../../../../wp-config.php
4. Octet nul et astuces d'encodage
   – Sur les anciennes configurations PHP et serveur, les attaquants peuvent utiliser la troncature d'octet nul (%00) pour contourner les vérifications de suffixe. De nombreuses versions modernes atténuent cela, mais c'est toujours une charge utile courante dans les analyses automatisées :
       – ?tpl=../../../../wp-config.php
5. Étapes post-exploitation
   – Si les identifiants wp-config sont trouvés, l'attaquant les utilise pour accéder à la base de données ou pour créer un utilisateur administrateur, télécharger des portes dérobées ou exfiltrer des secrets supplémentaires.
   – Si les téléchargements de fichiers sont accessibles et non assainis, l'attaquant peut télécharger des shells PHP et obtenir un RCE.

Une divulgation responsable a noté que la logique d'inclusion du thème Learnify ne parvenait pas à assainir correctement les chemins fournis par l'utilisateur, permettant les techniques ci-dessus.

---

Indicateurs d'exemple et modèles de requêtes malveillantes à rechercher

Vérifiez vos journaux de serveur web et les journaux WAF pour des requêtes contenant ces modèles :

• php://filter/convert.base64-encode/resource=
• .... ou ../ répétées (traversée de chemin)
• %00 ou tentatives encodées en octet nul
• Requêtes vers des fichiers PHP de thème avec des chaînes de requête inhabituelles comme ?tpl=... ou ?page=... (vérifiez tout paramètre qui semble sélectionner un modèle)
• Longues chaînes base64 dans les réponses (indique que le contenu du fichier est encodé et renvoyé)

Ligne de demande suspecte d'exemple :

GET /wp-content/themes/learnify/somefile.php?template=php://filter/convert.base64-encode/resource=../../../../wp-config.php HTTP/1.1

Si vous voyez ce modèle, traitez-le comme une priorité élevée — isolez et enquêtez immédiatement.

---

Liste de contrôle des actions immédiates (que faire dans les premières heures)

Si vous exploitez un site utilisant Learnify ≤1.15.0, effectuez les actions suivantes immédiatement :

1. Mettez le site en mode maintenance (si possible) ou appliquez des contrôles d'accès temporaires (listes d'autorisation IP) pour réduire l'exposition.
2. Passez à un thème propre (par défaut de WordPress) ou retirez le thème vulnérable des répertoires accessibles au public. Ne laissez pas le thème vulnérable actif.
3. Si une version de thème corrigée est publiée, appliquez la mise à jour immédiatement. Si aucun correctif officiel n'existe encore, procédez avec les atténuations ci-dessous.
4. Mettez en place une règle WAF (patching virtuel) pour bloquer les demandes contenant des séquences de traversée ou des utilisations de wrapper (voir les règles d'exemple dans la section “Règles WAF”).
5. Changez le mot de passe de la base de données WordPress et toutes les informations d'identification de service qui peuvent être stockées dans wp-config.php et d'autres fichiers de configuration — mais seulement après avoir assuré des sauvegardes et des vérifications d'intégrité, car la compromission peut persister.
6. Faites tourner les clés secrètes et les sels dans wp-config.php après remédiation.
7. Scannez le site à la recherche de webshells, de fichiers suspects et de timestamps modifiés.
8. Restaurez à partir d'une sauvegarde propre vérifiée si vous détectez une compromission.
9. Augmentez la surveillance : activez la surveillance de l'intégrité des fichiers, les journaux d'audit et les alertes.

Si vous n'avez pas la capacité technique d'effectuer toutes les étapes, contactez votre fournisseur d'hébergement ou une équipe de sécurité et fournissez-leur les indicateurs que vous avez trouvés.

---

Comment détecter si votre site a été exploité

Même si vous fermez la vulnérabilité, vous devez vérifier si elle a été exploitée auparavant.

Vérifiez pour :

• Nouveaux fichiers ou fichiers modifiés dans wp-content/uploads, wp-content/thèmes, Contenu wp/plugins, ou d'autres emplacements inattendus.
• Nouveaux utilisateurs administrateurs dans WordPress (vérifiez utilisateurs_wp la table).
• Tâches planifiées suspectes (cron jobs) ou entrées cron non autorisées dans la base de données.
• Connexions sortantes du serveur vers des IP inconnues (vérifiez les journaux de pare-feu/hôte).
• Utilisation inattendue élevée du CPU/IO ou pics de trafic.
• Requêtes de base de données inhabituelles dans les journaux de requêtes lentes ou requêtes utilisant des comptes jamais vus auparavant.
• Fichiers PHP inconnus ou scripts encodés contenant évaluer, base64_decode, ou gzinflate.

Outils recommandés :

• Vérifications de l'intégrité des fichiers au niveau du serveur (style tripwire).
• Scanners de sécurité WordPress (préférez ceux qui fournissent une analyse au niveau du code et des heuristiques).
• Analyse complète des fichiers et du contenu de la base de données pour les malwares.
• Examen manuel des fichiers critiques (wp-config, .htaccess, index.php dans les dossiers de plugins/thèmes).

Si vous trouvez des preuves de compromission, suivez les étapes de réponse à l'incident dans la section suivante.

---

Réponse aux incidents : manuel étape par étape

Si vous confirmez l'exploitation, procédez comme suit :

1. Contenir
   – Mettez le site hors ligne ou bloquez le trafic pour éviter d'autres dommages.
   – Révoquez les identifiants et clés API compromis.
   – Isolez le serveur du réseau si possible.
2. Préserver les preuves
   – Sauvegardez les journaux (serveur web, base de données, journaux d'application) et les images disque.
   – Ne pas écraser les journaux — préservez les horodatages pour l'analyse judiciaire.
3. Éradiquer
   – Supprimez tous les backdoors, shells et scripts malveillants découverts.
   – Réinstallez le cœur de WordPress, les plugins et les thèmes à partir de sources propres.
   – Reconstruisez les serveurs à partir d'images si une persistance au niveau du serveur est suspectée.
4. Récupérer
   – Restaurer à partir d'une sauvegarde propre (prise avant le compromis).
   – Appliquer tous les correctifs de sécurité disponibles et les mesures de durcissement.
   – Changer tous les mots de passe et faire tourner les clés et les sels.
5. Post-récupération
   – Renforcer la surveillance et la journalisation.
   – Réaliser un post-mortem : comment le compromis a-t-il eu lieu ? Quels contrôles ont échoué ?
   – Éduquer l'équipe et mettre à jour votre plan de réponse aux incidents.
6. Notifier
   – Informer les parties prenantes, le fournisseur d'hébergement et, si nécessaire dans votre juridiction, les clients ou les régulateurs.

---

Recommandations de durcissement pour réduire le risque LFI

Même après une atténuation immédiate, adoptez ces défenses à long terme :

1. Principe du moindre privilège
   – Assurez-vous que les permissions de fichiers et de répertoires sont minimales. La plupart des fichiers WordPress devraient être lisibles par le serveur web mais pas modifiables, sauf wp-content/uploads qui nécessite un accès en écriture uniquement pour les téléchargements.
   – Les comptes de base de données utilisés par WordPress ne devraient avoir que les privilèges nécessaires.
2. Configuration PHP
   – Désactiver autoriser_inclusion_url.
   – Désactiver les wrappers inutilisés si possible.
   – Utilisez open_basedir pour restreindre l'accès de PHP aux répertoires.
   – Désactiver exécutif, shell_exec, passage, système si ce n'est pas nécessaire.
3. Désactiver l'éditeur de plugins et de thèmes intégré
   – Ajouter à wp-config.php:
   définir('DISALLOW_FILE_EDIT', vrai);
définir('DISALLOW_FILE_MODS', vrai); // restreint les installations/mises à jour de plugins/thèmes depuis l'administration WP
4. Téléchargements sécurisés
   – Empêcher l'exécution directe des fichiers PHP dans wp-content/uploads en ajoutant des règles serveur (voir l'exemple de bloc .htaccess/nginx ci-dessous).
5. Utilisez des sels et des clés forts et uniques (faites-les tourner lors de la remédiation)
   – Changer les clés invalidera les cookies d'authentification actifs — utile après un incident.
6. Sauvegardes régulières et tests de restauration
   – Conservez des sauvegardes fréquentes hors site et testez les restaurations régulièrement.
7. Utilisez des mises à niveau par étapes et une révision de code
   – Pour les thèmes/plugins en développement actif, examinez le code tiers ou restreignez l'utilisation jusqu'à ce que la posture de sécurité soit vérifiée.

---

Règles WAF pratiques et atténuations au niveau du serveur

Le patching virtuel (WAF) peut gagner du temps lorsqu'un patch officiel n'est pas encore disponible. Voici des règles d'exemple que vous pouvez utiliser dans des systèmes WAF courants ou comme contrôles au niveau du serveur web. Adaptez et testez soigneusement — des règles incorrectes peuvent bloquer le trafic légitime.

Détection de motifs importants à bloquer :

• Toute valeur de paramètre contenant php://filter
• Tout paramètre contenant plusieurs ../ séquences
• Tentatives de byte nul %00
• Tentatives d'inclure des fichiers avec des noms de fichiers sensibles (wp-config.php, .env, /etc/passwd)

Exemple de règle de style ModSecurity/Core Rule Language (CRS) :

# Block common LFI attack signatures
SecRule REQUEST_URI|ARGS|ARGS_NAMES|REQUEST_HEADERS "@rx (?i)((\.\./)|(\.\.\\)|php://filter|phpfilter||/etc/passwd|wp-config.php)" \
 "id:1009001,phase:1,deny,status:403,log,msg:'Potential LFI attempt blocked',severity:2,tag:'LFI',tag:'OWASP_TOP_10_A03'"

Règle basée sur la localisation Nginx pour interdire php://filter ou les tentatives de traversal :

if ($request_uri ~* "(php://filter||\.\./){1,}") {
 return 403;
}

Apache .htaccess extrait efficace pour bloquer l'exécution PHP dans les téléchargements :

# Protéger les téléchargements - empêcher l'exécution PHP

Une approche plus nuancée : bloquer uniquement les demandes suspectes, autoriser celles qui sont sûres. Tester les règles sur un environnement de staging avant de les appliquer en production.

---

Comment nous, chez WP‑Firewall, aidons (pare-feu géré + atténuation)

Chez WP‑Firewall, nous partons d'une hypothèse : des vulnérabilités seront découvertes dans les thèmes/plugins. La protection la plus rapide et la moins perturbante est le patching virtuel via un WAF géré qui bloque les tentatives d'exploitation en temps réel pendant que vous planifiez et appliquez des corrections permanentes.

Protections de base que nous fournissons et recommandons :

• Règles WAF gérées mises à jour automatiquement en réponse à de nouvelles divulgations — bloquer les charges utiles d'exploitation (php://filter, séquences de traversée, tentatives de récupération wp-config.php) avant qu'elles n'atteignent PHP.
• Analyse de logiciels malveillants et détection de signatures pour détecter les webshells et les modifications suspectes peu après une tentative d'exploitation.
• Surveillance de l'intégrité des fichiers et analyses quotidiennes pour détecter des changements de fichiers inattendus.
• Alertes d'incidents et support pour aider à trier les résultats et mettre en œuvre des atténuations.
• Capacité de patching virtuel afin que même si un thème n'a pas de patch officiel, vous puissiez continuer vos opérations tout en réduisant le risque.

Nous recommandons d'associer un patching virtuel immédiat avec les étapes de durcissement du serveur décrites ci-dessus, de faire tourner les identifiants et de mettre en œuvre une surveillance continue.

---

Exemples de regex de détection et conseils d'analyse de journaux

Surveillez les journaux du serveur web et mettez en œuvre des alertes sur ces modèles :

Regex (insensible à la casse) pour détecter les probes LFI probables :

(?i)(phpfilter|php://filter|(\.\./){2,}|(\.\.\\){2,}||wp-config\.php|/etc/passwd)

Entrées de journal déclenchant des alertes :

• GET /wp-content/themes/learnify/… ?…=php://filtre/convert.base64-encode/resource=../../../../wp-config.php
• Toute demande utilisant php:// enveloppes
• Demandes qui retournent 200 avec des chaînes encodées en base64 — le base64 dans les pages HTML est souvent un indicateur de lectures de contenu de fichiers.

Configurez un travail automatisé pour analyser les journaux quotidiennement pour ces modèles et notifier les administrateurs.

---

Exemple de test sûr pour vérifier la vulnérabilité (uniquement pour les propriétaires du site)

Si vous êtes le propriétaire du site et que vous devez tester si votre installation Learnify est vulnérable, suivez cette procédure de vérification sûre et en lecture seule. N'essayez pas d'exploiter les sites d'autres personnes.

1. Utilisez une requête non destructive php://filter qui tente simplement d'encoder en base64 un fichier reconnu (par exemple, readme.html dans le répertoire du thème).
2. Construisez une requête similaire à :

GET /wp-content/themes/learnify/index.php?tpl=php://filter/convert.base64-encode/resource=inc/readme.html

3. Si la réponse contient une chaîne base64 qui se décode en contenu de fichier, la fonction dans ce thème est vulnérable à un abus de modèle d'inclusion. Arrêtez les tests et passez à l'atténuation.

Important: Testez uniquement sur les sites que vous possédez ou gérez. Ne réalisez pas de tests sur des sites tiers.

---

Arbre de décision pour la remédiation : Mise à jour vs Atténuation temporaire vs Suppression

• Si un thème corrigé officiel est disponible : mettez à jour immédiatement, puis suivez la liste de vérification de vérification (scan d'intégrité des fichiers, rotations de mots de passe).
• S'il n'existe pas de correctif officiel :
  • Retirez le thème de l'utilisation active (passez à un thème par défaut).
  • Appliquez des règles WAF et des restrictions serveur pour bloquer les tentatives d'exploitation.
  • Travaillez avec le fournisseur de thème pour un calendrier ou envisagez de remplacer le thème par une alternative maintenue.
• Si vous ne pouvez pas retirer le thème pour des raisons commerciales :
  • Mettez le site derrière des contrôles d'accès stricts (liste blanche d'IP) pour l'accès administrateur.
  • Appliquez des règles WAF strictes et autorisez uniquement une fonctionnalité minimale.
  • Planifiez une surveillance dédiée et des scans d'intégrité fréquents.

---

Après remédiation : valider et surveiller

Après avoir appliqué des correctifs, validez votre environnement :

1. Relancez les scanners automatisés.
2. Vérifiez qu'aucun compte administrateur inattendu ou tâche planifiée n'est présent.
3. Vérifiez les connexions réseau inattendues ou les changements DNS.
4. Examinez les sauvegardes pour des indicateurs précoces de compromission (assurez-vous que les sauvegardes sont propres).
5. Continuez la surveillance accrue pendant au moins 30 jours après la remédiation.

---

Foire aux questions (FAQ)

Q : LFI peut-il conduire à une exécution de code à distance ?

R : LFI lui-même est une vulnérabilité d'inclusion/lecture de fichiers. L'exécution de code à distance peut être possible si l'attaquant peut inclure un fichier qu'il peut contrôler (par exemple, un fichier PHP téléchargé) ou enchaîner le LFI avec d'autres erreurs de configuration (répertoires écrits, wrappers dangereux ou plugins malveillants).

Q : Mon site utilise un thème enfant de Learnify — suis-je impacté ?

R : Possiblement. Les thèmes enfants héritent du code de base des thèmes parents. Si la logique vulnérable existe dans le code du thème parent et que le thème parent est Learnify ≤1.15.0, vous êtes probablement affecté. Vérifiez la version du thème parent et appliquez des mesures d'atténuation.

Q : J'ai corrigé le thème — dois-je encore faire tourner les identifiants ?

R : Oui. S'il y a une chance que le site ait été exposé, changez les clés, les mots de passe de la base de données et les jetons API utilisés sur le site. Le patchage empêche l'exploitation future mais ne supprime pas les compromissions qui se sont produites plus tôt.

Q : Comment puis-je être informé de vulnérabilités similaires à l'avenir ?

R : Abonnez-vous à un flux de sécurité de confiance et maintenez vos signatures WAF et vos scanners de logiciels malveillants à jour. Mettez en œuvre une surveillance automatisée des vulnérabilités pour les thèmes et plugins installés.

---

Commencez à protéger votre site aujourd'hui — Plan gratuit disponible

Si vous souhaitez une couche de protection immédiate et simple pendant que vous effectuez les étapes de remédiation technique ci-dessus, notre niveau gratuit géré fournit des défenses essentielles pour les sites WordPress. Le plan gratuit comprend un pare-feu géré avec patching virtuel, un pare-feu d'application web (WAF), un scan de logiciels malveillants, une protection contre la bande passante illimitée et une atténuation des risques OWASP Top 10. S'inscrire est simple et rapide — vous pouvez commencer à bloquer les tentatives d'exploitation en quelques minutes.

En savoir plus ou s'inscrire au plan gratuit ici

Options de mise à niveau : nous proposons également des plans payants abordables qui ajoutent la suppression automatique de logiciels malveillants, le blacklistage/whitelistage d'IP, des rapports de sécurité mensuels et des services gérés avancés pour les entreprises et les agences. Si vous gérez plusieurs sites ou avez besoin d'un support de remédiation actif, nos plans de niveau supérieur offrent une approche de sécurité complète et gérée.

---

Dernières réflexions des experts en sécurité WP‑Firewall

Cette divulgation LFI de Learnify est un rappel que tout thème ou plugin peut introduire des faiblesses critiques. Les aspects les plus importants de la réponse à des incidents comme celui-ci sont la rapidité et l'exhaustivité :

• Vitesse d'application des atténuations (patching virtuel et suppression temporaire).
• Exhaustivité dans l'enquête (l'attaquant a-t-il obtenu quelque chose ? Qu'est-ce qui a été accédé ?).
• Améliorations à long terme (durcissement, surveillance, moindre privilège).

Si vous avez besoin d'un partenaire capable de gérer le patching virtuel et de fournir une détection et une réponse continues pour votre flotte WordPress, les services gérés de WP‑Firewall sont conçus pour faire exactement cela : protéger le trafic en temps réel, scanner les indicateurs post-exploitation et vous aider à récupérer avec un minimum de perturbation des affaires.

Si vous gérez plusieurs sites WordPress, c'est le moment de revoir votre inventaire de thèmes, de confirmer les versions et d'appliquer les étapes ci-dessus. Si vous avez besoin d'aide pour trier des indicateurs spécifiques, nous publions des guides de remédiation détaillés et fournissons un support aux clients qui nécessitent une assistance accélérée. Restez vigilant et traitez toute sonde LFI comme potentiellement sérieuse : les attaquants automatisent ces vérifications, et un site exploitable est réellement à risque.

---

Annexe A : Liste de contrôle rapide (copier/coller)

• Identifier si Learnify ≤ 1.15.0 est installé.
• Passer à un thème différent ou désactiver Learnify.
• Appliquer des règles WAF pour bloquer les tentatives php://filter et de traversée de chemin.
• Scanner à la recherche de webshells et de modifications de fichiers non autorisées.
• Faire tourner les identifiants de la base de données et les sels WP.
• Restaurer à partir d'une sauvegarde propre si une compromission est détectée.
• Mettre en œuvre un durcissement des permissions de fichiers.
• Activez la surveillance et l'alerte de l'intégrité des fichiers.
• Surveiller les journaux pendant 30 jours après la remédiation.

---

Annexe B : Ressources et références supplémentaires

• CVE-2025-60085 (référence de l'avis public)
• Meilleures pratiques de durcissement PHP
• Manuel de sécurité WordPress (guide pour les administrateurs de site)
• Guide de réglage du WAF et de test des règles

(Si vous souhaitez de l'aide pour mettre en œuvre des règles WAF spécifiques ou effectuer un scan de vulnérabilité sécurisé sur votre environnement, notre équipe de sécurité chez WP‑Firewall peut vous assister. Nous offrons des options en libre-service et gérées adaptées aux sites de toutes tailles.)

---

Merci de prendre la sécurité au sérieux. Si vous avez des questions sur les étapes ci-dessus ou si vous souhaitez des conseils spécifiques à votre site, contactez le support de WP‑Firewall ou inscrivez-vous au plan gratuit pour obtenir une protection immédiate et gérée : https://my.wp-firewall.com/buy/wp-firewall-free-plan/