Nom du plugin	Schéma de données structurées WP SEO
Type de vulnérabilité	Scripts intersites (XSS)
Numéro CVE	CVE-2026-3604
Urgence	Faible
Date de publication du CVE	2026-05-12
URL source	CVE-2026-3604

XSS stocké par un contributeur authentifié dans le schéma de données structurées WP SEO (CVE-2026-3604) — Ce que les propriétaires de sites WordPress doivent savoir

TL;DR — Une vulnérabilité de Cross‑Site Scripting (XSS) stockée (CVE-2026-3604) a été divulguée, affectant le plugin “ WP SEO Structured Data Schema ” dans les versions jusqu'à et y compris 2.8.1. Un utilisateur authentifié avec des privilèges de contributeur peut stocker un script malveillant qui s'exécutera plus tard lorsqu'un utilisateur ayant des privilèges plus élevés ou un autre visiteur consulte une page affectée. Le problème a une gravité équivalente au CVSS de 6.5 et nécessite une interaction de l'utilisateur pour une exploitation réussie. Aucun correctif officiel n'était disponible au moment de la divulgation. Si vous utilisez ce plugin, suivez immédiatement les étapes d'atténuation ci-dessous.

---

Pourquoi c'est important (court)

L'XSS stocké est l'une des vulnérabilités côté client les plus dangereuses car la charge utile malveillante est persistée sur le site (base de données, options, postmeta) et s'exécute dans le navigateur de quiconque consulte le contenu infecté. Lorsque les contributeurs — utilisateurs pouvant créer du contenu mais souvent non dignes de confiance pour inclure du HTML brut — peuvent injecter des scripts qui sont ensuite rendus aux administrateurs ou aux éditeurs, un compromis peut s'intensifier rapidement : détournement de session, création d'administrateurs malveillants, modification de configuration, installation de portes dérobées, spam SEO ou distribution massive de logiciels malveillants.

---

Instantané de vulnérabilité

• Vulnérabilité: XSS stocké authentifié (contributeur+)
• Logiciels concernés : Plugin WP SEO Structured Data Schema
• Versions concernées : <= 2.8.1
• CVE : CVE-2026-3604
• Publié : 11 mai 2026
• Privilège requis : Contributeur (ou supérieur)
• Gravité similaire à CVSS : 6.5 (modéré/moyen)
• Exploitation : Nécessite la présence d'un compte de contributeur et une interaction d'utilisateur privilégié (par exemple, visualisation ou interaction avec la charge utile stockée dans l'administration ou le frontend)
• État du correctif lors de la divulgation : Aucun correctif officiel disponible (les propriétaires de sites doivent appliquer des atténuations)

---

Comment fonctionne l'XSS stocké dans ce contexte

Une vulnérabilité XSS stockée signifie que les entrées fournies par l'utilisateur sont enregistrées sur le site et ensuite sorties sans une sanitation ou un échappement appropriés. Dans le plugin en question, certains champs que les contributeurs peuvent remplir (par exemple, des extraits de données structurées, des champs méta ou des entrées de schéma personnalisées) ne sont pas suffisamment filtrés. Un attaquant avec un compte de contributeur peut insérer des charges utiles HTML/JavaScript qui sont enregistrées dans la base de données. Lorsque qu'un administrateur/éditeur (ou un visiteur du site) charge la page ou la vue d'administration du plugin qui sort ce contenu, le script malveillant s'exécute dans le contexte du navigateur de cet utilisateur.

Parce que le script s'exécute avec les privilèges de la victime dans le navigateur, les conséquences incluent :

• Vol de cookies d'authentification ou de jetons de session (menant à la prise de contrôle du compte).
• Exécution d'actions administratives en falsifiant des requêtes (flux similaires à CSRF).
• Injection de portes dérobées persistantes, de comptes administrateurs ou de modifications malveillantes du plugin.
• Altération du contenu SEO ou insertion de liens de spam pour dégrader la réputation.
• Fourniture de JavaScript malveillant qui redirige ou charge des logiciels malveillants à l'insu des visiteurs.

Même si l'attaquant initial doit détenir un compte de contributeur (un rôle de moindre privilège), l'XSS stocké peut devenir un vecteur d'escalade vers un compromis complet du site une fois que les administrateurs interagissent avec la charge utile stockée.

---

Qui est à risque ?

• Sites avec le plugin WP SEO Structured Data Schema installé et activé, fonctionnant avec la version 2.8.1 ou antérieure.
• Sites qui permettent aux utilisateurs externes de s'inscrire ou d'obtenir un rôle de Contributeur (ou supérieur).
• Blogs multi-auteurs où les Contributeurs produisent des données structurées ou remplissent des champs gérés par le plugin qui sont ensuite affichés dans les écrans d'administration ou les modèles front-end.
• Sites où les administrateurs ou éditeurs examinent fréquemment le contenu directement dans l'interface d'administration sans désinfection supplémentaire.

Si vous n'utilisez pas le plugin ou s'il n'est pas actif — vous n'êtes pas impacté. Si vous hébergez le plugin mais ne l'avez pas mis à jour ou supprimé, considérez cela comme une priorité élevée à évaluer et à atténuer.

---

Scénarios d'exploitation dans le monde réel

1. Contributeur → Ingénierie sociale → Admin
   • Un attaquant avec un compte de Contributeur enregistre un extrait de schéma conçu ou un champ méta contenant une charge utile à l'apparence inoffensive qui contient un script caché.
   • Un éditeur/admin ouvre la page des paramètres du plugin ou consulte le post dans l'aperçu admin ; le script s'exécute dans leur navigateur.
   • Le script utilise les cookies authentifiés de l'admin pour effectuer des actions via des points de terminaison AJAX avec privilèges admin (créer un nouvel admin, installer un plugin malveillant, changer l'email du site, etc.).
