| Nom du plugin | Créateur de blocs de shortcodes ultime |
|---|---|
| Type de vulnérabilité | Scripts intersites (XSS) |
| Numéro CVE | CVE-2024-12166 |
| Urgence | Moyen |
| Date de publication du CVE | 2026-03-26 |
| URL source | CVE-2024-12166 |
XSS réfléchi dans “Shortcodes Blocks Creator Ultimate” (<= 2.2.0, CVE-2024-12166) : Ce que les propriétaires de sites WordPress doivent faire maintenant
Date: 24 mars 2026
Une vulnérabilité récemment divulguée dans le plugin WordPress “Créateur de blocs de shortcodes ultime” (versions <= 2.2.0) — suivie comme CVE-2024-12166 — est un problème de Cross-Site Scripting (XSS) réfléchi qui peut être déclenché via le page paramètre. La vulnérabilité permet à un attaquant non authentifié de créer une URL qui, lorsqu'elle est visitée par un utilisateur privilégié ou un administrateur, peut entraîner l'exécution de JavaScript arbitraire dans le contexte de la session de navigateur de cet utilisateur.
En tant qu'équipe de sécurité WordPress chez WP-Firewall, nous traitons les XSS réfléchis dans les plugins destinés aux administrateurs avec une grande urgence. Cet avis explique les détails techniques, les scénarios de risque dans le monde réel, la détection et les indicateurs de compromission, les atténuations immédiates que vous pouvez appliquer, et les meilleures pratiques à long terme pour les développeurs. Nous couvrons également comment un pare-feu d'application web géré (WAF) et le patching virtuel peuvent vous protéger pendant que le mainteneur du plugin publie un correctif officiel.
Note: cet avis évite le code d'exploitation. L'objectif est d'informer les propriétaires de sites et les développeurs afin qu'ils puissent réagir rapidement et en toute sécurité.
Résumé exécutif
- Vulnérabilité : Cross-Site Scripting (XSS) réfléchi via
pageparamètre dans le plugin Shortcodes Blocks Creator Ultimate (<= 2.2.0). - CVE : CVE-2024-12166
- Versions affectées : version 2.2.0 et antérieures
- Impact : Exécution de JavaScript arbitraire dans le navigateur de la victime après interaction de l'utilisateur (clic sur un lien conçu ou visite d'une page malveillante).
- Privilège requis : aucun pour l'attaquant pour créer l'URL ; nécessite un utilisateur privilégié (généralement un administrateur ou un éditeur) pour interagir avec le lien conçu.
- Gravité : Moyenne / CVSS ~7.1 (significatif en raison de l'impact administratif potentiel).
- Recommandation immédiate : appliquer le correctif officiel lorsqu'il est disponible OU appliquer des atténuations en couches maintenant — désactiver ou restreindre le plugin, appliquer les meilleures pratiques pour les administrateurs, renforcer l'accès et déployer des règles WAF/patching virtuel.
Qu'est-ce que le XSS réfléchi et pourquoi est-il dangereux ici ?
Le XSS réfléchi se produit lorsqu'une application inclut des données fournies par l'utilisateur non assainies dans une page de réponse, ce qui amène un navigateur à exécuter du JavaScript fourni par l'attaquant. Contrairement au XSS stocké, la charge utile malveillante n'est pas stockée de manière persistante sur le site — elle est “réfléchie” à partir d'une requête et exécutée lorsqu'un utilisateur visite l'URL conçue.
Ce problème particulier est dangereux pour trois raisons :
- Le plugin expose des fonctionnalités accessibles par des pages d'administration ou des pages où des utilisateurs privilégiés opèrent. Si un administrateur clique sur le lien malveillant, le script s'exécute dans un contexte où des actions à privilèges élevés (paramètres du plugin, création de publications, modifications d'utilisateurs) sont possibles.
- Même une courte exécution de JavaScript peut suffire à voler des cookies d'authentification, usurper des administrateurs, injecter des portes dérobées ou modifier des paramètres critiques du site.
- L'attaque peut être automatisée à grande échelle : les attaquants peuvent créer des URL et tenter des campagnes de phishing, ou publier des liens pour tromper les administrateurs afin qu'ils les visitent.
La vulnérabilité nécessite une interaction de l'utilisateur (l'utilisateur privilégié doit cliquer ou visiter), mais c'est un vecteur réaliste : un attaquant peut envoyer un e-mail, publier un message privé ou héberger une page qui incite l'administrateur du site à suivre le lien.
Comment la vulnérabilité fonctionne typiquement (niveau élevé)
- Un attaquant construit une URL qui cible une page dans le plugin vulnérable et injecte du code de script malveillant (ou des caractères) dans le
pageparamètre ou d'autres champs de requête. - Le plugin vulnérable renvoie ce paramètre dans une page HTML sans échappement ou assainissement approprié.
- L'attaquant envoie l'URL à un utilisateur avec des privilèges élevés (administrateur ou un autre rôle privilégié).
- Lorsque l'utilisateur ouvre l'URL, le JavaScript de l'attaquant s'exécute dans le navigateur de l'utilisateur sous l'origine du site (même origine), permettant des techniques potentielles de prise de contrôle de compte : vol de cookies, déclenchement de CSRF, invites de vol d'identifiants, manipulation du DOM et appels API utilisant la session authentifiée de l'utilisateur.
- L'attaquant peut alors escalader l'accès, créer de nouveaux comptes administrateurs, télécharger des fichiers de plugin/thème malveillants ou persister une porte dérobée.
Scénarios d'attaque réalistes
- Phishing auprès des administrateurs : Un attaquant envoie un e-mail au propriétaire du site avec un lien qui semble être une URL de site légitime. Si l'administrateur clique, le JavaScript injecté s'exécute.
- Leurres de sites tiers : Le lien malveillant est publié sur un forum ou envoyé en privé à un canal de chat d'équipe. Tout utilisateur privilégié qui clique est affecté.
- Attaques inter-sites impliquant un site externe : Un attaquant intègre un lien conçu dans une page ou un message tiers que l'administrateur visite, provoquant l'exécution du XSS réfléchi.
- Suivis après exécution : Après l'exécution initiale du script, le code de l'attaquant peut appeler des points de terminaison réservés aux administrateurs (via XHR/fetch) pour créer de nouveaux comptes, injecter des options malveillantes ou installer des plugins/portes dérobées — menant finalement à la compromission du site.
Qui est à risque ?
- Tout site WordPress utilisant le plugin Shortcodes Blocks Creator Ultimate version 2.2.0 ou antérieure.
- Administrateurs et autres comptes d'utilisateurs privilégiés dont les sessions de navigateur peuvent être trompées pour visiter une URL malicieusement conçue.
- Les sites avec une sécurité admin faible (connexion à facteur unique, mots de passe réutilisés, pas de gestion de session) sont à un risque plus élevé de compromission persistante après un XSS initial.
Détection : quoi rechercher
Le XSS réfléchi est transitoire, donc les preuves directes dans les fichiers du site sont souvent manquantes. Recherchez des indicateurs indirects :
- Activité de connexion inhabituelle ou nouveaux comptes administrateurs créés après des clics suspects.
- Changements inattendus dans les paramètres de plugin/thème, publications ou pages.
- Requêtes HTTP sortantes de votre serveur vers des adresses IP inconnues (signe de porte dérobée ou d'exfiltration).
- Fichiers modifiés avec des horodatages inattendus (nouveaux fichiers PHP, portes dérobées déposées).
- Tâches programmées suspectes (hooks cron) que vous n'avez pas définies.
- Journaux du serveur web montrant des requêtes contenant des chaînes de requête inhabituelles (en particulier
page=avec des caractères encodés tels que%3C,%3E,JavaScript :, ou des attributs commeonerror=). - Alertes des scanners de malware indiquant un JavaScript inhabituel ou du code obfusqué injecté dans les pages.
- Erreurs de console de navigateur ou scripts en ligne inattendus lorsque les administrateurs chargent certaines pages de plugin.
Si vous soupçonnez qu'un administrateur compromis a cliqué sur un lien malveillant, vérifiez immédiatement les signes ci-dessus et procédez à la réponse à l'incident.
Étapes d'atténuation immédiates (liste de contrôle pour le propriétaire du site)
Si vous gérez un site qui utilise le plugin affecté, prenez ces mesures dès maintenant :
- Vérifier la version du plugin :
- Si vous êtes sur une version fixe (une mise à jour de plugin est publiée), mettez à jour le plugin immédiatement.
- Si aucun correctif n'est encore disponible, continuez avec les atténuations ci-dessous.
- Restreindre l'accès aux pages du plugin :
- Restreindre l'accès aux pages d'administration du plugin par IP ou par rôle. Utilisez .htaccess, des règles de serveur web ou un plugin qui limite l'accès admin.
- Mettre en œuvre l'authentification à deux facteurs (2FA) pour tous les utilisateurs administrateurs.
- Renforcez les comptes administrateurs :
- Changez immédiatement les mots de passe des administrateurs et imposez des mots de passe forts et uniques.
- Déconnectez toutes les sessions actives (WordPress → Utilisateurs → Modifier le profil → Sessions) ou utilisez un plugin pour forcer la déconnexion partout.
- Supprimez les comptes admin inutilisés.
- Désactivez ou désactivez temporairement le plugin vulnérable :
- Si le plugin n'est pas essentiel, désactivez-le ou désinstallez-le jusqu'à ce qu'une version sécurisée soit disponible.
- Si la désactivation n'est pas possible (la fonctionnalité du site en dépend), bloquez les pages d'administration spécifiques du plugin en utilisant des règles de contrôle d'accès (liste blanche IP dans la zone admin, ou blocage de points de terminaison spécifiques).
- Analyser et nettoyer :
- Effectuez une analyse complète des logiciels malveillants sur votre site et votre compte d'hébergement.
- Vérifiez l'intégrité des fichiers pour les fichiers modifiés ou suspects dans wp-content, wp-includes et la racine.
- Restaurez à partir d'une sauvegarde connue et bonne si vous détectez des fichiers malveillants que vous ne pouvez pas nettoyer en toute sécurité.
- Révocation & secrets :
- Faites tourner les clés API, les secrets et changez les mots de passe pour tout service qui a pu être exposé.
- Envisagez de révoquer et de réémettre tous les jetons utilisés pour l'automatisation du site.
- Surveiller les journaux :
- Surveillez de près les journaux du serveur web pour des requêtes suspectes avec des paramètres de requête ou des agents utilisateurs inhabituels.
- Surveillez la création de nouveaux comptes administrateurs et les installations de plugins.
- Informer les parties prenantes :
- Informez votre équipe et votre fournisseur d'hébergement si vous détectez une compromission. Si vous avez des données clients à risque, suivez les exigences de notification légales ou réglementaires.
WAF et patching virtuel — protection en attendant un patch officiel
Si une mise à jour officielle du plugin n'est pas encore disponible, la manière la plus rapide et la moins perturbante de réduire le risque est d'appliquer un patch virtuel avec un WAF. Un WAF géré peut bloquer les tentatives d'exploitation avant qu'elles n'atteignent le code vulnérable.
Actions WAF recommandées (exemples et modèles sûrs que vous pouvez utiliser pour créer des règles) :
- Bloquez les caractères et mots-clés suspects dans le
pageparamètre (ou toute chaîne de requête) pour les requêtes qui ciblent les points de terminaison d'administration du plugin. - Bloquez les modèles de charge utile XSS courants, tels que les balises script (
5.) et les URI JavaScript, les gestionnaires d'événements (onerror=,onload=), ou les équivalents encodés. - Appliquez des règles ciblées uniquement pour les requêtes qui correspondent aux chemins des plugins afin d'éviter les faux positifs.
Exemple de pseudo-règle (pseudo-syntaxe similaire à ModSecurity ; adaptez pour votre interface WAF) :
Remarque : Ne copiez pas les charges utiles d'exploitation dans les journaux ou les règles. Utilisez des modèles qui correspondent aux marqueurs des tentatives XSS.
# Pseudo-rule: Block requests with script-like patterns to plugin admin pages If REQUEST_URI contains "/wp-admin/admin.php" AND REQUEST_ARGS["page"] matches "(%3C|<).*script.*(%3E|>)|javascript:|onerror=|onload=" Then BLOCK and LOG the request
Une autre approche consiste à renforcer les caractères autorisés :
# Pseudo-règle : N'autorisez que les caractères sûrs pour le paramètre de page sur les points de terminaison des plugins
Si vous utilisez un service WAF géré, soumettez un ticket pour obtenir un correctif virtuel personnalisé (une règle ciblée) déployé pour votre site afin de bloquer le vecteur d'attaque tout en suivant d'autres étapes de remédiation. Cette approche réduit immédiatement le risque sans modifier le code du plugin.
Conseils de sécurité pour les développeurs (pour les auteurs et les mainteneurs de plugins)
Si vous développez des plugins WordPress ou êtes responsable de ce plugin spécifique, ces recommandations axées sur les développeurs sont essentielles :
- Assainissez et échappez toutes les entrées fournies par l'utilisateur :
- Utilisez les fonctions d'assainissement de WordPress telles que
assainir_champ_texte(),esc_attr(),esc_html(),esc_url(), etwp_kses()le cas échéant. - Ne jamais afficher directement des données non échappées dans le HTML.
- Utilisez les fonctions d'assainissement de WordPress telles que
- Utilisez un échappement de contexte de sortie approprié :
esc_html()pour le contenu du corps HTML.esc_attr()pour les contextes d'attributs.esc_url_raw()/esc_url()pour les URI.- Utiliser
wp_kses_post()ouwp_kses()lorsque du HTML partiel est autorisé (et définissez les balises autorisées).
- Utilisez des nonces et des vérifications de capacité :
- Valider
current_user_can()pour les actions administratives. - Utiliser
wp_verify_nonce()pour les actions POST et les soumissions de formulaires administratifs.
- Valider
- Évitez de refléter les paramètres de requête bruts dans les pages administratives :
- Si vous devez refléter des paramètres pour la navigation ou l'état, assainissez-les et utilisez des listes blanches pour les valeurs attendues.
- Convertissez l'entrée en jetons, ou associez les valeurs de requête à des étiquettes connues et sûres avant la sortie.
- Validation côté serveur :
- Validez côté serveur, pas seulement côté client. Ne comptez jamais uniquement sur JavaScript pour la validation.
- Tests de sécurité :
- Incluez une analyse statique automatisée et des tests dynamiques axés sur l'injection et le XSS.
- Ajoutez des tests unitaires qui vérifient l'échappement attendu pour tous les chemins de sortie.
- En-têtes de réponse :
- Retournez des en-têtes sécurisés comme Content-Security-Policy (CSP) qui restreignent l'exécution de scripts en ligne et réduisent le risque de XSS.
- Ajoutez HttpOnly aux cookies lorsque cela est possible pour réduire le vol via des scripts côté client.
- Versions de correctifs rapides :
- Lorsqu'une vulnérabilité est signalée, validez et publiez un correctif rapidement et de manière transparente, y compris les étapes de mise à niveau recommandées pour les propriétaires de sites.
Pour les fournisseurs d'hébergement et les agences
- Appliquez une atténuation globale via le WAF au niveau de l'hôte pour tous les clients utilisant le plugin vulnérable.
- Proposez de restreindre temporairement ou de désactiver le plugin pour les clients qui ne peuvent pas mettre à jour.
- Fournissez des conseils clairs et une liste de contrôle de remédiation aux clients (rotation des mots de passe, analyse, contrôle administratif).
- Soutenez la réponse aux incidents et l'analyse judiciaire pour les clients qui ont pu être compromis.
Indicateurs de compromission (IoCs) à rechercher.
- Entrées de journal Web avec des demandes à
/wp-admin/admin.phpou d'autres points de terminaison administratifs contenantpage=avec encodé<,>,JavaScript :,onerror=,onload=, ou d'autres jetons de gestionnaire d'événements. - Nouveaux utilisateurs administrateurs créés ou modifiés peu après une entrée de journal suspecte.
- Modifications des fichiers de plugin/thème avec des horodatages correspondant à une activité suspecte.
- Événements planifiés indésirables (wp-cron) invoquant des fonctions inconnues.
- Options modifiées dans le
options_wptableau (recherchez des valeurs inattendues ou des données sérialisées). - Installations inattendues de plugins ou de thèmes pendant la même période.
Si vous trouvez l'un de ces éléments, supposez la possibilité d'une compromission plus profonde et envisagez une réponse professionnelle à l'incident.
Récupération et nettoyage si vous avez été compromis
- Mettez le site hors ligne pour contenir si des preuves claires de compromission existent.
- Conservez les journaux et les instantanés pour analyse.
- Réinstallez les fichiers principaux de WordPress à partir de sources fiables.
- Remplacez les plugins et les thèmes par des copies propres ou restaurez à partir d'une sauvegarde antérieure à la compromission.
- Nettoyez ou remplacez les fichiers PHP modifiés ; supprimez les fichiers ou scripts PHP inconnus.
- Changez tous les mots de passe (admin, FTP, panneau d'hébergement, base de données) et les clés API.
- Réémettez tous les jetons et secrets exposés.
- Rescannez le site après le nettoyage pour vous assurer qu'aucune porte dérobée ne reste.
- Examinez les processus du serveur et les tâches cron.
- Envisagez de restaurer à partir d'une sauvegarde propre et d'appliquer les atténuations ci-dessus avant de reconnecter le site à Internet.
Pourquoi une approche en couches est essentielle
- Corriger le plugin est la bonne solution à long terme, mais une mise à jour officielle peut prendre du temps.
- 1. Désactiver le plugin réduit la surface d'attaque mais peut casser la fonctionnalité du site.
- 2. Le WAF/le patching virtuel est rapide et efficace pour bloquer les modèles d'attaque mais ne remplace pas les correctifs côté serveur appropriés.
- 3. Une sécurité admin forte (2FA, gestion des sessions) réduit la probabilité d'escalade de privilèges après une exécution réussie de XSS réfléchi.
- 4. Les capacités de surveillance et de réponse aux incidents vous aident à détecter et à récupérer rapidement.
5. Combiner ces couches — patching rapide, protections WAF, durcissement admin, surveillance continue et pratiques de développement sécurisées — offre la meilleure protection.
6. Exemples de modèles de règles WAF (ne pas copier les charges utiles)
7. Voici des idées de règles génériques et sûres pour aider votre équipe de sécurité à configurer le blocage sans risquer de faux positifs. Adaptez-les à votre environnement et testez-les soigneusement.
- 8. Bloquez les requêtes ciblant les points de terminaison admin du plugin qui incluent des chevrons ou des jetons XSS courants dans les chaînes de requête.
- 9. Challenge (CAPTCHA) ou présentez un interstitiel à toute requête vers les chemins wp-admin contenant des caractères encodés suspects.
- 10. Limitez le taux ou bloquez les requêtes répétées qui sondent les points de terminaison du plugin avec des encodages de paramètres inhabituels.
- 11. Déployez une règle personnalisée qui inspecte le
page12. paramètre pour des caractères en dehors d'une liste blanche attendue (lettres, chiffres, tirets, traits de soulignement).
13. Les tests et la mise en scène sont essentiels avant d'appliquer des règles agressives en production. Surveillez toujours les faux positifs (requêtes légitimes qui sont bloquées).
14. Liste de contrôle pratique pour les propriétaires de sites (liste de contrôle à copier-coller)
- 15. Vérifiez la version du plugin. Si une mise à jour est disponible, mettez à jour vers la version corrigée.
- 16. S'il n'y a pas encore de patch, désactivez le plugin si possible.
- Déconnectez toutes les sessions administratives et faites tourner les mots de passe administrateurs.
- Activer l'authentification à deux facteurs pour tous les utilisateurs administrateurs.
- 17. Appliquez la ou les règles WAF pour bloquer les valeurs de paramètres suspectes pour les points de terminaison admin du plugin.
page18. Scannez le site pour détecter des logiciels malveillants et vérifiez l'intégrité des fichiers. - 19. Restreignez l'accès à wp-admin via une liste blanche d'IP lorsque cela est possible.
- Restreindre l'accès à wp-admin via une liste blanche d'IP lorsque cela est possible.
- Vérifiez les nouveaux utilisateurs administrateurs et les tâches planifiées inattendues.
- Sauvegardez le site maintenant (après nettoyage) et documentez les étapes de l'incident.
- Abonnez-vous à des flux de sécurité fiables pour des mises à jour sur les versions corrigées.
Comment WP-Firewall aide (notre approche)
Chez WP-Firewall, nous recommandons une réponse pratique et en couches pour des problèmes comme CVE-2024-12166 :
- WAF géré et patching virtuel : nos ingénieurs peuvent déployer des règles ciblées qui bloquent les modèles d'exploitation connus pour ce XSS réfléchi pendant que vous attendez une mise à jour officielle du plugin. Cela réduit le risque sans avoir besoin de modifier le code du site.
- Analyse et nettoyage des logiciels malveillants : les analyses programmées détectent les indicateurs de compromission tôt. Si vous soupçonnez une compromission, notre équipe peut aider avec des nettoyages ou fournir des conseils pour restaurer à partir de sauvegardes propres.
- Outils de durcissement des administrateurs : nous aidons à appliquer l'authentification à deux facteurs, les politiques de verrouillage et la gestion des sessions pour rendre plus difficile pour les attaquants d'utiliser une exécution XSS pour prendre le contrôle du compte.
- Surveillance et alertes : nous surveillons les modèles de requêtes suspects et vous informons rapidement lorsqu'une exploitation potentielle est tentée afin que vous puissiez agir.
- Conseils de sécurité : listes de contrôle exploitables et support individuel pour aider les agences et les propriétaires de sites à réagir rapidement et à limiter les dommages.
Utiliser un WAF géré en combinaison avec les autres recommandations ci-dessus offre la réduction de risque pratique la plus rapide pour les problèmes de XSS réfléchis.
Nouveau : Commencez avec le plan gratuit de WP-Firewall aujourd'hui
Titre : Protégez votre administrateur WordPress dès le premier clic — Commencez avec une couche de défense gratuite
Nous comprenons que le temps et les ressources varient d'un site à l'autre. Si vous recherchez une protection immédiate que vous pouvez activer aujourd'hui, essayez le plan de base gratuit de WP-Firewall. Il vous offre des défenses essentielles pour réduire l'exposition aux XSS réfléchis et à d'autres types d'attaques courants :
- Protection essentielle : pare-feu géré qui bloque les modèles d'attaque courants.
- Bande passante illimitée à travers la couche de pare-feu.
- Règles de pare-feu d'application web (WAF) pour atténuer les risques du Top 10 OWASP.
- Scanner de logiciels malveillants qui aide à détecter les scripts injectés et les portes dérobées.
Vous pouvez vous inscrire au plan gratuit ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Si vous avez besoin d'un nettoyage plus rapide et automatisé ainsi que de contrôles plus granulaires, nos plans Standard et Pro ajoutent la suppression automatique de logiciels malveillants, le blocage d'IP, des capacités de patch virtuel, des rapports de sécurité mensuels et des services gérés premium.
Recommandations à long terme pour les propriétaires de sites WordPress et les développeurs
- Gardez les plugins et les thèmes à jour. Mettez en place des mises à jour en plusieurs étapes ou des tests de patch afin de pouvoir appliquer les mises à jour en toute sécurité.
- N'installez que des plugins provenant de sources réputées et supprimez les plugins/thèmes inutilisés.
- Appliquez le principe du moindre privilège pour les rôles d'utilisateur et minimisez les utilisateurs administrateurs.
- Adoptez un WAF et un scan automatisé dans le cadre de la maintenance de routine.
- Effectuer des sauvegardes régulières et tester les restaurations.
- Éduquez les administrateurs et les éditeurs sur les risques de phishing — le XSS réfléchi nécessite généralement une interaction de l'utilisateur comme cliquer sur un lien. La sensibilisation réduit les taux de réussite.
- Encouragez les auteurs de plugins à adopter des listes de contrôle de codage sécurisé et des tests de sécurité automatisés.
Derniers mots — urgence et équilibre
Les vulnérabilités XSS réfléchies comme CVE-2024-12166 sont courantes mais restent impactantes car elles exploitent le comportement humain. Le chemin vers le compromis nécessite généralement une combinaison de vulnérabilité technique et d'une action de l'utilisateur (cliquer sur un lien conçu), ce qui signifie que nous devons défendre à la fois le code et les personnes qui l'utilisent.
Actions immédiates que vous devriez prioriser :
- Mettez à jour le plugin si un patch est disponible.
- Si ce n'est pas disponible, bloquez la surface d'attaque (désactivez le plugin, limitez l'accès) et déployez des WAF/patchs virtuels pour stopper les modèles d'exploitation.
- Renforcez les comptes administrateurs et surveillez les journaux pour détecter des signes de compromission.
- Si une compromission est suspectée, suivez la liste de contrôle de récupération d'incidents et envisagez une aide judiciaire professionnelle.
Nous reconnaissons que les décisions de sécurité doivent équilibrer disponibilité et risque. Si vous avez besoin d'aide pour appliquer des atténuations ou si vous souhaitez un second avis sur la bonne approche pour votre site, l'équipe de WP-Firewall est prête à vous aider.
Restez en sécurité, gardez les plugins à jour et n'hésitez pas à appliquer des contrôles en couches en attendant les patchs des développeurs.
