Nom du plugin	Perfmatters
Type de vulnérabilité	Suppression de fichiers arbitraire
Numéro CVE	CVE-2026-4350
Urgence	Haut
Date de publication du CVE	2026-04-05
URL source	CVE-2026-4350

CVE-2026-4350 — Suppression de fichiers arbitraire dans Perfmatters (<= 2.5.9.1) : Ce que vous devez savoir

Le 3 avril 2026, une vulnérabilité de haute gravité (CVE-2026-4350) affectant le plugin WordPress Perfmatters a été divulguée publiquement. La faille permet à un utilisateur authentifié avec des privilèges d'abonné de déclencher la suppression de fichiers sur un site exécutant des versions vulnérables (<= 2.5.9.1). Une version corrigée (2.6.0) est disponible et doit être appliquée immédiatement.

Dans cet article long, nous vous guiderons à travers :

• Ce qu'est la vulnérabilité et pourquoi elle est dangereuse
• Comment un attaquant pourrait l'exploiter (conceptuellement)
• Des mesures d'atténuation à court terme que vous pouvez appliquer maintenant (y compris les règles WAF)
• Comment récupérer et durcir votre environnement
• Recommandations de surveillance et de détection
• Comment WP-Firewall peut aider à protéger les sites (y compris notre plan gratuit)

Ce guide est rédigé à partir d'une expérience pratique et réelle de protection des sites WordPress. Notre objectif est d'aider les propriétaires de sites et les administrateurs à prendre des mesures immédiates et efficaces sans exposer les étapes d'exploitation qui accéléreraient les attaques.

---

Résumé rapide

• Composant affecté : plugin WordPress Perfmatters
• Versions concernées : <= 2.5.9.1
• Corrigé dans : 2.6.0
• CVE : CVE-2026-4350
• Privilège requis : Abonné (authentifié)
• Risque : Élevé — suppression arbitraire de fichiers sur le site
• CVSS (tel que publié) : 8.1

---

Pourquoi cette vulnérabilité est importante

La suppression de fichiers arbitraire est fondamentalement destructive. Si un attaquant peut supprimer :

• des fichiers de base de WordPress, des fichiers de plugin ou des modèles de thème, il peut casser le site.
• .htaccess ou fichiers de configuration du serveur web, ils peuvent modifier le routage/la sécurité du site.
• wp-config.php ou fichiers sous wp-content, ils peuvent affecter la configuration, l'accès aux données ou les workflows d'escalade de privilèges.
• Téléchargements et médias, ils peuvent endommager le contenu et les opérations commerciales.

