| Nom du plugin | FluentForm |
|---|---|
| Type de vulnérabilité | Référence d'objet directe non sécurisée (IDOR) |
| Numéro CVE | CVE-2026-5395 |
| Urgence | Haut |
| Date de publication du CVE | 2026-05-17 |
| URL source | CVE-2026-5395 |
IDOR dans FluentForm (CVE-2026-5395) : Ce que les propriétaires de sites WordPress doivent faire maintenant
Une vulnérabilité récemment divulguée de référence d'objet direct non sécurisé (IDOR) affectant les versions de FluentForm jusqu'à et y compris 6.2.0 (CVE-2026-5395) mérite l'attention de chaque propriétaire de site WordPress qui accepte des comptes utilisateurs ou utilise ce plugin de formulaire populaire. Bien que l'exploitation nécessite un compte authentifié de bas niveau (abonné), de nombreux sites WordPress réels permettent l'enregistrement des utilisateurs — et cela peut rendre un IDOR étonnamment pratique à abuser à grande échelle.
Dans cet article, nous expliquons, en termes simples, ce qu'est cette vulnérabilité, pourquoi elle est importante même lorsqu'un compte d'abonné est requis, comment détecter les tentatives d'abus, et — le plus important — quelles mesures d'atténuation immédiates et pratiques vous pouvez appliquer dès aujourd'hui. Nous montrerons également comment WP‑Firewall peut protéger votre site (y compris notre plan gratuit), et fournir une liste de contrôle claire pour la réponse aux incidents si vous soupçonnez un compromis.
Remarque : Si vous utilisez FluentForm sur votre site, mettez-le à jour immédiatement vers la version corrigée (6.2.1 ou ultérieure). Si vous ne pouvez pas mettre à jour pour des raisons opérationnelles, suivez les étapes d'atténuation ci-dessous pour réduire l'exposition.
Résumé (TL;DR)
- Vulnérabilité : Références d'objet direct non sécurisé (IDOR) dans FluentForm <= 6.2.0 (CVE-2026-5395).
- Ce que cela permet : Un utilisateur authentifié avec un accès de niveau abonné peut être en mesure d'accéder ou d'interagir avec des objets (entrées de formulaire, exports, téléchargements ou métadonnées de formulaire) qui devraient être restreints.
- Facteurs de risque : Les sites qui permettent l'enregistrement des utilisateurs, acceptent les contributions de la communauté ou intègrent des formulaires avec des flux de travail sensibles ont une exposition accrue.
- Actions immédiates : Mettez à jour FluentForm vers 6.2.1+, restreignez ou désactivez l'enregistrement des utilisateurs si possible, et mettez en œuvre un patch virtuel avec un pare-feu d'application Web (WAF).
- À long terme : Appliquez le principe du moindre privilège pour les rôles, renforcez les points de terminaison REST et AJAX, adoptez le durcissement des rôles, et surveillez les journaux pour une activité suspecte.
Qu'est-ce qu'un IDOR et pourquoi est-il dangereux ?
Une référence d'objet direct non sécurisé (IDOR) se produit lorsqu'une application utilise des identifiants fournis par l'utilisateur (IDs) pour accéder à des objets internes — tels que des enregistrements de base de données, des fichiers ou des ressources — sans effectuer de vérifications d'autorisation suffisantes. Au lieu de vérifier que l'utilisateur authentifié est réellement autorisé à accéder à l'objet demandé, l'application fait confiance à l'ID de l'utilisateur et retourne l'objet.
Pourquoi c'est dangereux :
- Les IDOR permettent aux attaquants d'accéder à des données qu'ils ne devraient pas voir simplement en changeant une valeur d'ID dans une requête. Par exemple, si vous pouvez récupérer la soumission #123 en visitant /api/get_entry?id=123, vous pourriez essayer /api/get_entry?id=124 et voir les données de quelqu'un d'autre.
- L'impact varie des fuites de confidentialité à la manipulation complète des données en fonction des objets exposés et de ce que l'application permet.
- Dans les écosystèmes de plugins WordPress, les IDOR apparaissent souvent dans les points de terminaison REST/HTTP et les gestionnaires AJAX où les développeurs oublient de vérifier les capacités ou la propriété.
Parce que les IDOR reposent sur une autorisation manquante plutôt que sur une rupture de l'authentification ou l'injection de code, ils peuvent être subtils à détecter lors des revues de code et peuvent rester inaperçus pendant de longues périodes.
Détails du problème de FluentForm (niveau élevé)
Résumé de l'avis public :
- Une vulnérabilité classée comme IDOR affecte les versions de FluentForm jusqu'à 6.2.0.
- Le problème a été attribué à CVE-2026-5395 et corrigé dans la version 6.2.1.
- La vulnérabilité nécessite un compte authentifié de niveau abonné pour être exploitée (c'est-à-dire que quiconque ayant un compte de site de base peut essayer).
Ce que cela signifie probablement en pratique :
- Certains points de terminaison de FluentForm permettaient l'accès aux ressources par ID sans vérifications suffisantes de capacité ou de propriété.
- Un abonné pouvait énumérer ou demander des ID d'objet (pour les soumissions de formulaires, les fichiers, les exports, etc.) et récupérer ou interagir autrement avec des ressources auxquelles il ne devrait pas avoir accès.
- Selon la manière dont le plugin stocke les pièces jointes (par exemple, les fichiers téléchargés accessibles via des URL directes) et comment les entrées sont retournées, une exploitation réussie peut conduire à l'exposition de données sensibles incluses dans les soumissions de formulaires.
Nous évitons délibérément de reproduire le code d'exploitation ici. L'objectif est d'informer, pas de permettre des abus. Si votre site utilise FluentForm, considérez cela comme une urgence actionable : planifiez une mise à jour et appliquez des correctifs virtuels si une mise à jour immédiate n'est pas possible.
Quelle est la gravité de cela pour votre site ?
La gravité dépend de quelques facteurs pratiques :
- Configuration du site : Si vous autorisez l'enregistrement ouvert des utilisateurs ou si vous avez une communauté comprenant de nombreux comptes abonnés, votre exposition augmente. Les attaquants peuvent créer des comptes et sonder les points de terminaison.
- Types de formulaires : Les formulaires critiques pour l'entreprise (candidatures, formulaires de contact avec des PII sensibles, rappels de paiement, champs de téléchargement de fichiers) présentent un risque élevé si les entrées ou les pièces jointes sont exposées.
- Intégrations de plugins supplémentaires : Si les soumissions de formulaires sont transférées par email, CRM, ou stockées contenant des clés API ou des données privées, un IDOR peut fuir ces éléments sensibles.
- Complexité de l'attaque : Parce que l'exploitation nécessite un compte abonné, un abus automatisé à grande échelle est possible où de faux comptes sont facilement créés. Certains sites bloquent l'enregistrement ou vérifient les utilisateurs, ce qui réduit le risque.
En résumé : si votre site accepte les enregistrements d'utilisateurs ou si vous utilisez FluentForm pour collecter tout type de données personnelles, considérez cela comme une mise à jour de haute priorité.
Liste de contrôle de remédiation immédiate (que faire dès maintenant)
Si vous hébergez des sites WordPress, effectuez ces actions dans l'ordre ci-dessous. Priorisez les sites qui acceptent l'enregistrement des utilisateurs ou où les formulaires collectent des PII.
- Mettez à jour FluentForm
– Le fournisseur a publié la version 6.2.1 corrigeant ce problème. Mettez à jour vers 6.2.1 ou une version ultérieure immédiatement sur tous les sites affectés. Testez les mises à jour en staging si possible, puis déployez en production. - Si vous ne pouvez pas mettre à jour immédiatement
– Désactivez temporairement le plugin FluentForm jusqu'à ce que vous puissiez appliquer un correctif.
– Désactivez l'enregistrement ouvert des utilisateurs via l'administration WordPress : Réglages → Général → Adhésion (décochez “Tout le monde peut s'inscrire”).
– Restreindre l'accès aux points de terminaison de plugin connus en utilisant votre WAF (patch virtuel) ou les règles de votre serveur web (voir la section suivante). - Appliquer des patches virtuels WAF
– Configurer les règles WAF pour :
– Bloquer la manipulation suspecte des paramètres (par exemple, tentatives d'accès aux entrées en devinant des ID).
– Bloquer l'accès direct aux points de terminaison de plugin pour les demandes de niveau abonné qui tentent des ID ou des méthodes d'objet inhabituels.
– Limiter le taux des demandes aux points de terminaison pertinents pour limiter l'énumération. - Audit des comptes d'utilisateurs
– Supprimer ou restreindre tout compte abonné inutile.
– Verrouiller les comptes compromis ou suspects en forçant les réinitialisations de mot de passe.
– Ajouter une authentification à deux facteurs pour les comptes à privilèges élevés (administrateurs, éditeurs). - Surveiller les journaux et les indicateurs
– Rechercher des pics dans les demandes aux points de terminaison FluentForm, en particulier avec différents paramètres id.
– Examiner les journaux d'accès pour des réponses 200 répétées aux demandes GET/POST contenant des paramètres de requête comme id= ou entry_id=.
– Vérifier les téléchargements de fichiers inhabituels à partir des répertoires de téléchargement. - Sauvegardes et détection
– Assurez-vous d'avoir une sauvegarde récente avant de mettre à jour ou de prendre des mesures de remédiation.
– Effectuer une analyse complète du site avec votre scanner de logiciels malveillants après la mise à jour pour s'assurer qu'aucune modification persistante n'a été effectuée.
Comment WP‑Firewall aide (protection gérée et patching virtuel)
WP‑Firewall fournit plusieurs couches de défense qui sont efficaces contre des vulnérabilités comme cet IDOR :
- Règles WAF gérées : Nous pouvons déployer des patches virtuels qui bloquent ou filtrent les modèles d'exploitation avant qu'ils n'atteignent le code du plugin. Par exemple, des règles peuvent refuser les demandes d'utilisateurs authentifiés tentant d'énumérer des ID ou d'accéder à des points de terminaison de niveau administrateur en utilisant des identifiants d'abonné.
- Les 10 principales mesures d'atténuation selon l'OWASP : Le jeu de règles de WP‑Firewall aborde les classes courantes de contrôle d'accès et d'injection, aidant à réduire la surface d'exploitation même lorsqu'un plugin présente un défaut logique.
- Analyseur de logiciels malveillants et atténuation : Si une vulnérabilité a été exploitée, le scanner de WP‑Firewall peut identifier les fichiers et modifications suspects et les mettre en quarantaine ou les signaler pour examen.
- Protection avec un minimum de friction : Les règles de pare-feu gérées peuvent être déployées rapidement et temporairement lorsqu'un correctif d'urgence est nécessaire et avant que le plugin puisse être mis à jour.
Si vous gérez plusieurs sites, ces contrôles vous permettent de réagir rapidement : bloquer les tentatives d'exploitation, surveiller et mettre à jour selon votre propre calendrier.
Règles WAF recommandées et modèles de correctifs virtuels (guidance conceptuelle)
Ci-dessous se trouvent des modèles de règles conceptuelles que vous pouvez appliquer (implémentés dans votre WAF ou via WP‑Firewall) :
- Bloquer l'énumération basée sur les paramètres :
- Refuser ou limiter les demandes qui présentent des ID numériques séquentiels à un taux élevé depuis la même IP ou compte utilisateur.
- Exiger la présence de nonces valides ou d'en-têtes de capacité pour les points de terminaison qui accèdent aux entrées de formulaire.
- Appliquer l'accès aux points de terminaison basé sur les rôles :
- Bloquer les demandes aux points de terminaison d'exportation d'entrées de formulaire si le rôle du demandeur est abonné.
- Retourner 403 aux rôles non autorisés plutôt que 404/200 pour réduire les fuites d'informations.
- Valider le type de contenu et la méthode HTTP :
- Restreindre les points de terminaison aux méthodes HTTP attendues (par exemple, uniquement POST) et bloquer les méthodes incorrectes qui pourraient divulguer des données.
- Contrôles d'accès aux fichiers :
- Empêcher le téléchargement direct des pièces jointes téléchargées depuis des dossiers gérés par le plugin, sauf si la demande de service a un contrôle de capacité ou un jeton valide.
- Bloquer le hotlinking vers des fichiers téléchargés depuis des référents non fiables si le formulaire stocke des pièces jointes publiquement.
Vous devriez travailler avec votre équipe de sécurité pour traduire ces modèles en règles WAF précises. Si vous utilisez WP‑Firewall, nos analystes peuvent appliquer des correctifs virtuels pour vous pendant que vous préparez la mise à jour du plugin.
Détection des signes d'exploitation (ce qu'il faut rechercher)
Si vous soupçonnez que le site a été sondé ou exploité, recherchez :
- Des modèles de requêtes inhabituels contre les points de terminaison FluentForm :
- Un volume élevé de requêtes vers des points de terminaison avec des paramètres id, entry_id ou form_id.
- Des requêtes qui varient uniquement par ID numérique (indicatif d'énumération).
- De nouveaux comptes d'abonnés ou suspects :
- Plusieurs comptes créés dans une courte période, en particulier avec des modèles similaires (domaines d'email comme mailinator, noms d'utilisateur séquentiels).
- Indicateurs d'exfiltration de données :
- Pic d'activité d'email sortant (si les soumissions de formulaires sont transférées).
- Accès aux entrées de formulaire suivi de connexions réseau externes (recherchez des scripts ou des tâches planifiées).
- Téléchargements de fichiers inattendus à partir de répertoires de téléchargements ou de plugins :
- Vérifiez les journaux d'accès pour des réponses 200 aux requêtes de noms de fichiers d'attachement qui se produisent rarement.
- Signes de modifications post-exploitation :
- Utilisateurs administrateurs inattendus, thèmes/plugins modifiés, tâches cron inconnues ou fichiers PHP dans les téléchargements.
Si vous constatez des preuves de compromission, suivez les étapes de réponse aux incidents ci-dessous.
Liste de contrôle en cas d'incident (si vous soupçonnez une exploitation)
- Isolez le(s) site(s) affecté(s)
– Mettez le site en mode maintenance ou isolez-le du trafic public pendant que vous enquêtez.
– Si vous hébergez plusieurs sites sur le même serveur, envisagez d'isoler par IP, répertoire ou conteneur. - Conserver les bûches
– Exportez les journaux d'accès du serveur web, les journaux d'application et les journaux de base de données pour l'analyse judiciaire.
– Ne videz pas les journaux prématurément ; ceux-ci sont essentiels pour déterminer l'étendue. - Modifier les identifiants
– Réinitialisez les mots de passe administratifs et les identifiants de base de données.
– Faites tourner toutes les clés API ou jetons qui ont été utilisés par des formulaires ou des intégrations tierces. - Scannez pour la persistance et les portes dérobées.
– Utilisez un scanner de confiance pour détecter les fichiers modifiés et les modèles de porte dérobée connus.
– Examinez manuellement les dossiers critiques (thèmes, mu-plugins, uploads) pour des fichiers PHP ou des fichiers inattendus. - Restaurer à partir de sauvegardes propres si nécessaire
– Si le site est fortement compromis, restaurez à partir d'une sauvegarde effectuée avant l'incident.
– Après la restauration, appliquez des mises à jour et un durcissement avant de réactiver l'accès public. - Informez les parties prenantes et respectez les exigences en matière de confidentialité.
– Si des PII ont été exposées, suivez la politique de notification des violations de votre organisation et les exigences légales pertinentes. - Renforcez et surveillez après l'incident
– Appliquez les règles WAF recommandées, mettez à jour FluentForm et surveillez les tentatives répétées.
– Activez la journalisation et les alertes automatisées pour les modèles d'accès suspects.
Si vous utilisez les services gérés de WP‑Firewall, nous pouvons vous aider à contenir, nettoyer et protéger le site pendant que vous restaurez.
Meilleures pratiques de durcissement pour réduire l'exposition future aux IDOR.
Les IDOR sont un problème de logique et d'autorisation, donc au-delà de la correction d'un plugin, vous devriez adopter des mesures de durcissement systémique :
- Principe du moindre privilège :
- Ne donnez aux utilisateurs que les capacités dont ils ont besoin. De nombreux plugins ajoutent des points de terminaison qui supposent que les utilisateurs authentifiés sont dignes de confiance — réduisez cette confiance.
- Utilisez des plugins de gestion des rôles pour personnaliser ce qu'un abonné peut (et plus important, ne peut pas) faire.
- Examinez et restreignez les points de terminaison REST et AJAX :
- Auditez vos plugins pour découvrir les points de terminaison publics et assurez-vous qu'ils vérifient current_user_can() ou la propriété appropriée avant de renvoyer des données.
- Désactivez ou protégez les répertoires de téléchargement de plugins :
- Vérifiez que les pièces jointes téléchargées sont stockées en toute sécurité et servies par un contrôle d'accès, et non comme des URL devinables publiquement.
- Limitez l'enregistrement ouvert :
- Si vous n'avez pas besoin que des utilisateurs anonymes aient des comptes, désactivez l'enregistrement ouvert.
- Utilisez CAPTCHA ou vérification par e-mail pour relever le niveau de création de comptes en masse.
- Surveillez la création et l'activité des utilisateurs :
- Configurez des alertes pour la création de comptes en masse ou l'activité anormale des abonnés.
- Limitez le taux d'actions comme “ voir l'entrée ” ou “ exporter ” pour les utilisateurs authentifiés.
- Utilisez un cycle de mise à jour en plusieurs étapes et testé :
- Testez les mises à jour dans un environnement de staging ou local avant de les déployer en production. Utilisez des sauvegardes et un plan de retour en arrière.
- Gardez les plugins au minimum :
- Désinstallez les plugins inutilisés. Chaque plugin est un code supplémentaire qui pourrait contenir des défauts logiques.
Comment tester que vous n'êtes plus vulnérable
Après avoir mis à jour vers FluentForm 6.2.1 ou une version ultérieure et appliqué les règles WAF :
- Vérifiez la version du plugin
– Confirmez dans l'administration WordPress que FluentForm est mis à jour vers 6.2.1+. - Testez en préproduction
– Recréez les conditions (un compte abonné) et tentez des flux de travail normaux du plugin pour vous assurer qu'aucune fonctionnalité légitime n'est bloquée. - Vérifiez les journaux pour les tentatives bloquées
– Le WAF devrait montrer les tentatives bloquées ou limitées qui correspondent aux anciens modèles de vulnérabilité. - Exécutez une analyse de sécurité
– Utilisez le scanner de logiciels malveillants WP‑Firewall et d'autres outils de scan pour inspecter les fichiers suspects et les anomalies. - Passez en revue les comptes utilisateurs et les entrées de formulaire
– Assurez-vous qu'il n'y a pas d'accès non autorisé ou d'exportations d'entrées de formulaire.
Si vous n'êtes pas sûr d'avoir atténué le problème avec succès, le service géré de WP‑Firewall peut auditer votre site et appliquer des règles de protection.
FAQ : Questions courantes des propriétaires de sites
Q : Si un attaquant a seulement besoin d'un compte abonné, à quel point cela est-il grave ?
R : Cela peut être significatif. De nombreux sites permettent des abonnements pour des commentaires, des newsletters ou du contenu protégé. Les attaquants utilisent souvent des e-mails jetables pour créer des comptes en masse, puis utilisent des outils automatisés pour rechercher des IDOR et énumérer des ID. Si vos formulaires collectent des PII, des fichiers ou des secrets, ces données pourraient être en danger.
Q : La désactivation de l'enregistrement des utilisateurs résoudra-t-elle ce problème ?
A : Cela réduit le risque, car cela élève la barrière pour les attaquants. Cependant, si des comptes d'abonnés valides existent déjà, ou si les attaquants trouvent des moyens de télécharger des données via d'autres intégrations, des protections supplémentaires sont toujours nécessaires.
Q : Est-il suffisant de s'appuyer sur des protections au niveau du serveur (comme les téléchargements privés) ?
A : Les protections au niveau du serveur aident. Mais l'approche la plus robuste est une défense en couches : corriger le plugin, appliquer des vérifications de capacité et utiliser un WAF pour arrêter les tentatives d'exploitation avant qu'elles n'atteignent l'application.
Q : Dois-je supprimer les anciennes entrées de formulaire ?
A : Supprimez uniquement si elles sont connues pour être compromises ou contiennent des informations sensibles inutiles. Conservez des sauvegardes et suivez votre politique de conservation des données. Assainissez ou censurez les PII si elles ne sont plus nécessaires.
Exemple de vérifications de capacité que les auteurs de plugins devraient utiliser (conceptuel)
Le code du plugin gérant l'accès aux objets doit vérifier à la fois l'authentification et la propriété/capacités. En pseudo-code PHP WordPress, un modèle de vérification robuste inclut :
- Vérification des nonces pour AJAX ou REST
- Vérification de current_user_can() pour la bonne capacité
- S'assurer que l'utilisateur actuel possède l'objet ou a une capacité privilégiée
(Nous omettons les noms d'endpoints vulnérables spécifiques et évitons de donner des détails de reproduction. Les développeurs devraient appliquer ces vérifications à tous les endpoints de plugin qui acceptent un ID d'objet d'un utilisateur.)
Pourquoi un WAF est essentiel dans votre pile de sécurité
Un pare-feu d'application Web (WAF) complète le patching en fournissant :
- Patching virtuel : blocage immédiat des modèles d'exploitation pendant que vous préparez et testez les mises à jour de code.
- Limitation de débit : empêche l'énumération massive et les tentatives de devinette d'ID par force brute.
- Protection pour les endpoints qui sont difficiles à changer rapidement : parfois, un plugin est critique pour les flux de travail commerciaux et ne peut pas être désactivé immédiatement — un WAF achète du temps.
- Journalisation et renseignement sur les menaces : combinés avec la surveillance, les journaux WAF vous aident à repérer les tentatives de scan et d'exploitation suspectes.
WP‑Firewall propose des politiques WAF gérées adaptées à WordPress et des règles proactives pour les vulnérabilités logiques courantes comme les IDOR.
Protégez votre site aujourd'hui — Commencez avec le plan gratuit WP-Firewall
Si vous avez besoin d'une protection gérée immédiate pendant que vous gérez les mises à jour et la vérification des plugins, WP‑Firewall propose un plan de base gratuit conçu pour une couverture essentielle :
- Basique (gratuit) : Pare-feu géré, bande passante illimitée, WAF, scanner de logiciels malveillants et atténuation des risques OWASP Top 10.
- Standard ($50/an) : Ajoute la suppression automatique des logiciels malveillants et des contrôles simples de liste noire/liste blanche IP.
- Pro ($299/an) : Ajoute des rapports de sécurité mensuels, un patching virtuel automatique et des modules complémentaires premium tels qu'un gestionnaire de compte dédié et un service de sécurité géré.
Inscrivez-vous au plan gratuit WP‑Firewall et obtenez une protection WAF gérée et un scan automatique pendant que vous appliquez des mises à jour de plugins et des durcissements : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
C'est le moyen le plus rapide de mettre une couche de protection sur votre site et de réduire la fenêtre d'exposition causée par les vulnérabilités des plugins tiers.
Derniers mots — une feuille de route pratique
- Mettez à jour FluentForm vers 6.2.1 ou une version ultérieure immédiatement.
- Si vous ne pouvez pas mettre à jour immédiatement : désactivez l'enregistrement ouvert, désactivez temporairement le plugin et appliquez des patches virtuels WAF.
- Auditez et durcissez les rôles des utilisateurs, supprimez les abonnés inutiles et ajoutez une surveillance pour les activités suspectes.
- Utilisez WP‑Firewall pour une protection gérée immédiate — le plan gratuit fournit une base solide pendant que vous prenez les mesures ci-dessus.
- Si vous détectez une compromission, suivez la liste de contrôle de réponse aux incidents : isolez, préservez les journaux, réinitialisez les identifiants, scannez, restaurez et durcissez.
Les IDOR ne sont pas des bugs exotiques — ce sont des erreurs logiques qui sont évitables avec une bonne hygiène de développement et des défenses en couches. Le patching est l'action la plus importante, mais ne sous-estimez pas la rapidité et la valeur du patching virtuel et de la surveillance. Si vous gérez plusieurs sites WordPress, investissez dans un plan de mise à jour et de surveillance régulier. Cela vous fera gagner du temps, de la réputation et potentiellement des coûts de gestion d'incidents plus tard.
Si vous souhaitez de l'aide pour examiner votre site ou appliquer des patches virtuels d'urgence, l'équipe de WP‑Firewall peut vous aider avec l'audit, les règles WAF gérées et les options de récupération. Commencez avec le plan de protection gratuit pour obtenir une couverture immédiate pendant que vous mettez en œuvre des corrections : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Si vous le souhaitez, nous pouvons produire un manuel de remédiation concis et étape par étape adapté à votre environnement d'hébergement (cPanel, Plesk, hébergeur géré ou déploiements conteneurisés). Dites-nous quelle configuration d'hébergement vous utilisez et nous préparerons une liste de contrôle et des exemples de règles WAF que vous pourrez copier dans WP‑Firewall ou votre console de gestion WAF existante.
