Nom du plugin	Galerie photo Envira
Type de vulnérabilité	Scripts intersites (XSS)
Numéro CVE	CVE-2026-1236
Urgence	Faible
Date de publication du CVE	2026-03-05
URL source	CVE-2026-1236

Urgent : Ce que les propriétaires de sites WordPress doivent savoir sur la vulnérabilité XSS stockée de la galerie photo Envira (CVE-2026-1236)

Si vous utilisez WordPress et la galerie photo Envira (y compris les éditions Lite/Gratuites ou premium), vous devez lire ceci maintenant.

Une vulnérabilité de Cross‑Site Scripting (XSS) stockée — suivie sous le nom de CVE‑2026‑1236 — affecte les versions de la galerie photo Envira jusqu'à et y compris 1.12.3. Le problème permet à un utilisateur authentifié avec des privilèges d'Auteur (ou supérieurs) d'injecter une charge utile XSS persistante via le paramètre de l'API REST du plugin nommé thème_galerie_justifié. La vulnérabilité a été corrigée dans la galerie photo Envira 1.12.4.

Ci-dessous, j'explique, en termes simples et avec des étapes concrètes, ce que signifie cette vulnérabilité, comment les attaquants pourraient en abuser, comment la détecter et la mitiger, et comment WP‑Firewall vous protège — y compris ce que vous pouvez faire aujourd'hui si vous ne pouvez pas mettre à jour immédiatement.

Ceci est écrit d'après une expérience de première main en ingénierie de sécurité WordPress — des conseils pratiques et sans fioritures pour les propriétaires de sites, les agences et les équipes de sécurité.

---

Résumé rapide (pour les propriétaires de sites qui veulent les titres)

• Une vulnérabilité XSS stockée existe dans la galerie photo Envira ≤ 1.12.3 via le paramètre de l'API REST thème_galerie_justifié.
• Identifiant CVE : CVE‑2026‑1236. Correctif : galerie photo Envira 1.12.4.
• Privilège requis : utilisateur authentifié avec au moins le rôle d'Auteur.
• Impact : XSS stocké (persistant). Un attaquant peut injecter un script qui s'exécute dans les navigateurs des visiteurs — vol de session possible, manipulation de présentation, redirections, facilitation de clickjacking, ou pivot vers des actions côté serveur via l'interaction d'un utilisateur privilégié.
• CVSS (rapporté) : 5.9 (moyen). L'exploitation nécessite qu'un Auteur déclenche ou interagisse avec le contenu injecté dans de nombreux scénarios réalistes, mais l'attaque reste pertinente pour les sites avec plusieurs auteurs, contributeurs ou éditeurs non fiables.
• Actions immédiates : mettre à jour le plugin vers 1.12.4 (recommandé), appliquer un WAF/correctif virtuel si vous ne pouvez pas mettre à jour, limiter les privilèges d'Auteur, auditer les charges utiles injectées, scanner et nettoyer tout contenu injecté.

---

Pourquoi cela importe — le XSS stocké est dangereux même lorsque le score semble “ moyen ”

Le XSS stocké signifie qu'un script malveillant est enregistré sur le serveur (par exemple, dans un enregistrement de base de données, un paramètre de plugin ou un postmeta) et servi à tout utilisateur qui consulte la page affectée. Contrairement au XSS réfléchi qui nécessite qu'une victime clique sur un lien conçu, le XSS stocké peut injecter des charges utiles qui persistent entre les visites et affectent plusieurs utilisateurs.

Même si le CVSS ici est dans la plage moyenne, le XSS stocké est particulièrement utile pour les attaquants pour :

• Voler des cookies de session ou des jetons d'authentification des éditeurs et des administrateurs de site (si les cookies manquent de portée HttpOnly/sécurisée).
• Modifier le contenu du site (créer des publications/pages, injecter du spam ou des publicités).
• Ajouter des portes dérobées ou des utilisateurs administrateurs malveillants en interagissant indirectement avec des interfaces privilégiées.
• Propager des logiciels malveillants (injecter du JavaScript malveillant pour servir des charges utiles malveillantes aux utilisateurs finaux).
• Détourner le SEO en injectant des liens cachés ou du contenu masqué.

Le hic : la vulnérabilité nécessite qu'un Auteur authentifié (ou supérieur) soumette la charge utile — ce qui rend les sites avec plusieurs éditeurs, contributeurs ou auteurs invités particulièrement à risque. De nombreuses petites agences et équipes éditoriales pratiques donnent un accès de niveau Auteur pour plus de commodité, ce qui augmente l'exposition.