Une vulnérabilité qui permet à un compte Abonné de supprimer des fichiers est particulièrement préoccupante car l'Abonné est un rôle à très faible privilège qui est couramment disponible sur de nombreux sites (par exemple, pour les clients, les commentateurs ou les sites permettant l'enregistrement des utilisateurs). Les attaquants peuvent soit abuser des comptes existants, soit enregistrer de nouveaux comptes (si l'enregistrement est activé) pour effectuer des actions destructrices.

Cette classe de vulnérabilité relève du “ Contrôle d'accès brisé ” — une catégorie centrale de l'OWASP — car le plugin ne vérifie pas correctement que l'utilisateur authentifié dispose de privilèges suffisants avant d'effectuer la suppression de fichiers.

---

Ce que fait la vulnérabilité (conceptuel, pas de code d'exploitation)

À un niveau élevé, le plugin vulnérable expose un point de terminaison fonctionnel qui accepte un paramètre (nommé “ delete ” dans les rapports publics). Lorsqu'une requête avec certaines valeurs est soumise, le code côté serveur du plugin effectue des opérations de suppression de fichiers en utilisant le(s) paramètre(s) fourni(s) sans validation adéquate et sans vérifier que l'appelant a une capacité suffisamment élevée (niveau administrateur) pour effectuer des actions destructrices.

Points clés :

• Le serveur reçoit un nom de fichier/chemin via un paramètre de requête.
• Le plugin appelle une fonction de suppression de système de fichiers (par exemple, PHP unlink) en utilisant cette valeur.
• Le plugin manque de forte sanitation des chemins et/ou impose des restrictions faibles, permettant la suppression de fichiers en dehors du répertoire prévu.
• Les vérifications de permission du plugin sont inadéquates : le code permet aux comptes à faible privilège (Abonné) de déclencher la suppression.

Comme cela nécessite une authentification, un attaquant ne peut pas le déclencher en tant que visiteur anonyme. Mais sur de nombreux sites, les attaquants peuvent :

• Créer des comptes et se voir attribuer le statut d'Abonné par défaut (auto-inscription).
• Obtenir des comptes abonnés par le biais de stuffing de crédentiels, de listes achetées ou de crédentiels précédemment compromis.
• Compromettre un compte abonné existant en utilisant le phishing ou d'autres techniques d'ingénierie sociale.

Une fois qu'un utilisateur authentifié à faible privilège peut supprimer des fichiers, il peut casser le site et couvrir ses traces, souvent avant que les propriétaires du site ne s'en aperçoivent.

---

Scénarios d'exploitation réalistes

Pensez aux scénarios réels suivants :

1. Site d'inscription ouvert
   Un blog ou un site d'adhésion qui permet à quiconque de s'inscrire acceptera des milliers de comptes. Un attaquant enregistre un compte abonné, appelle le point de terminaison du plugin et supprime des fichiers.
2. Identifiants d'abonné compromis
   Un abonné réutilise un mot de passe compromis — l'attaquant se connecte et utilise le point de terminaison destructeur.
3. Abus interne / compte malveillant
   Un utilisateur mécontent avec des privilèges d'abonné endommage intentionnellement le site.
4. Attaques en chaîne
   Un attaquant utilise la suppression de fichiers pour enlever des fichiers de plugin ou de thème, provoquant des erreurs. Il exploite ensuite le chaos pour déployer des changements intrusifs supplémentaires ou des portes dérobées.

Parce que la suppression de fichiers critiques peut provoquer une interruption de service, cette vulnérabilité est attrayante pour les attaquants qui souhaitent un impact rapide (défiguration, temps d'arrêt, extorsion).

---

Indicateurs de compromission (IoCs) et points de détection

Si votre site a pu être ciblé, recherchez les signes suivants :

• Fichiers multimédias manquants dans wp-content/uploads ou fichiers de plugin/thème manquants
• Erreurs 500 soudaines ou écrans blancs après des requêtes aux points de terminaison administratifs
• Messages d'erreur dans les journaux PHP ou serveur indiquant des inclusions échouées ou des fichiers manquants
• 404 inattendus pour des fichiers/chemins de système de fichiers qui existaient auparavant
• Entrées de journal montrant des requêtes authentifiées aux points de terminaison de plugin avec un paramètre “ delete ” ou similaire
• Journaux d'audit WordPress (s'ils sont présents) montrant des opérations de fichiers initiées par des utilisateurs à faible privilège
• Activité de compte inhabituelle pour les utilisateurs abonnés — nouveaux comptes créés à peu près au même moment que les suppressions de fichiers

Où vérifier :

• Journaux d'accès/d'erreur du serveur web (nginx, Apache)
• Journaux PHP-FPM et journal d'erreurs PHP
• Plugins d'activité ou de journal d'audit WordPress (s'ils sont installés)
• Gestionnaire de fichiers du panneau de contrôle de l'hôte (horodatages de modification de fichiers)
• Surveillance de l'intégrité des fichiers (si vous avez des outils de somme de contrôle en place)

Si vous voyez des signes de suppression, mettez le site hors ligne (mode maintenance) et suivez les étapes de récupération ci-dessous.

---

Actions immédiates (premières 1 à 24 heures)

1. Mettez à jour maintenant
   Mettez à jour le plugin Perfmatters vers la version corrigée (2.6.0 ou ultérieure) immédiatement. C'est la seule solution fiable à long terme.
2. Si vous ne pouvez pas appliquer le correctif immédiatement, appliquez des mesures d'atténuation.
   a. Désactivez temporairement le plugin (si possible) jusqu'à ce que vous puissiez le mettre à jour.
   b. Si la désactivation n'est pas possible, désactivez l'enregistrement des utilisateurs publics et verrouillez tous les comptes d'abonnés (mettez-les en attente ou changez les mots de passe).
   c. Appliquez des règles WAF ou des règles au niveau du serveur pour bloquer les demandes contenant le paramètre vulnérable ou vers le point de terminaison spécifique du plugin — voir les directives WAF ci-dessous.
3. Vérifier les comptes utilisateurs
   Forcez la réinitialisation des mots de passe pour tous les comptes avec des privilèges d'abonné ou supérieurs ; examinez les comptes récemment créés et supprimez les comptes suspects.
4. Sauvegarde et instantané.
   Prenez une sauvegarde/snapshot complète du système de fichiers et de la base de données avant d'apporter des modifications de remédiation — cela permet l'investigation et la récupération.
5. Vérifiez les journaux et scannez.
   Examinez les journaux du serveur et de WordPress pour une activité suspecte (demandes au plugin, suppressions de fichiers). Exécutez un scan de malware pour détecter d'autres manipulations.
6. Renforcer les permissions des fichiers
   Assurez-vous que des fichiers comme wp-config.php ne sont pas modifiables par l'utilisateur du serveur web lorsque cela est pratique ; assurez-vous que les fichiers du plugin et du noyau ne sont pas accessibles en écriture par tous. Remarque : des permissions trop strictes peuvent casser les mises à jour du plugin ; testez soigneusement.

---

Étapes de remédiation recommandées à long terme.

1. Appliquez les correctifs rapidement et maintenez les plugins à jour.
   Exécutez toujours des versions à jour et appliquez rapidement les correctifs pour les plugins qui effectuent des opérations sur les fichiers.
2. Principe du moindre privilège pour les rôles d'utilisateur
   Considérez si les abonnés doivent exister sur votre site. Si ce n'est pas nécessaire, désactivez l'enregistrement ou changez les nouveaux utilisateurs en un rôle encore plus limité via la gestion des rôles.
3. Renforcement des rôles et examen des capacités.
   Utilisez des plugins ou des politiques pour auditer et limiter les capacités des rôles par défaut. Supprimez les capacités inutiles du rôle d'abonné.
4. Authentification à deux facteurs (2FA)
   Appliquez l'authentification à deux facteurs (2FA) pour les comptes avec des capacités élevées, et appliquez la 2FA pour tous les utilisateurs lorsque cela est pratique afin de réduire le risque de prise de contrôle de compte.
5. Restreignez les points de terminaison administratifs du plugin.
   Limitez l'accès à admin-ajax ou aux points de terminaison du plugin aux utilisateurs authentifiés avec des capacités applicables. Évitez d'exposer les actions de gestion de fichiers via des points de terminaison accessibles au public.
6. Mettez en œuvre une surveillance de l'intégrité des fichiers (FIM)
   Utilisez un système d'intégrité des fichiers pour détecter et alerter sur des suppressions ou des modifications de fichiers inattendues. Cela réduit le temps entre la compromission et la détection.
7. Sauvegardes régulières et tests de restauration
   Avoir des sauvegardes automatisées hors site avec des tests de restauration périodiques. La capacité de restaurer rapidement réduit considérablement le temps d'arrêt après des événements destructeurs.
8. Utilisez le patching virtuel (WAF)
   Lorsque le patching immédiat n'est pas possible, un WAF peut bloquer les modèles et les requêtes malveillants ciblant la vulnérabilité. Voir la section suivante pour des règles WAF pratiques.

---

WAF et patching virtuel : atténuations pratiques que vous pouvez appliquer maintenant

Un pare-feu d'application Web (WAF) fournit une protection puissante à court terme via le patching virtuel — bloquant les requêtes qui correspondent à un modèle d'attaque avant qu'elles n'atteignent le code vulnérable. Voici des stratégies WAF pratiques qui sont efficaces pour cette vulnérabilité. Celles-ci sont écrites comme des règles conceptuelles ; votre console de gestion WAF acceptera des conditions équivalentes.

Important: ces règles sont des exemples défensifs — elles n'incluent pas de charges utiles d'exploitation. Elles sont conçues pour prévenir les modèles d'abus courants autour des points de terminaison de suppression de fichiers.

1. Bloquer les requêtes qui incluent un paramètre “delete” contre les points de terminaison du plugin (points de terminaison admin ou AJAX) à moins que l'utilisateur connecté n'ait des capacités d'administrateur.
   • Pseudo-règle :
     Condition : la requête HTTP inclut un paramètre nommé “delete” (GET ou POST) ET l'URI cible correspond au(x) chemin(s) du plugin ou admin-ajax.
     Action : Bloquer / Challenger / Retourner 403 à moins que la session n'indique une capacité d'administrateur.
2. Prévenir le parcours de chemin et les valeurs de chemin absolu dans les paramètres destinés à référencer des fichiers dans un répertoire de téléchargements.
   • Pseudo-règle :
     Condition: parameter value contains “../” or starts with “/” or contains drive-letter patterns (e.g., “C:\”) or contains encoded traversal (%2e%2e, %2f%5c).
     Action : Bloquer la requête.
3. Limiter l'accès aux points de terminaison administratifs du plugin par IP (lorsque cela est possible).
   • Pseudo-règle :
     Condition : requête à /wp-admin/ ou admin-ajax.php avec un paramètre d'action spécifique au plugin ET l'IP du client n'est pas dans la plage admin-office ou n'est pas authentifiée en tant qu'admin.
     Action : Bloquer ou retourner 403.
4. Bloquer les requêtes POST où le référent ne correspond pas à votre site et contient un paramètre de suppression de fichier.
   • Pseudo-règle :
     Condition : requête POST avec un paramètre similaire à delete ET l'en-tête Referer manquant ou ne correspondant pas à l'hôte du site.
     Action : Bloquer.
5. Appliquer une limitation de taux sur les abonnés authentifiés.
   • Pseudo-règle :
     Condition : Un utilisateur authentifié avec le rôle d'abonné effectue des requêtes correspondant aux points de terminaison du plugin plus de X fois en Y minutes.
     Action : Ralentir ou bloquer.
6. Mettre sur liste blanche les formats de paramètres sûrs (approche de liste autorisée).
   • Pseudo-règle :
     Condition : Si un paramètre est censé être un ID numérique, n'autoriser que les caractères 0-9 ; si des noms de fichiers spécifiques sont attendus, faire correspondre des modèles regex stricts qui rejettent les barres obliques ou les segments de points.
     Action : Rejeter tout le reste.
7. Patch virtuel dédié (pour les appareils WAF qui le supportent)
   Si vous utilisez un WAF géré ou un service de sécurité qui prend en charge les patches virtuels, demandez ou déployez un patch virtuel qui bloque spécifiquement le chemin de code vulnérable et l'utilisation des paramètres pour ce plugin jusqu'à ce que vous puissiez mettre à jour.

Remarques sur le placement des règles et la sécurité :

• Testez les règles en mode “ journal ” ou “ surveillance ” d'abord pour éviter les faux positifs.
• Dans la mesure du possible, restreignez par la capacité de l'utilisateur authentifié plutôt que par l'IP seule ; les règles IP peuvent bloquer le travail légitime des administrateurs.
• Gardez les règles étroitement limitées aux chemins et motifs du plugin pour éviter de casser des fonctionnalités non liées du site.

---

Exemples de modèles de règles (pseudo-code)

Ci-dessous se trouvent des pseudo-règles illustratives qu'un ingénieur WAF professionnel mettrait en œuvre. NE COPIEZ PAS brut dans la production sans tester et adapter à votre environnement.

1) Bloquer le paramètre de suppression suspect avec traversée de chemin

IF (REQUEST_URI contains "/wp-admin/" OR REQUEST_URI contains "admin-ajax.php")
  AND (QUERY_STRING contains "delete=" OR POST_BODY contains "delete=")
  AND (PARAM_VALUE contains "../" OR PARAM_VALUE startswith "/" OR PARAM_VALUE contains "%2e%2e")
THEN block_request (status 403) LOG "suspicious_delete_param"

2) Bloquer les utilisateurs non administrateurs d'appeler le point de terminaison de suppression

SI (REQUEST_URI contient "perfmatters" OU REQUEST_URI contient "perfmatters-endpoint")

3) Limiter le taux des requêtes au niveau des abonnés vers les points de terminaison du plugin

