Nom du plugin	Cartes géographiques interactives
Type de vulnérabilité	Scripts intersites (XSS)
Numéro CVE	CVE-2025-15345
Urgence	Moyen
Date de publication du CVE	2026-05-17
URL source	CVE-2025-15345

XSS réfléchi dans “Cartes géographiques interactives” (<= 1.6.27) — Ce que les propriétaires de sites WordPress doivent faire maintenant

Avis de sécurité WP-Firewall et guide de remédiation

Résumé: Une vulnérabilité de Cross-Site Scripting (XSS) réfléchie (CVE-2025-15345) a été divulguée dans le plugin WordPress “Cartes géographiques interactives” affectant les versions jusqu'à et y compris 1.6.27. Le fournisseur a publié un correctif dans la version 1.6.28. Le problème est classé comme de gravité moyenne (CVSS 7.1), est exploitable via des requêtes conçues, et peut être utilisé pour exécuter du JavaScript dans le contexte des utilisateurs visitant une page vulnérable. Si votre site utilise ce plugin, agissez immédiatement.

---

Table des matières

• Ce qui a été divulgué (niveau élevé)
• Pourquoi le XSS réfléchi est important pour les sites WordPress
• Vue d'ensemble technique (comment fonctionne généralement le XSS réfléchi)
• Impact et risques dans le monde réel
• Comment détecter si vous êtes affecté
• Étapes d'atténuation immédiates à court terme (que faire dès maintenant)
• Mesures recommandées à long terme (renforcement et processus)
• Exemples de règles d'atténuation WAF et conseils (sûrs, non-exploitants)
• Liste de contrôle de réponse aux incidents pour compromission suspectée
• Comment WP-Firewall aide et plan recommandé
• Commencez à protéger votre site avec le plan gratuit de WP-Firewall (informations d'inscription)
• Notes finales et ressources

---

Ce qui a été divulgué (niveau élevé)

• Vulnérabilité: Cross-Site Scripting (XSS) réfléchi dans le plugin Cartes géographiques interactives pour WordPress.
• Versions concernées : toute version de plugin jusqu'à et y compris 1.6.27.
• Corrigé dans : 1.6.28 (appliquez la mise à jour dès que possible).
• CVE : CVE-2025-15345.
• Gravité: Moyen (CVSS 7.1).
• Privilèges requis : Aucun pour créer des charges utiles — cependant, l'exploitation nécessite généralement qu'un utilisateur (souvent un utilisateur authentifié ou un administrateur) clique sur un lien conçu ou ouvre une page contenant le paramètre/valeur vulnérable.
• Date de divulgation publique : mi-mai 2026.

Si vous hébergez des sites utilisant ce plugin, votre priorité est de mettre à niveau vers 1.6.28 ou une version ultérieure ou d'appliquer des contrôles compensatoires si la mise à niveau immédiate n'est pas possible.

---

Pourquoi le XSS réfléchi est important pour les sites WordPress

Le XSS réfléchi est l'une des classes de vulnérabilités web les plus courantes. Sur les sites WordPress, il est particulièrement dangereux car :

• Il peut être utilisé pour voler des cookies, des jetons de session et d'autres informations sensibles si les cookies d'authentification manquent de protections appropriées.
• Il permet le détournement de session, permettant aux attaquants de se faire passer pour des administrateurs ou des éditeurs s'ils parviennent à les tromper pour qu'ils visitent une URL conçue.
• Il peut être utilisé pour mener des attaques de phishing ciblées ou de prise de contrôle de compte pour des attaques à plus fort impact.
• Il peut conduire à l'exécution arbitraire de JavaScript dans les navigateurs des visiteurs — les attaquants peuvent utiliser cela pour installer des scripts de porte dérobée, créer des comptes administrateurs malveillants (via des utilisateurs authentifiés), ou effectuer des actions au nom des utilisateurs connectés.

Même si la vulnérabilité nécessite une interaction de l'utilisateur (cliquer sur un lien), les attaquants utilisent l'ingénierie sociale, des e-mails de phishing ou du spam dans les commentaires pour contraindre les utilisateurs à visiter des pages malveillantes — rendant le XSS réfléchi un risque pratique.

---

Vue d'ensemble technique — comment le XSS réfléchi fonctionne généralement (non-exploitant)

Le XSS réfléchi se produit lorsque des données contrôlées par l'utilisateur fournies dans une requête (par exemple dans une chaîne de requête, une soumission de formulaire ou un en-tête) sont immédiatement incluses dans une réponse HTTP par le serveur sans encodage/échappement ou validation appropriés. La réponse reflète la charge utile fournie par l'attaquant vers le navigateur de la victime, où elle est exécutée en tant que JavaScript.

Flux d'attaque typique :

1. L'attaquant crée une URL contenant un contenu malveillant dans un paramètre (par exemple ?location= ou des équivalents encodés).
2. L'attaquant incite une victime à ouvrir l'URL (e-mail de phishing, chat, réseaux sociaux, ou même en intégrant le lien dans une publicité).
3. Lorsque la victime charge la page, le serveur renvoie du HTML qui inclut le script de l'attaquant sans échappement.
4. Le navigateur de la victime exécute le script dans le contexte du site vulnérable — l'attaquant peut maintenant lire les cookies, manipuler le DOM, envoyer des requêtes authentifiées au site, exfiltrer des données, et plus encore.

Le XSS réfléchi est différent du XSS stocké (où la charge utile malveillante persiste dans une base de données) et du XSS basé sur le DOM (où la vulnérabilité existe uniquement dans le code côté client). Dans le cas signalé, la vulnérabilité est réfléchie et a été classée comme de gravité moyenne en fonction des impacts probables et de l'interaction utilisateur requise.

---

Impact et risques dans le monde réel

• Risque de données confidentielles : Les cookies du navigateur et les données de stockage local peuvent être accessibles si les cookies ne sont pas protégés (HttpOnly, SameSite).
• Prise de contrôle de compte : Les attaquants peuvent tenter un détournement de session ou exécuter des actions en utilisant les privilèges de la victime (si la victime est un administrateur/éditeur).
• Injection de contenu : Les attaquants peuvent modifier les pages affichées aux visiteurs (bannières malveillantes, superpositions de phishing).
• Propagation : Le XSS réfléchi est souvent utilisé comme vecteur initial pour livrer des charges utiles plus persistantes (attaques en chaîne qui créent des portes dérobées ou créent des utilisateurs malveillants).
• Dommages à la réputation : Si les attaquants montrent du contenu malveillant à vos visiteurs de site, cela nuit à la confiance et peut déclencher un blacklistage par les moteurs de recherche.
• Risque d'exploitation automatisée : Une fois divulgués, les détails de la vulnérabilité apparaissent souvent dans des outils de scan de masse et des kits d'exploitation automatisés. Même si les détails publics sont limités, les attaquants opportunistes essaieront des vecteurs communs.

Étant donné le volume des déploiements WordPress et la popularité des plugins de carte / localisation, des tentatives de scan et d'exploitation massives sont probables. Traitez cela comme urgent pour tout site utilisant le plugin.

---

Comment détecter si vous êtes affecté

1. Inventaire : Confirmez si Interactive Geo Maps est installé et quelle version il est. Dans WP Admin : Plugins -> Plugins installés. Si la version est <= 1.6.27, le plugin est vulnérable.
2. Recherchez des pages qui affichent des cartes ou acceptent des paramètres des chaînes de requête. Ce sont les vecteurs probables.
3. Examinez les journaux d'accès et les journaux WAF pour des requêtes suspectes :
   • Requêtes répétées avec des caractères encodés tels que , , script, onerror=, ou inhabituelles JavaScript : charges utiles.
   • Requêtes avec des paramètres de requête suspects qui contiennent <, >, ou des formes encodées.
4. Examinez le code source de la page et le HTML rendu des pages de carte : recherchez des 5. balises injectées ou des scripts en ligne inattendus qui ne font pas partie du code légitime.
5. Effectuez un scan interne sécurisé : utilisez un scanner de vulnérabilités ou un environnement de test contrôlé (ne testez jamais en production avec des utilisateurs actifs sans consentement). Recherchez des entrées réfléchies dans les réponses lorsque vous soumettez des valeurs de paramètres.
6. Surveillez les rapports des utilisateurs : si des visiteurs ou des administrateurs signalent des pop-ups inattendus, des redirections ou un comportement “bizarre”, enquêtez immédiatement.
7. Vérifiez la base de données et les comptes utilisateurs pour des signes de compromission (utilisateurs administrateurs inattendus, changements de contenu, scripts injectés stockés dans post_content ou options).

Si des signes d'exploitation sont trouvés, suivez immédiatement un flux de travail de réponse aux incidents (voir ci-dessous).

---

Actions immédiates — que faire dès maintenant

Si votre site utilise Interactive Geo Maps et que la version du plugin est vulnérable (<= 1.6.27), priorisez ces étapes :

1. Mettez à jour le plugin vers 1.6.28 ou une version ultérieure
   • C'est la solution définitive. Mettez à jour via WordPress Admin -> Plugins ou via CLI si vous êtes à l'aise (WP-CLI : mise à jour du plugin wp interactive-geo-maps).
2. Si vous ne pouvez pas mettre à jour immédiatement (compatibilité, mise en scène requise), prenez l'une de ces actions temporaires :
   • Désactivez le plugin jusqu'à ce que vous puissiez le mettre à jour.
   • Restreignez l'accès aux pages qui affichent des cartes — placez-les derrière une authentification, une page de maintenance, ou refusez l'accès via votre panneau de contrôle d'hébergement.
   • Utilisez un WAF (Web Application Firewall) pour bloquer les modèles de requêtes malveillantes et les charges utiles XSS courantes visant les points de terminaison vulnérables.
3. Mettez votre site dans un état de surveillance :
   • Activez la journalisation et augmentez la fréquence de surveillance pour les points de terminaison liés aux cartes.
   • Surveillez les pics suspects de 4xx/5xx, les chaînes de requête inhabituelles et les tentatives de connexion échouées.
4. Rescannez votre site :
   • Exécutez une analyse de malware et un contrôle d'intégrité des fichiers pour vous assurer qu'il n'y a pas eu de compromission antérieure.
5. Communiquez avec les parties prenantes :
   • Si le site héberge plusieurs utilisateurs ou est orienté vers les clients, informez les parties prenantes concernées et votre fournisseur d'hébergement si nécessaire.
6. Planifiez un suivi :
   • Après la mise à jour, testez le site en profondeur pour vous assurer que les cartes fonctionnent correctement et que le correctif résout le problème sans casser la fonctionnalité.

Note: Si vous découvrez des preuves de compromission, ne vous contentez pas de corriger ; suivez la liste de contrôle de réponse aux incidents ci-dessous.

---

Mesures recommandées à long terme (renforcement et processus)

Pour minimiser l'exposition future et améliorer la posture de récupération, adoptez ces meilleures pratiques :

• Maintenir un inventaire des plugins et appliquer des mises à jour en temps opportun
  • Automatisez les mises à jour des plugins lorsque cela est sûr (testez les mises à niveau en staging d'abord).
• Utilisez un accès basé sur les rôles et réduisez le nombre d'administrateurs.
  • Limitez les comptes administratifs au plus petit ensemble d'utilisateurs qui en ont besoin.
• Appliquez l'authentification multi-facteurs (MFA) pour les administrateurs.
  • Réduisez le risque de prise de contrôle de compte même si les identifiants sont phishés.
• Renforcez la sécurité des cookies.
  • Définissez les cookies d'authentification avec les attributs HttpOnly, Secure et SameSite.
• Implémentez la politique de sécurité du contenu (CSP)
  • CSP peut réduire l'impact des XSS en limitant d'où les scripts peuvent être chargés ; utilisez d'abord un mode de rapport uniquement pour identifier les sources requises.
• Conservez des sauvegardes régulières et testées.
  • Maintenez des sauvegardes hors site (base de données + fichiers) et vérifiez que vous pouvez restaurer rapidement.
• Adoptez un service WAF/de patching virtuel
  • Les WAF peuvent fournir des règles qui atténuent les CVE connus jusqu'à ce que vous puissiez appliquer les mises à jour du fournisseur.
• Adoptez une surveillance de l'intégrité des fichiers en temps réel et des analyses de logiciels malveillants périodiques
  • Détectez rapidement les fichiers injectés.
• Limitez l'utilisation des plugins à des plugins essentiels et bien entretenus
  • Désactivez et supprimez immédiatement les plugins inutilisés.
• Testez les mises à jour dans un environnement de staging
  • Réduisez le temps d'arrêt et le risque de compatibilité en validant les mises à jour avant de les déployer en production.
• Abonnez-vous aux notifications de vulnérabilité et aux flux de sécurité
  • Recevez des notifications sur les CVE et les correctifs des plugins afin de pouvoir réagir plus rapidement.

---

Exemples de règles d'atténuation WAF et conseils (sûrs, non-exploitants)

Si vous devez protéger le site avant de pouvoir mettre à jour ou désactiver le plugin en toute sécurité, les modèles défensifs suivants sont généralement efficaces. Ceux-ci sont illustratifs — adaptez-les à votre environnement et à vos journaux, et évitez de bloquer le trafic légitime.

Important: Ne collez pas de charges utiles d'exploitation exactes ou de chaînes PoC connues publiquement dans les règles de production sans test, car des règles trop larges peuvent casser des fonctionnalités légitimes.

Idées de règles suggérées (pseudo-logique) :

• Bloquez les requêtes où les paramètres de requête contiennent des équivalents non échappés <script ou codés :
  • Condition : REQUEST_URI ou QUERY_STRING contient <script ou script (insensible à la casse).
  • Action : Bloquer/403 ou Challenge (CAPTCHA).
• Bloquez les requêtes contenant des motifs d'attributs XSS courants :
  • par exemple, onerror=, onload=, JavaScript : apparaissant dans les chaînes de requête ou les en-têtes.
• Bloquez les paramètres de requête très longs qui incluent des séquences codées suspectes :
  • Condition : longueur du paramètre > seuil prédéfini + contient des caractères suspects.
• Limitez le taux des URI de requête associées aux pages d'affichage de carte (par exemple, /carte, /géolocalisation points de terminaison).
• Challengez les requêtes avec des charges utiles suspectes via CAPTCHA plutôt que de bloquer directement pour réduire les faux positifs.
• Autorisez les référents et agents utilisateurs connus comme bons pour les pages administratives.
• Pour les pages administratives ou les points de terminaison de configuration de plugin, restreignez par IP lorsque cela est possible.

Exemple de pseudo-règle compatible ModSecurity (illustratif, pas prêt pour la production) :

# Pseudo-règle : bloquer les modèles XSS réfléchis de base dans la chaîne de requête"

Remarques :

• Les tests sont essentiels. Commencez en mode détection uniquement et affinez.
• Utilisez une approche en couches : WAF + CSP + mises à jour de l'application.
• Ne comptez pas uniquement sur le WAF ; corrigez le plugin lorsque cela est possible.

---

Liste de contrôle de réponse aux incidents — si vous soupçonnez un compromis

Si vous voyez des preuves d'exploitation (scripts injectés, utilisateurs administratifs inattendus, actions non autorisées), suivez une réponse aux incidents structurée :

1. Isoler:
   • Si nécessaire, mettez le site hors ligne ou restreignez l'accès aux interfaces administratives pour éviter d'autres dommages.
2. Instantané de l'état actuel :
   • Exportez les journaux actuels, copiez les fichiers, les instantanés de base de données pour une analyse judiciaire (préservez les horodatages).
3. Faites tourner les clés et les identifiants :
   • Changez les mots de passe administratifs, les clés API, les identifiants de base de données et tous les identifiants stockés sur le serveur.
   • Forcer une réinitialisation de mot de passe pour tous les comptes privilégiés.
4. Scannez minutieusement :
   • Exécutez une analyse approfondie des logiciels malveillants, y compris une recherche de fichiers contenant 5., du contenu encodé en base64 ou des fichiers PHP inhabituels.
   • Vérifiez les tâches planifiées malveillantes (cron jobs), les nouveaux fichiers PHP dans les téléchargements et les modifications de wp-config.php ou .htaccess.
5. Passez en revue les utilisateurs et les autorisations :
   • Supprimez les utilisateurs administrateurs inconnus et auditez les récents changements de rôle des utilisateurs.
6. Nettoyez ou restaurez :
   • Si vous avez une sauvegarde propre récente d'avant la compromission, envisagez de la restaurer après vous être assuré que la vulnérabilité est corrigée et que les identifiants ont été changés.
   • Si vous nettoyez sur place, supprimez le contenu injecté, les portes dérobées et les fichiers malveillants. Vérifiez l'intégrité des fichiers de base, de thème et de plugin.
7. Surveillez et validez :
   • Après remédiation, surveillez les journaux, l'activité des utilisateurs et les analyses externes. Effectuez une analyse de sécurité indépendante pour valider le nettoyage.
8. Rapport et apprentissage post-incident :
   • Documentez l'incident, la chronologie et la cause profonde.
   • Ajustez les processus (par exemple, cadence de mise à jour, tests de staging, règles WAF) pour prévenir la récurrence.

Si vous n'êtes pas à l'aise avec une réponse complète à l'incident, engagez un fournisseur de sécurité professionnel pour vous aider. Une remédiation rapide et correcte réduit le risque de portes dérobées persistantes et d'attaques répétées.

---

Comment WP-Firewall aide (et plan recommandé)

Chez WP-Firewall, nous opérons d'un point de vue pratique, de défense en profondeur. Voici comment notre plateforme aide les propriétaires de sites confrontés à des vulnérabilités de plugins comme celle-ci :

• WAF géré : Notre pare-feu peut déployer des règles ciblées pour bloquer les types de tentatives XSS réfléchies couramment utilisées pour exploiter les vulnérabilités basées sur des cartes et des paramètres. Cela protège votre site pendant que vous planifiez et testez les mises à jour de plugins.
• Analyse des logiciels malveillants : Des analyses continues recherchent des scripts injectés et des modifications de fichiers suspects afin que vous puissiez repérer rapidement une exploitation.
• Atténuation OWASP : Des ensembles de règles intégrés traitent les problèmes courants du Top 10 OWASP, réduisant la chance qu'un attaquant réussisse malgré un plugin vulnérable.
• Protection adaptée à la bande passante : Nos protections n'ajoutent pas de latence inutile pour les visiteurs légitimes tout en bloquant le trafic malveillant.
• Patching virtuel (Pro) : Pour les clients qui ne peuvent pas immédiatement appliquer les mises à jour des plugins en raison de contraintes de test ou de compatibilité, le patching virtuel fournit un bouclier temporaire sûr pour bloquer les tentatives d'exploitation jusqu'à ce que vous puissiez mettre à jour.

Quel plan WP-Firewall est fait pour vous ?

• Basique (gratuit) : Protection essentielle — pare-feu géré, bande passante illimitée, WAF, scanner de malware et atténuation des risques OWASP Top 10. Cela offre une défense de base immédiate pour les petits sites et constitue une excellente première étape.
• Standard : Ajoute un contrôle automatique de suppression de malware et de liste noire/liste blanche d'IP pour les petites équipes.
• Pro : Pour les agences et les sites de grande valeur, Pro fournit des rapports mensuels, un patching virtuel automatisé des vulnérabilités et des services de support premium.

Chaque installation WordPress devrait associer un patching opportun à une protection active. Le WAF doit être considéré comme un tampon d'urgence pendant que vous appliquez les patches du fournisseur et effectuez des tests approfondis.

---

Commencez à protéger votre site avec le plan gratuit de WP-Firewall

Titre: Commencez à Protéger Votre Site avec le Plan Gratuit de WP-Firewall

Si vous êtes inquiet au sujet de cette vulnérabilité ou si vous souhaitez une protection de base sur laquelle vous pouvez compter immédiatement, envisagez de commencer avec le plan de base (gratuit) de WP-Firewall. Il offre une protection de pare-feu géré, un WAF toujours actif, un scan de malware et une couverture contre les risques courants du Top 10 OWASP — tout ce dont un petit site a besoin pour réduire les risques pendant que vous testez et appliquez les mises à jour des plugins. Inscrivez-vous ou en savoir plus à :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Exemples pratiques — ce que vous devriez faire étape par étape

Ci-dessous se trouve un runbook concis que vous pouvez suivre si vous gérez des sites WordPress avec ce plugin sur une flotte de sites.

1. Inventaire et triage
   • Requête : Quels sites ont des cartes géographiques interactives installées ? (Utilisez des outils de gestion ou WP-CLI.)
   • Priorisez : Sites avec des cartes publiques et utilisateurs à privilèges élevés en premier.
2. Patch ou contenir
   • Meilleur : Mettez à jour vers 1.6.28 immédiatement (testez en staging si nécessaire).
   • Si vous ne pouvez pas mettre à jour en toute sécurité : désactivez le plugin ou appliquez une règle WAF pour bloquer les tentatives XSS réfléchies sur les points de terminaison de la carte.
3. Vérifiez
   • Après la mise à jour ou la containment, testez les pages de la carte pour vous assurer que les cartes s'affichent et qu'aucun script inattendu ne s'exécute.
   • Re-scanner avec un scanner de malware et vérifier les journaux d'accès pour de nouvelles demandes suspectes.
4. Restaurer la confiance
   • Si vous avez trouvé des preuves de compromission, effectuez une remédiation complète : restaurez à partir d'une sauvegarde connue comme bonne, faites tourner les identifiants et informez les parties concernées si nécessaire.
5. Prévenir
   • Activer la MFA, limiter les comptes administrateurs, adopter le plan gratuit WP-Firewall pour une protection de base immédiate, et planifier une fenêtre de maintenance pour garder les plugins à jour.

---

Journalisation et surveillance — exemples à rechercher

Lors de la surveillance des journaux pour des signes de XSS réfléchi ou de tentatives d'exploitation, recherchez :

• Des requêtes avec encodage <, > des caractères : %3C, %3E
• Des requêtes contenant des chaînes comme onerror=, onload=, JavaScript :, ou des segments base64 suspects (souvent utilisés pour obfusquer les charges utiles)
• Un volume élevé de requêtes pour cartographier les points de terminaison à partir d'IP uniques ou d'un petit ensemble d'IP (modèle de balayage)
• Réponses 200 inattendues à des entrées suspectes (ce qui signifie que le serveur a renvoyé une page normale — possiblement avec du contenu injecté)

Exemple de signature de ligne de journal (journal combiné Apache simplifié) :

123.45.67.89 - - [15/May/2026:13:21:01 +0000] "GET /maps?city=script/script HTTP/1.1" 200 12345 "-" "Mozilla/5.0 (compatible)"

Action : Enquêter sur cette IP et la page, bloquer si cela fait partie d'un modèle d'exploitation, et vérifier si un visiteur a réellement déclenché la charge utile.

---

FAQ

Q : Si je mets à jour vers 1.6.28, suis-je complètement en sécurité ?
R : La mise à jour supprime la vulnérabilité connue dans la version du plugin référencée. Cependant, vous devez toujours suivre les meilleures pratiques de durcissement (MFA, comptes administrateurs limités, WAF, sauvegardes) car de nouvelles vulnérabilités peuvent apparaître dans n'importe quel composant.

Q : Un WAF peut-il remplacer le patching ?
R : Non. Un WAF est un contrôle compensatoire important et fournit une atténuation rapide, mais il ne doit pas être utilisé comme un remplacement permanent pour les mises à jour. Le patching virtuel achète du temps et réduit le risque jusqu'à ce que vous puissiez appliquer le patch du fournisseur.

Q : Je ne peux pas mettre à jour en raison de la compatibilité. Que devrais-je faire ?
R : Désactivez temporairement le plugin ou restreignez l'accès aux pages de carte, appliquez des règles WAF, testez les mises à jour en staging, et coordonnez-vous avec le développeur du plugin pour un calendrier.

---

Fermeture — traiter les plugins en priorité

Les plugins ajoutent une grande fonctionnalité aux sites WordPress, mais ils augmentent également la surface d'attaque. La divulgation XSS réfléchie des cartes géographiques interactives est un rappel : surveillez les mises à jour des plugins, maintenez un inventaire et gardez un plan de réponse d'urgence prêt. Priorisez le correctif du fournisseur, et si vous ne pouvez pas l'appliquer immédiatement, comptez sur des défenses en couches : WAF, CSP, MFA, privilège minimal et surveillance vigilante.

Si vous voulez une première étape immédiate et pratique — activez une protection gérée de base qui protège votre site des modèles d'attaque courants pendant que vous testez et appliquez les mises à jour du fournisseur. Le plan de base (gratuit) de WP-Firewall fournit cette protection de base et est disponible pour s'inscrire maintenant : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Si vous le souhaitez, je peux :

• Fournissez un ensemble de règles ModSecurity courtes adaptées à vos points de terminaison de carte (testées et prêtes pour la mise en scène), ou
• Parcourez un manuel de réponse aux incidents étape par étape adapté à votre environnement d'hébergement et à l'accès à WP-CLI.

Restez en sécurité — mettez à jour d'abord, défendez ensuite, et surveillez toujours.