---

Comment la vulnérabilité fonctionne (niveau élevé, pas de code d'exploitation)

• L'API REST de la galerie photo Envira accepte un paramètre appelé thème_galerie_justifié.
• Le plugin n'a pas réussi à suffisamment assainir ou échapper ce paramètre lors de son stockage ou de son rendu.
• Un Auteur authentifié écrit une valeur malveillante dans thème_galerie_justifié via l'API REST.
• Cette valeur malveillante est persistée dans la base de données et est ensuite affichée sur une page ou un écran d'administration dans un contexte où elle est exécutée en tant que JavaScript dans le navigateur (XSS stocké).
• Parce que la charge utile est stockée sur le serveur et affichée à d'autres utilisateurs, tout visiteur visualisant la galerie ou une page d'administration qui rend la valeur pourrait exécuter le script injecté.

Nous évitons de publier du code de preuve de concept — la divulgation responsable et les détails d'exploitation sont réservés aux chercheurs en sécurité et aux fournisseurs. Si vous pensez que votre site peut être impacté, agissez immédiatement sur la détection et l'atténuation.

---

Versions affectées et remédiation

• Affecté : versions de la galerie photo Envira <= 1.12.3
• Corrigé dans : galerie photo Envira 1.12.4
• CVE : CVE‑2026‑1236

Priorité de remédiation : Si vous exécutez une version de la galerie photo Envira ≤ 1.12.3, mettez à jour vers 1.12.4 immédiatement. Si vous ne pouvez pas mettre à jour en raison de contraintes de compatibilité ou de mise en scène, appliquez un patch virtuel via votre pare-feu d'application Web et suivez les étapes ci-dessous.

---

Étapes immédiates — une liste de contrôle actionable (faites cela maintenant)

1. Mettez à jour la galerie photo Envira vers la version 1.12.4 (ou ultérieure)
   • Le fournisseur du plugin a publié un correctif. La mise à jour est la remédiation la plus directe et fiable.
   • Testez les mises à jour sur une copie de mise en scène d'abord si vous avez des thèmes/code personnalisé qui peuvent dépendre d'une version antérieure.
2. Si la mise à jour n'est pas immédiatement possible — appliquez WAF/patch virtuel
   • Configurez votre pare-feu pour bloquer les demandes qui tentent de définir thème_galerie_justifié un contenu suspect contenant <script, onerror=, JavaScript :, document.cookie, ou des équivalents encodés.
   • Ajoutez des règles qui bloquent spécifiquement les demandes POST/PATCH vers les routes REST API du plugin portant de telles charges utiles.
3. Limitez les privilèges des utilisateurs
   • Réduisez le nombre d'utilisateurs avec des rôles Auteur+. Lorsque cela est possible, utilisez des rôles Contributeur ou des rôles personnalisés avec le minimum de privilèges.
   • Supprimez ou auditez les comptes utilisateurs inutilisés.
   • Appliquez des mots de passe forts et activez l'authentification à deux facteurs pour les comptes avec des privilèges élevés.
4. Scannez à la recherche de contenu injecté (recherchez et nettoyez)
   • Utilisez WP‑CLI ou votre outil de base de données pour rechercher des preuves de charges utiles injectées dans les options, postmeta et posts.
   • Exemples de recherche typiques :
     • WP‑CLI : wp db query "SELECT * FROM wp_postmeta WHERE meta_value LIKE '%justified_gallery_theme%';"
     • SQL : SELECT * FROM wp_postmeta WHERE meta_value REGEXP '<script|onerror|javascript:';
   • Recherchez également wp_posts.post_content et wp_options.option_value des marqueurs de script suspects.
5. Inspectez les journaux et l'activité récente
   • Consultez les journaux d'accès à l'API REST et les journaux d'activité des utilisateurs pour identifier qui a écrit la valeur et quand.
   • Vérifiez les adresses IP des utilisateurs et les horaires pour des motifs suspects.
6. Faites tourner les identifiants et les secrets si vous trouvez des preuves de compromission du compte administrateur
   • Réinitialisez les mots de passe pour tous les comptes impactés (surtout s'ils ont interagi avec le point de terminaison du plugin).
   • Faites tourner toutes les clés API ou les identifiants qui pourraient être stockés sur le site.
7. Surveillez et planifiez un suivi.
   • Continuez à surveiller le site pour des signes de compromission supplémentaire ou de charges utiles récurrentes pendant plusieurs semaines.
   • Planifiez des analyses récurrentes.

---

Comment détecter l'exploitation — techniques de détection pratiques.

La détection des XSS stockés peut être délicate car la charge utile est souvent codée ou obfusquée pour échapper aux scanners naïfs. Voici des méthodes pratiques pour faire ressortir une exploitation potentielle :

• Grep ou interrogez votre base de données pour des marqueurs de script courants :
  • wp_postmeta.meta_value LIKE '%<script%'
  • wp_posts.post_content LIKE '%<script%'
  • wp_options.option_value LIKE '%<script%'
  • meta_value REGEXP 'onerror|onload|javascript:|document.cookie|innerHTML'
• Utilisez WP‑CLI pour extraire des lignes suspectes pour un examen manuel :
  • wp db query "SELECT meta_id, post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%';"
• Auditez les changements récents de l'API REST :
  • Si vous enregistrez les requêtes de l'API REST (ou si vous avez un plugin d'audit), filtrez les points de terminaison contenant “envira” ou l'ID de la galerie et examinez les charges utiles.
• Utilisez un scanner HTML / scanner XSS (hébergé ou sur site) pour explorer les pages et identifier les points d'injection DOM.
• Inspectez les pages de la galerie dans un environnement de staging : visualisez la source de la galerie et recherchez des scripts en ligne inattendus ou des gestionnaires d'événements.

Si vous trouvez du contenu suspect, exportez-le vers un environnement sûr pour un examen judiciaire et supprimez/nettoyez les valeurs en production uniquement après analyse et sauvegardes.

---

Comment nettoyer un site après détection.

1. Prenez un instantané judiciaire
   • Faites une sauvegarde complète (fichiers + DB) et stockez-la hors ligne avant d'apporter des modifications.
   • Exporter les lignes suspectes pour enquête.
2. Supprimer les charges utiles malveillantes
   • Nettoyer manuellement les lignes/options/publications méta affectées, en remplaçant les valeurs par des valeurs par défaut sûres.
   • Ne pas simplement supprimer le plugin ou les entrées de plugin sans comprendre les dépendances.
3. Vérifier les portes dérobées et la persistance
   • Rechercher dans les fichiers de thème et les téléchargements des fichiers PHP récemment modifiés ou du code obfusqué.
   • Vérifier dans wp-content/uploads des fichiers .php inattendus (les téléchargements ne devraient pas contenir de PHP exécutable).
   • Scanner le système de fichiers et la base de données avec un scanner de malware fiable.
4. Mettez à jour et renforcez
   • Mettre à jour le plugin, le cœur de WordPress et d'autres plugins/thèmes vers leurs dernières versions.
   • Renforcer le site comme décrit ci-dessous.
5. Faire tourner les identifiants et réémettre les secrets
   • Forcer les réinitialisations de mot de passe pour les utilisateurs qui pourraient avoir été ciblés.
   • Faire tourner les clés API, les jetons OAuth ou d'autres identifiants.
6. Ré-auditer et surveiller
   • Re-scanner et surveiller les journaux pour toute réapparition.
   • Continuer à surveiller pendant une période (30 à 90 jours) pour s'assurer que l'attaquant n'a plus de persistance.

---

Atténuations techniques recommandées (détaillées)

Ci-dessous se trouvent des contrôles techniques qui aident à renforcer votre site WordPress contre cette classe de vulnérabilité.

A. Pare-feu d'application Web (WAF) / Patching virtuel

Si vous ne pouvez pas mettre à niveau immédiatement, le patching virtuel via un WAF est la mesure de protection la plus rapide.

Modèles de détection suggérés (exemples — adaptez à la syntaxe de votre WAF) :

• Bloquer les requêtes POST/PATCH/PUT où le paramètre body thème_galerie_justifié contient des indicateurs XSS :
  • Regex pour bloquer les balises script évidentes et les gestionnaires d'événements :
    • (?i)(<\s*script\b|on(error|load|click|mouseover)\s*=|javascript:|document\.cookie|innerHTML|<\s*iframe\b)
• Bloquer les requêtes vers les points de terminaison REST qui contiennent des charges utiles suspectes :
  • Si le plugin expose des espaces de noms REST comme /wp-json/envira/ ou /wp-json/envira-gallery/, créez une règle ciblée pour toute requête vers cet espace de noms avec un contenu suspect.
• Exemple de règle de style ModSecurity (conceptuel) :

  SecRule REQUEST_BODY "@rx (?i)(<\s*script\b|onerror=|javascript:|document\.cookie)" "id:900001,deny,log,msg:'Bloquer la tentative XSS justifiée_gallery_theme d'envira',phase:2"

Important: Concevez et testez les règles avec soin pour éviter les faux positifs qui bloquent les opérations légitimes. Commencez par le mode de surveillance/journalisation, puis passez au blocage.

B. Restreindre l'accès à l'API REST

• Restreindre les points de terminaison REST du plugin aux utilisateurs authentifiés avec des vérifications de capacité appropriées (les développeurs peuvent ajouter des vérifications côté serveur au plugin ou via du code personnalisé).
• Si le point de terminaison n'est pas requis publiquement, restreignez-le par capacité ou désactivez-le :
  • Exemple : dans un mu-plugin ou un thème fonctions.php, ajoutez des filtres pour vérifier L'utilisateur actuel peut modifier les publications. avant de permettre la route.

C. Politique de sécurité du contenu (CSP)

• Implémentez ou renforcez un CSP pour réduire l'impact XSS :
  • Utilisez un en-tête CSP pour interdire les scripts en ligne et limiter les sources de scripts aux hôtes de confiance :

    Content-Security-Policy : default-src 'self' ; script-src 'self' https://trusted-cdn.example.com ; object-src 'none' ; base-uri 'self' ; frame-ancestors 'none' ;

  • Remarque : la mise en œuvre d'un CSP strict peut nécessiter un déploiement progressif et des tests car de nombreux plugins et thèmes dépendent des scripts en ligne.

D. Échappement et assainissement de la sortie (correction de développement)

• Assurez-vous que les auteurs de plugins (ou votre code personnalisé) utilisent un échappement approprié (esc_html(), esc_attr(), wp_kses_post()) pour les valeurs contrôlées par l'utilisateur avant de les afficher sur les pages.
• Assainissez les entrées au moment de l'écriture (assainir_champ_texte, wp_kses avec des balises autorisées) et échappez lors de la sortie.

E. Principe du moindre privilège

• Convertissez les auteurs qui ne soumettent que du contenu au rôle de Contributeur, qui ne peut pas publier ou effectuer certains changements REST.
• Mettez en œuvre la segmentation des rôles : séparez les auteurs de contenu des constructeurs de sites.

F. Renforcement de l'environnement administrateur

• Désactivez l'édition de fichiers de thème/plugin via définir('DISALLOW_FILE_EDIT', vrai);
• Utilisez l'authentification à deux facteurs pour tous les comptes Éditeur+ et Auteur+.
• Appliquez des politiques de mot de passe fortes et une rotation périodique pour les utilisateurs privilégiés.

---

Protection WP‑Firewall : comment nous aidons

Chez WP‑Firewall, nous nous concentrons sur des protections pratiques et immédiates qui vous permettent de rester en ligne et en sécurité pendant que vous corrigez.

• WAF géré avec patching virtuel : nous pouvons mettre en œuvre des règles ciblées qui bloquent les tentatives de définir thème_galerie_justifié des valeurs dangereuses, empêchant l'exploitation même si la version du plugin reste temporairement non corrigée.
• Analyse et détection de logiciels malveillants : notre scanner recherche des injections de scripts suspects dans des emplacements de stockage courants (postmeta, options, publications) et signale les charges utiles XSS probablement stockées.
• Atténuation des 10 principales vulnérabilités OWASP : Nos ensembles de règles par défaut atténuent les vecteurs d'injection courants et les charges utiles XSS en bloquant les motifs suspects dans les entrées soumises via les interfaces REST et administratives.
• Conseils sur la réponse aux incidents et assistance à la nettoyage : Si vous découvrez des charges utiles injectées, nous fournissons des conseils de remédiation étape par étape et une assistance de nettoyage gérée en option pour les clients des plans premium.

Si vous préférez agir de manière pratique, notre documentation explique comment configurer des règles personnalisées pour les charges utiles de l'API REST et détecter les XSS stockés dans les bases de données WordPress.

---

Idées d'exemples de règles WAF (adaptez à votre système)

Ci-dessous se trouvent des règles conceptuelles pour bloquer des vecteurs d'attaque évidents. Adaptez-les à votre environnement et testez d'abord en mode de surveillance.

1. Bloquez les requêtes contenant un script en ligne dans le paramètre justifié :
   • Condition : REQUEST_METHOD dans (POST, PUT, PATCH) ET REQUEST_BODY contient thème_galerie_justifié
   • Alors : Si REQUEST_BODY correspond à l'expression régulière (?i)(<\s*script\b|on(error|load|click|mouseover)\s*=|javascript:|document\.cookie), enregistrez et bloquez.
2. Bloquez l'injection de script encodé :
   • Décodez les encodages courants et bloquez les motifs qui incluent des caractères encodés pour <script ou JavaScript :.
   • Exemple : recherchez script ou \x3cscript variantes.
3. Limitez le taux des requêtes API REST suspectes pour un seul utilisateur/IP afin de prévenir les tentatives automatisées.

Encore une fois : ne copiez pas ces règles textuellement en production — adaptez-les selon le langage de votre WAF.

---

Liste de contrôle de durcissement pour les agences et les hébergeurs (opérationnel)

• Assurez-vous que toutes les mises à jour de plugins/thèmes sont régulièrement appliquées ; maintenez un environnement de staging pour des tests de compatibilité rapides.
• Appliquez le principe du moindre privilège et minimisez les privilèges d'auteur — utilisez Contributeur lorsque cela est possible.
• Surveillez et auditez l'activité de l'API REST et activez la journalisation pour les points de terminaison critiques.
• Ajoutez des règles WAF qui ciblent les charges utiles REST suspectes et trouvez un équilibre entre le blocage et les faux positifs.
• Effectuez des analyses périodiques de la base de données pour détecter les marqueurs de script.
• Maintenez des sauvegardes fréquentes et vérifiez les procédures de restauration.
• Formez le personnel éditorial à éviter de cliquer sur des liens inconnus et à être conscient de l'ingénierie sociale.
• Envisagez des mises à jour automatiques des plugins pour les plugins à faible risque et établissez une fenêtre de test pour les plugins critiques.

---

Plan d'intervention en cas d'incident (version abrégée)

1. Contenir : Mettez le site en mode maintenance si une exploitation active est suspectée.
2. Instantané : Capturez une sauvegarde complète et des journaux pour une analyse judiciaire.
3. Identifier : Recherchez l'indicateur de compromission (IOC) — valeurs méta suspectes, activité des utilisateurs, fichiers modifiés.
4. Nettoyer : Supprimez les charges utiles, fermez les portes dérobées, mettez à jour tous les plugins vulnérables vers des versions corrigées.
5. Récupérer : Restaurez à un point propre connu si le nettoyage n'est pas pratique, mettez à jour tous les identifiants.
6. Examiner : Revue post-incident — ce qui a mal tourné, comment éviter la récurrence.
7. Notifier : Si des données clients ou des comptes administratifs sensibles ont été affectés, informez les parties prenantes selon votre politique.

---

Foire aux questions

Q : “Je ne donne l'accès Auteur qu'à des collègues de confiance. Dois-je encore m'inquiéter ?”
UN: Oui. Les menaces internes, les comptes d'auteur compromis et l'ingénierie sociale sont réalistes. Si un Auteur peut accéder aux points de terminaison REST, l'exploitation est possible. Renforcer la sécurité de connexion (2FA) et surveiller les écritures API réduit le risque.

Q : “Mon site ne montre aucun contenu malveillant — dois-je quand même mettre à jour ?”
UN: Oui. Le patching élimine la vulnérabilité et empêche une exploitation future. Même si votre site est propre aujourd'hui, les vulnérabilités non corrigées sont des cibles futures.

Q : “Puis-je compter sur le WAF de mon hébergeur pour me protéger ?”
UN: Un WAF d'hébergeur aide, mais vous avez besoin de règles qui détectent spécifiquement les modèles pertinents pour cette vulnérabilité. Combinez la protection de l'hôte avec des mises à jour de plugins, un renforcement des rôles et des analyses pour le meilleur résultat.

---

Signes que votre site pourrait déjà avoir été exploité.

• Comptes administrateurs/éditeurs inattendus créés ou modifiés.
• Publications/pages inexpliquées ajoutées (souvent avec des liens ou iframes étranges).
• Redirections inattendues lors de la visite des pages frontales.
• Nouveaux fichiers ou fichiers modifiés dans les répertoires de thèmes ou de plugins.
• Découverte de blocs dans des lignes de base de données où aucun ne devrait être présent.

Si vous découvrez des preuves, prenez-les au sérieux — suivez les étapes de réponse à l'incident ci-dessus.

---

Recommandations finales — un plan pragmatique priorisé

1. Mettez à jour Envira Photo Gallery vers 1.12.4 immédiatement.
2. Appliquez des règles de patch virtuel/courte durée WAF (surtout si vous ne pouvez pas mettre à jour aujourd'hui).
3. Auditez et réduisez les privilèges Author+ ; activez l'authentification à deux facteurs pour les éditeurs et les administrateurs.
4. Effectuez une analyse complète des logiciels malveillants et du contenu ; recherchez des marqueurs de script dans la base de données.
5. Renforcez l'accès à l'API REST et mettez en œuvre CSP lorsque cela est possible.
6. Planifiez des analyses régulières et des examens de sécurité périodiques.

Ces étapes réduiront votre risque immédiat et rendront votre site résilient contre des vulnérabilités similaires de plugins à l'avenir.

---

Protégez votre site avec une base rapide et gratuite — WP‑Firewall Basic (Gratuit)

Essayez WP‑Firewall Basic : protection essentielle à coût nul

Si vous souhaitez une sécurité de base gérée immédiate pendant que vous travaillez sur les correctifs et le renforcement, WP‑Firewall Basic (Gratuit) fournit des défenses essentielles que vous pouvez activer en quelques minutes :

• Pare-feu géré et WAF adaptés pour WordPress
• Bande passante illimitée (pas d'inquiétude concernant le débit WAF)
• Analyse des logiciels malveillants pour détecter des injections suspectes
• Atténuations ciblées sur les risques OWASP Top 10, y compris les protections XSS

Ce plan gratuit est idéal pour les propriétaires de sites qui ont besoin d'un filet de sécurité fiable tout en testant des mises à jour et en appliquant des corrections. Inscrivez-vous et activez les protections gratuites ici : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

(Si vous avez besoin plus tard d'une suppression automatique de logiciels malveillants, de listes noires/blanches d'IP, de patchs virtuels automatiques ou d'un nettoyage géré, nos plans Standard et Pro offrent des couches de protection supplémentaires.)

---

Réflexions finales de l'équipe WP‑Firewall

Les vulnérabilités des plugins comme CVE‑2026‑1236 sont une réalité inconfortable de l'écosystème WordPress — mais elles sont gérables. Les meilleurs résultats proviennent de défenses en couches : correction rapide, utilisation intelligente d'un WAF/patching virtuel, moindre privilège et surveillance continue.

Si vous avez besoin d'aide pour prioriser la remédiation ou si vous souhaitez un patch virtuel ciblé pendant que vous mettez à jour, l'équipe de WP‑Firewall peut vous aider à mettre en œuvre des règles et des analyses sur mesure afin que vous puissiez rester en ligne et en sécurité sans longues interruptions.

Restez en sécurité et agissez maintenant — mettez à jour Envira Photo Gallery, scannez votre site et protégez les utilisateurs privilégiés.

— Équipe de sécurité WP-Firewall

---

Annexe : Commandes et requêtes utiles (exemples)

• Recherche WP‑CLI DB pour postmeta suspect :

  wp db query "SELECT meta_id, post_id, meta_key, meta_value FROM wp_postmeta WHERE meta_value LIKE '%<script%' OR meta_value LIKE '%javascript:%' LIMIT 100;"

• SQL pour trouver des options suspectes :

  SELECT option_id, option_name, option_value FROM wp_options WHERE option_value REGEXP '<script|onerror|javascript:|document.cookie' LIMIT 100;

• Filtre de journal REST rapide (selon votre journalisation) :

  Filtrer les journaux pour les URL contenant /wp-json/ et les corps de requête contenant thème_galerie_justifié.

Remarque : ajustez les préfixes de table si votre installation n'utilise pas wp_.

---

Si vous souhaitez un plan d'atténuation sur mesure pour votre site (règles WAF personnalisées, déploiement de patchs virtuels ou nettoyage guidé), répondez avec le type d'environnement d'hébergement (partagé, géré, VPS) et si vous avez un environnement de staging — nous fournirons des instructions étape par étape.