SI (USER_ROLE == "subscriber")"

Ces modèles sont intentionnellement génériques. Les clients de WP-Firewall ont accès à un déploiement de règles géré qui peut être adapté à chaque site pour éviter de casser le trafic.

---

Récupération : si des fichiers ont été supprimés

Si vous découvrez des preuves de suppression, suivez une séquence de récupération sécurisée :

1. Isoler
   Mettre le site en mode maintenance ou le rendre temporairement hors ligne pour éviter d'autres dommages.
2. Sauvegardez l'état actuel
   Prenez un instantané du système de fichiers et de la base de données actuels pour les analyses judiciaires.
3. Identifier le périmètre
   Déterminez quels fichiers manquent et si d'autres changements (nouveaux fichiers, portes dérobées) sont présents.
4. Restaurez à partir d'une sauvegarde connue comme bonne
   Restaurez la sauvegarde propre la plus récente. Vérifiez l'intégrité et la fonctionnalité avant de rendre le site public.
5. Réinitialisez les identifiants et les secrets
   Faites tourner tous les identifiants administratifs et d'infrastructure (utilisateurs WordPress, panneau de contrôle d'hébergement, FTP/SFTP, base de données, clés API). Régénérez les sels dans wp-config.php si pertinent.
6. Analysez et auditez
   Effectuez une analyse complète des logiciels malveillants et un audit de code pour détecter les portes dérobées ou le code injecté. Vérifiez les comptes administratifs nouvellement créés.