2. Contributeur → Exécution front-end → Visiteurs
   • Le plugin génère des données structurées ou un balisage de schéma dans la page front-end sans échapper ; le navigateur d'un visiteur exécute la charge utile.
   • Le script charge du code malveillant tiers (malvertising, phishing) ou exploite une vulnérabilité du navigateur pour persister sur la machine du visiteur, nuisant à la réputation et exposant les visiteurs.
3. Charge utile stockée + tâches planifiées
   • La charge utile déclenche des actions lorsque des pages de maintenance cron ou planifiées sont visitées par des utilisateurs privilégiés, automatisant une persistance résistante au nettoyage.

L'élément critique est que la charge utile est stockée et peut être déclenchée lorsque des utilisateurs ayant des privilèges plus élevés interagissent avec le contenu.

---

Étapes immédiates à suivre (dans les 24 heures)

1. Inventoriez et évaluez
   • Vérifiez si le plugin WP SEO Structured Data Schema est installé et déterminez sa version.
     • WP-CLI : wp plugin get wp-seo-structured-data-schema --field=version
     • Admin WordPress : Plugins → Plugins installés → vérifier la version
   • Si le plugin est actif et que la version ≤ 2.8.1, prenez des mesures d'atténuation maintenant.
2. Si vous ne pouvez pas appliquer de correctif (aucun correctif officiel disponible) :
   • Désactivez le plugin immédiatement si possible. La désactivation est l'atténuation immédiate la plus sûre.
     • WP-CLI : wp plugin désactiver wp-seo-structured-data-schema
   • Si vous ne pouvez pas désactiver (raisons professionnelles), limitez l'exposition :
     • Restreignez l'accès aux pages d'administration du plugin par IP (utilisez les contrôles d'hébergement ou le WAF).
     • Désactivez temporairement la possibilité pour les contributeurs de créer ou de modifier les champs gérés par le plugin.
     • Exigez une révision manuelle par les éditeurs avant que le contenu ne soit mis en ligne.
3. Verrouillez les privilèges des utilisateurs.
   • Supprimez ou rétrogradez tout compte de contributeur non fiable.
   • Appliquez des mots de passe forts et faites tourner les identifiants pour les administrateurs et les éditeurs.
   • Désactivez l'enregistrement de nouveaux utilisateurs si ce n'est pas nécessaire.
4. Inspectez et nettoyez.
   • Recherchez des scripts suspects et des balises injectées dans le contenu et le stockage lié au plugin (voir la section Détection ci-dessous pour les requêtes).
   • Supprimez tous les scripts malveillants découverts, les utilisateurs indésirables ou les comptes administratifs injectés.
   • Si vous trouvez des modifications persistantes des fichiers, restaurez à partir d'une sauvegarde propre.
5. Surveiller les journaux et le trafic
   • Vérifiez les journaux du serveur et de l'application pour des requêtes POST suspectes, des vues de pages d'administration inhabituelles ou des pics d'activité.
   • Surveillez le trafic sortant pour de nouvelles connexions à des hôtes inconnus qui pourraient indiquer un signalement par des logiciels malveillants.
6. Appliquez un WAF/patch virtuel
   • Déployez des règles de pare-feu d'application Web (WAF) pour bloquer les charges utiles XSS typiques dans les points de terminaison du plugin affecté, ajoutez des signatures pour bloquer 5. (et d'autres modèles suspects) dans les soumissions aux points de terminaison liés au schéma, et bloquez les POST malveillants des points de terminaison des contributeurs.
   • Si vous utilisez WP-Firewall, activez le patch virtuel et configurez l'ensemble de règles qui cible les points de terminaison de ce plugin et les modèles XSS typiques.