7. Appliquez le correctif et le durcissement
   Mettez à jour le plugin vulnérable vers la version corrigée (2.6.0+), appliquez le patch virtuel WAF et suivez les étapes de durcissement ci-dessus.
8. Surveillance post-récupération
   Activez la journalisation améliorée, les vérifications d'intégrité des fichiers et les alertes pendant une période après la récupération.

Si vous manquez de ressources pour une gestion complète des incidents, consultez un fournisseur professionnel de réponse aux incidents WordPress ou un service de sécurité géré.

---

Prévenir des vulnérabilités similaires à l'avenir (guidance pour les développeurs)

Pour les auteurs et développeurs de plugins : cette vulnérabilité est un exemple classique de pourquoi les opérations sur les fichiers et les actions destructrices doivent être mises en œuvre avec des contrôles d'accès stricts et une sanitation.

Meilleures pratiques pour les développeurs :

• Appliquez des vérifications de capacité qui nécessitent des privilèges de niveau administrateur pour les opérations destructrices.
• Évitez d'accepter des chemins de système de fichiers bruts provenant des entrées utilisateur. Utilisez des ID ou des jetons sûrs, et résolvez vers des répertoires canoniques et attendus.
• Normalisez et assainissez les entrées ; refusez le parcours de chemin, ou utilisez des API sûres qui restreignent les opérations aux répertoires prévus.
• Introduisez des listes blanches côté serveur pour les noms de fichiers ; préférez référencer des objets par des ID internes.
• Effectuez un examen de code rigoureux et des tests automatisés autour des opérations sur les fichiers.
• Utilisez des en-têtes de sécurité et des nonces pour les actions Ajax/admin et vérifiez le référent et les capacités côté serveur.
• Documentez le modèle de sécurité et publiez un processus de divulgation des vulnérabilités.