7. Plan de remédiation
   • Surveillez les canaux de plugins officiels pour une publication de sécurité. Lorsqu'un correctif officiel est publié, appliquez-le rapidement dans un environnement de staging, testez-le, puis déployez-le en production.

---

Détection : comment trouver des artefacts d'exploitation possibles

Supposer que l'attaquant stocke des scripts dans le contenu des publications, les métadonnées des publications, les options ou des tables personnalisées. Utilisez les approches suivantes pour localiser des artefacts suspects.

Recherchez des balises script ou des attributs on-event dans le contenu :

• Exemple WP-CLI :
  • Rechercher des publications avec 5. balises :

    Requête wp db "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' ;"

  • Rechercher dans postmeta :

    wp db query "SELECT meta_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

• SQL direct (remplacez les préfixes de table si différents) :

  • SELECT ID, post_title FROM wp_posts WHERE post_content REGEXP '<[[:space:]]*script';

  • SELECT post_id, meta_key FROM wp_postmeta WHERE meta_value REGEXP '<[[:space:]]*script';

Recherchez des attributs HTML suspects couramment utilisés dans les charges utiles XSS :
onerror=, onload=, onclick=, JavaScript :, document.cookie, window.location, évaluer(

Recherchez les options du site et les champs liés aux plugins :

SELECT option_name FROM wp_options WHERE option_value LIKE '%

Recherchez des fichiers et des téléchargements :

• Scannez le répertoire des fichiers pour des fichiers PHP récemment ajoutés ou des fichiers JS suspects.
• Utiliser grep pour trouver des chaînes injectées :

  grep -R --exclude-dir=uploads 'document.cookie' .

  grep -R --exclude-dir=wp-content/uploads '<script' wp-content/plugins/

Vérifiez les comptes utilisateurs :

• Listez les comptes avec des privilèges de Contributeur+ et leurs dernières heures de connexion.

  wp user list --role=contributor --fields=ID,user_login,user_email,user_registered,last_login

• Note: dernier_connexion peut nécessiter un plugin qui enregistre les connexions ; sinon, vérifiez les journaux d'authentification sur le serveur.

Si vous trouvez du contenu injecté, prenez des captures d'écran, exportez les enregistrements et conservez-les pour une analyse judiciaire avant de nettoyer.

---

Liste de contrôle de réponse aux incidents (détaillée)

1. Isoler
   • Désactivez immédiatement le plugin vulnérable ou restreignez l'accès à ses pages d'administration.
   • Si vous soupçonnez une compromission active, envisagez de mettre le site en mode maintenance et de bloquer temporairement l'accès public.
2. Préserver
   • Faites une sauvegarde complète (base de données + fichiers) et conservez une copie hors ligne à des fins d'analyse judiciaire.
3. Identifier
   • Exécutez les requêtes de détection ci-dessus.
   • Recherchez de nouveaux utilisateurs administrateurs, des plugins non autorisés, des fichiers principaux modifiés ou des tâches planifiées inattendues (wp_cron).
4. Retirer
   • Supprimez les scripts injectés des articles/postmeta/options.
   • Supprimez les utilisateurs indésirables et réinitialisez les mots de passe des éditeurs et des administrateurs.
   • Supprimez tous les plugins ou thèmes non autorisés et restaurez les fichiers modifiés à partir d'une sauvegarde de confiance.
5. Récupérer
   • Restaurez les fichiers principaux et les fichiers de plugin à partir de sources fiables.
   • Appliquez toute mise à jour de sécurité disponible pour le plugin lorsqu'elle est publiée. S'il n'y a pas encore de correctif officiel, continuez le patch virtuel et d'autres atténuations.
6. Examinez et renforcez
   • Auditez les rôles et les permissions des utilisateurs.
   • Assurez-vous que l'authentification à deux facteurs (2FA) est activée pour tous les administrateurs et éditeurs.
   • Passez en revue les pratiques de journalisation et de surveillance pour détecter plus tôt les abus futurs.
   • Mettez en œuvre un flux de travail de révision de contenu : les contributeurs ne doivent pas publier de contenu qui contourne la révision de l'éditeur.
7. Notifier
   • Informez les parties prenantes concernées (propriétaires de site, administrateurs).
   • Si des données clients ont été exposées ou si l'intégrité du site a été affectée, suivez les obligations réglementaires applicables.
8. Post-mortem
   • Documentez la cause profonde, les étapes prises et les améliorations pour prévenir la récurrence.

---

Stratégies d'atténuation — conseils techniques pour les développeurs et les administrateurs de site

Voici des étapes défensives pratiques que vous pouvez prendre pour atténuer la vulnérabilité et réduire le risque futur.

1. Principe du moindre privilège
   • Limitez les capacités des utilisateurs. Les contributeurs ne devraient pas avoir la possibilité d'injecter du HTML brut ou des scripts.
   • Envisagez de déplacer les utilisateurs vers un rôle personnalisé avec des capacités encore plus strictes lorsque cela est approprié.
2. Assainir les entrées et échapper les sorties
   • Le code du plugin doit assainir les entrées à l'acceptation et échapper les données à la sortie.
   • Utilisez les API WordPress :
     • Assainir à l'entrée : wp_kses_post(), assainir_champ_texte(), wp_strip_all_tags() en fonction du contenu attendu.
     • Échapper à la sortie : esc_html(), esc_attr(), wp_kses_post() selon les besoins.
3. Politique de sécurité du contenu (CSP)
   • Appliquer des en-têtes CSP pour limiter le risque d'exécution de scripts provenant de sources non autorisées.
   • Exemple d'en-tête (commencer restrictif, puis ajuster) :

     Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'nonce-'; object-src 'none';

   • CSP est efficace pour limiter l'impact des XSS mais doit être mis en œuvre avec soin pour éviter de casser la fonctionnalité du site.
4. Désactiver le HTML non filtré pour les rôles non fiables
   • WordPress permet la capacité unfiltered_html pour certains rôles. Assurez-vous que les contributeurs n'ont pas cette capacité.
   • Utilisez des plugins de gestion des capacités ou des extraits de code pour supprimer unfiltered_html pour le rôle de contributeur :

     function wpf_remove_unfiltered_html_from_contributors() {;
             

5. Renforcer les API REST et les points de terminaison AJAX
   • Assurez-vous que les points de terminaison qui acceptent des données structurées vérifient les capacités et les nonces.
   • Limitez qui peut POSTER vers les points de terminaison qui gèrent le schéma ou les paramètres du plugin.
6. Patching virtuel avec un WAF
   • Déployez des règles WAF qui inspectent les données POST pour les charges utiles XSS sur des points de terminaison spécifiques au plugin.
   • Exemple de modèles WAF génériques à bloquer :
     • Bloquer les requêtes avec <script dans les paramètres destinés aux points de terminaison de schéma.
     • Bloquez onerror=, onload=, JavaScript : apparaissant dans les champs de formulaire.
   • Si vous utilisez WP-Firewall, activez le WAF et configurez une règle qui se déclenche sur les charges utiles correspondant aux balises de script ou aux attributs d'événements suspects sur les points de terminaison admin et plugin.
7. Couches de validation des entrées
   • Lorsque des données structurées sont attendues (par exemple, JSON-LD), validez que les chaînes entrantes correspondent au format JSON attendu et aux clés autorisées.
   • Rejeter ou assainir le HTML et les attributs inattendus.
8. Examiner les mises à jour des plugins et les communications des fournisseurs.
   • S'abonner aux annonces de sécurité des fournisseurs et mettre à jour rapidement lorsqu'un correctif est publié.

---

Protections spécifiques à WP-Firewall (comment nous aidons).

En tant que fournisseur de pare-feu WordPress, WP-Firewall est conçu pour réduire le temps de protection avec une défense en couches :

• WAF géré et correctifs virtuels : nous pouvons ajouter une règle bloquant les modèles de charge utile XSS connus visant les points de terminaison de plugin vulnérables pendant que vous attendez une publication officielle.
• Scanner de logiciels malveillants et vérifications de réputation : scanner les scripts injectés et les fichiers modifiés.
• Blocage basé sur les rôles : limiter l'accès aux pages d'administration sensibles par IP ou refuser des requêtes HTTP spécifiques aux points de terminaison de plugin.
• Journaux et alertes : nous fournissons des alertes détaillées pour les soumissions suspectes aux pages de plugins et les tentatives répétées provenant des mêmes IP.
• Options de mitigation rapide : correctifs virtuels temporaires qui neutralisent la vulnérabilité sans nécessiter de mises à jour immédiates des plugins.

Voici des exemples de protections que vous pouvez activer ou demander à votre hébergeur/fournisseur WAF :

• Créer une règle de blocage HTTP POST pour les requêtes aux points de terminaison de plugin qui contiennent <script, onerror=, onload=, document.cookie, window.location, ou évaluer(.
• Rejeter ou assainir tout décalage de type de contenu (par exemple, application/json attendu mais texte/html soumis).
• Ajouter des limites de taux et des vérifications de réputation IP pour les POST de niveau contributeur.

Nous recommandons d'associer ces mesures WAF à un durcissement au niveau du serveur (CSP, désactiver l'édition de fichiers, cookies sécurisés) et à l'hygiène des comptes.

---

Exemples pratiques de mitigation (faites-le vous-même).

Quelques actions concrètes que les administrateurs peuvent appliquer immédiatement :

1. Désactiver le plugin :

   wp plugin désactiver wp-seo-structured-data-schema

   (si la désactivation est acceptable)

2. Empêcher temporairement les contributeurs de soumettre des publications :
   • Utilisez un plugin de gestion des membres ou des rôles pour modifier les capacités des contributeurs ou exiger une modération de contenu.
3. Ajoutez un filtre simple côté serveur (exemple de mu-plugin)

   <?php
       

   Remarque : Il s'agit d'un palliatif défensif. Une bonne désinfection dans le code du plugin est la solution correcte.

4. Bloquez les soumissions contenant des charges utiles évidentes au niveau du serveur web (exemple nginx)
   • Ajoutez des règles d'inspection du corps de la requête qui refusent les requêtes avec <script dans les données de formulaire vers les points de terminaison du plugin. Consultez votre hébergeur pour les détails de mise en œuvre.

---

Renforcement à long terme — leçons apprises

• Traitez tout contenu qui sera re-rendu dans les écrans d'administration avec la même prudence que le contenu frontal. Les administrateurs sont des cibles ; le code qui affiche le contenu utilisateur dans les pages d'administration doit échapper.
• Limitez le nombre d'utilisateurs pouvant créer du contenu sans révision. Appliquez une étape de révision par un éditeur pour tout contenu incluant des données structurées ou du balisage brut.
• Utilisez une approche en couches : code sécurisé, protections WAF, surveillance et planification de la récupération.
• Maintenez un plan de sauvegarde et de récupération à jour qui inclut une vérification régulière et des copies hors site.
• Déployez l'authentification à deux facteurs et imposez des mots de passe forts pour tous les comptes privilégiés.

---

Requêtes de détection et feuille de triche d'analyse judiciaire

• Lister la version du plugin :

  wp plugin get wp-seo-structured-data-schema --field=version

• Trouvez des publications contenant <script:

  Requête wp db "SELECT ID, post_title FROM wp_posts WHERE post_content LIKE '%<script%' ;"

• Trouvez des postmeta avec des scripts :

  wp db query "SELECT meta_id, post_id, meta_key FROM wp_postmeta WHERE meta_value LIKE '%<script%';"

• Options de recherche :

  wp db query "SELECT option_name FROM wp_options WHERE option_value LIKE '%<script%';"

• Liste des comptes contributeurs :

  wp user list --role=contributor --fields=ID,user_login,user_email,user_registered

• Vérifiez les plugins actifs actuels :

  Liste des plugins WordPress --status=actif

Faites toujours une copie des lignes affectées avant de nettoyer pour préserver les preuves.

---

Que faire si vous voyez déjà des signes de compromission ?

1. Changez immédiatement tous les identifiants administratifs et faites tourner les secrets d'application (clés API, jetons OAuth, etc.).
2. Mettez le site en mode maintenance/hors ligne pour éviter d'autres dommages aux utilisateurs.
3. Restaurez à partir d'une sauvegarde propre antérieure à la compromission, après avoir vérifié que la sauvegarde n'est pas infectée.
4. Faites appel à un professionnel de la sécurité si vous ne parvenez pas à déterminer la cause profonde ou si l'attaquant maintient sa persistance.

---

Obtenez une protection gratuite immédiate avec le plan de base WP-Firewall

Titre : Obtenez une protection gratuite immédiate pour votre site avec WP‑Firewall Basic

Si vous souhaitez une protection immédiate et gérée pendant que vous enquêtez et remédiez à cette vulnérabilité, inscrivez-vous au plan WP‑Firewall Basic (gratuit) : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Pourquoi le plan Basic (Gratuit) aide maintenant :

• Protection essentielle : pare-feu géré qui filtre le trafic entrant et bloque les attaques web courantes.
• Bande passante illimitée : protection WAF sans interruptions basées sur le trafic.
• Détection de charges utiles malveillantes : le scanner signale les scripts injectés et les fichiers suspects.
• Atténuation des 10 principales vulnérabilités OWASP : règles ajustées pour réduire l'impact des vulnérabilités web courantes comme le XSS.

Si vous avez besoin d'une réponse plus rapide ou d'un nettoyage automatisé, envisagez de passer à Standard ou Pro pour la suppression automatique des logiciels malveillants, des listes IP personnalisées, des rapports de sécurité mensuels et des correctifs virtuels. Mais pour une défense immédiate pendant que vous enquêtez sur CVE-2026-3604, le plan gratuit vous offre un WAF géré et un scan pour réduire le risque d'exploitation supplémentaire. Inscrivez-vous ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Recommandations finales — actions prioritaires

1. Inventaire : Déterminez si le plugin vulnérable est installé et actif — faites-le maintenant.
2. Désactivez ou restreignez : Si installé et vulnérable, désactivez le plugin ou restreignez l'accès à ses pages et points de terminaison.
3. Verrouillez les comptes : Supprimez les comptes de contributeurs non fiables et forcez les réinitialisations de mot de passe pour les utilisateurs privilégiés.
4. Scannez et nettoyez : Exécutez un scan de logiciels malveillants, inspectez les publications/postmeta/options et supprimez tout script injecté.
5. WAF/correctif virtuel : Déployez des règles WAF pour bloquer les modèles XSS connus pour les points de terminaison du plugin (les clients WP‑Firewall peuvent utiliser nos règles gérées).
6. Surveillez et récupérez : Maintenez une surveillance accrue et restaurez des sauvegardes propres si nécessaire.
7. Appliquez les correctifs dès qu'ils sont disponibles : Appliquez la mise à jour officielle du plugin dès qu'elle est publiée et testez avant de réactiver.

---

Ressources et références

• Référence CVE
• Crédit du chercheur : Muhammad Yudha – DJ (divulgation créditée au chercheur dans l'avis public)

---

Nous savons que ce type de vulnérabilité est inquiétant — le XSS stocké permet à un attaquant d'utiliser même des comptes à faibles privilèges pour causer des dommages considérables. Si vous souhaitez de l'aide pour évaluer l'exposition ou déployer des correctifs virtuels et des protections WAF immédiatement, WP‑Firewall peut vous aider à réduire la fenêtre de risque pendant que vous remédiez. Inscrivez-vous au plan de base (gratuit) et obtenez une protection WAF gérée immédiate : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Si vous préférez, exécutez les requêtes de détection et la liste de contrôle des incidents ci-dessus, et contactez votre fournisseur d'hébergement ou votre équipe de sécurité si vous trouvez des preuves d'exploitation active. La sécurité est superposée : combinez les corrections de code, l'hygiène des rôles et les protections de périmètre pour garder votre site et vos utilisateurs en sécurité.