---

Surveillance et journalisation : ce qu'il faut activer maintenant

• Activez la journalisation d'accès détaillée du serveur web avec des entrées horodatées et des IP clients.
• Conservez les journaux d'erreurs PHP à des fins de débogage et d'analyse judiciaire.
• Si vous avez un plugin d'audit, activez la journalisation des actions des utilisateurs (connexions, changements de rôle, opérations sur les fichiers).
• Surveillez l'intégrité des fichiers pour détecter les modifications des fichiers critiques et alertez en cas de suppressions.
• Configurez les alertes WAF pour les blocages liés aux règles d'atténuation décrites ci-dessus.
• Examinez régulièrement les journaux — de nombreuses intrusions montrent des signes précoces dans des journaux à faible signal avant un compromis total.

---

Pourquoi un compte à faible privilège peut être un gros problème

De nombreux propriétaires de sites considèrent le rôle d'abonné comme inoffensif. Dans de nombreuses installations, cependant, les fonctionnalités des plugins ou les points de terminaison des extensions élargissent involontairement ce qu'un abonné peut déclencher. De petites négligences dans le code (vérifications de capacité manquantes, assainissement insuffisant) peuvent transformer un compte apparemment bénin en une capacité destructrice. Les attaquants sont opportunistes ; ils vont explorer les points de terminaison et les paramètres pour trouver des failles logiques. C'est pourquoi minimiser les expositions et utiliser plusieurs couches de défense est essentiel.

---

À propos de l'atténuation WP-Firewall et de la protection gérée

Chez WP-Firewall, nous adoptons une approche de défense en profondeur : garder les sites en sécurité nécessite des correctifs en temps opportun, un durcissement en couches et un blocage actif des attaques pendant que les correctifs sont déployés.

Notre approche de protection comprend :

• Des règles de pare-feu d'application web gérées (WAF) adaptées aux écosystèmes WordPress
• Un patch virtuel pour bloquer les tentatives d'exploitation connues pour des problèmes de haute gravité
• Des moteurs de scan et de suppression de logiciels malveillants pour la remédiation des menaces côté serveur
• Surveillance de l'intégrité des fichiers et alertes détaillées
• Renseignements sur les menaces granulaires adaptés aux plugins et thèmes WordPress

Si vous ne pouvez pas appliquer de correctifs immédiatement, nous vous recommandons fortement de déployer un patch virtuel dans votre WAF pour bloquer les vecteurs d'exploitation connus pour le point de terminaison de plugin vulnérable et les modèles de paramètres décrits ci-dessus. Même un blocage à court terme réduit considérablement le risque d'exploitation de masse.

---

Un titre simple pour encourager les inscriptions à notre plan gratuit

Protégez votre site aujourd'hui avec WP-Firewall Free — défenses essentielles incluses

Si vous souhaitez une protection immédiate et continue pendant que vous appliquez des correctifs et durcissez, envisagez de vous inscrire au plan gratuit de WP-Firewall. Notre plan de base (gratuit) comprend une protection de pare-feu gérée, un WAF de niveau entreprise, une bande passante illimitée, un scanner de logiciels malveillants et une atténuation contre les vecteurs d'attaque OWASP Top 10 — tout ce dont de nombreux sites ont besoin pour empêcher des attaques comme celle-ci d'atteindre un code vulnérable.

Commencez avec WP-Firewall Free : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Pour les équipes qui ont besoin d'une automatisation supplémentaire et d'une réponse rapide, nos plans payants ajoutent la suppression automatique de logiciels malveillants, le blocage/liste blanche des IP, le patching virtuel automatique, des rapports de sécurité mensuels et des services gérés premium.

---

Foire aux questions

Q : Je n'utilise pas le plugin Perfmatters — suis-je concerné ?
A : Seuls les sites utilisant les versions vulnérables du plugin (<= 2.5.9.1) sont directement concernés. Si vous n'utilisez pas le plugin, ce CVE spécifique ne s'applique pas à vous, mais les conseils généraux ici (patching, WAF, surveillance) améliorent toujours la sécurité.

Q : Un accès anonyme est-il nécessaire pour exploiter cela ?
A : Non — la vulnérabilité nécessite un compte authentifié au niveau Abonné ou supérieur. Cela dit, de nombreux sites permettent soit l'enregistrement, soit ont des comptes abonnés compromis, donc le risque reste réel.

Q : Un WAF peut-il empêcher complètement l'exploitation ?
A : Un WAF bien configuré avec des règles de patch virtuel peut efficacement prévenir les modèles d'exploitation connus, réduisant considérablement le risque pendant que vous appliquez le patch. Cependant, la solution définitive est de mettre à jour le plugin.

Q : Que faire si je trouve des fichiers critiques supprimés — que devrais-je restaurer ?
A : Restaurez à partir de la sauvegarde propre la plus récente, puis appliquez le patch au plugin, changez les identifiants et scannez à la recherche de portes dérobées. En cas de doute, faites appel à un support d'intervention en cas d'incident.

---

Remarques de clôture : restez pragmatique et agissez maintenant

La sécurité pratique concerne les couches et les actions de protection rapides. Pour les propriétaires de sites utilisant les versions affectées de Perfmatters :

1. Mettez à jour le plugin vers 2.6.0 immédiatement.
2. Si vous ne pouvez pas mettre à jour tout de suite, appliquez les atténuations ci-dessus (désactivez le plugin, arrêtez les nouvelles inscriptions, déployez des règles WAF).
3. Inspectez les journaux et les sauvegardes, et soyez prêt à restaurer à partir d'une sauvegarde propre si des suppressions ont eu lieu.
4. Renforcez les rôles et surveillez les activités suspectes à l'avenir.

Si vous gérez plusieurs sites, traitez cela comme un déploiement urgent : vérifiez les versions installées par script, automatisez les mises à jour lorsque c'est sûr, et utilisez le patch virtuel à grande échelle pendant que vous mettez à jour.

Pour obtenir de l'aide avec le patch virtuel rapide ou le déploiement de règles WAF sur mesure, les protections gérées de WP-Firewall sont disponibles pour protéger les sites pendant que vous remédiez. Inscrivez-vous au plan de base (gratuit) pour une couverture immédiate de pare-feu géré et de scan : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

Restez en sécurité — et rappelez-vous, une détection rapide plus un patch virtuel immédiat peuvent faire la différence entre un quasi-accident et une panne coûteuse.