Nom du plugin	Catalogue de jeux
Type de vulnérabilité	CSRF
Numéro CVE	CVE-2026-8418
Urgence	Faible
Date de publication du CVE	2026-05-20
URL source	CVE-2026-8418

Vulnérabilité CSRF critique dans le plugin Catalogue de jeux (≤ 1.2.0) : Ce que les propriétaires de sites WordPress doivent savoir et comment protéger votre site

Par l'équipe de sécurité WP‑Firewall — de véritables ingénieurs en sécurité WordPress écrivant de l'expérience de défense de milliers de sites.

Le 19 mai 2026, une vulnérabilité de falsification de requête intersite (CSRF) affectant le plugin WordPress “ Catalogue de jeux ” (versions ≤ 1.2.0) a été divulguée publiquement (CVE‑2026‑8418). Le problème permet à un attaquant de contraindre un administrateur authentifié (ou un autre utilisateur privilégié) à supprimer des publications de jeux arbitraires d'un site utilisant le plugin vulnérable. Bien que la vulnérabilité ait un faible score CVSS, son impact est réel : des campagnes CSRF ciblées ou massives peuvent supprimer du contenu, endommager la confiance et nécessiter une récupération manuelle.

Cet article explique, en langage simple et en détail technique, comment la vulnérabilité fonctionne, quels sont les risques immédiats, comment vous pouvez détecter l'exploitation et—surtout—comment protéger votre site maintenant en utilisant à la fois des atténuations à court terme et des corrections à long terme. Nous expliquons également comment WP‑Firewall (notre service de pare-feu WordPress géré et WAF) protège les sites contre ce type d'attaque et comment commencer avec notre plan de base gratuit.

---

Résumé rapide (TL;DR)

• Vulnérabilité : CSRF dans le plugin Catalogue de jeux ≤ 1.2.0 permet à un attaquant de déclencher la suppression de publications de jeux en trompant un utilisateur privilégié authentifié pour qu'il visite une page conçue ou clique sur un lien.
• Impact : Suppression arbitraire de publications (perte de données), effets potentiels en aval sur le SEO, la confiance des utilisateurs et la continuité des affaires.
• Conditions requises : L'attaquant n'a pas besoin d'être authentifié ; un administrateur de site ou un autre utilisateur privilégié doit être trompé pour effectuer une action tout en étant authentifié.
• Actions immédiates : Si vous avez le plugin et ne pouvez pas le mettre à jour, restreignez l'accès admin, activez un WAF (par exemple, WP‑Firewall) et appliquez des correctifs virtuels ou des règles temporaires pour bloquer les POSTs inter-domaines vers des points de terminaison vulnérables.
• À long terme : Le développeur du plugin devrait ajouter des vérifications de nonce appropriées, des vérifications de capacité, et idéalement migrer les actions sensibles vers l'API REST de WordPress avec des rappels de permission.
• Protection WP‑Firewall : Notre WAF bloque les requêtes inter-domaines vers les points de terminaison admin, applique des règles de validation d'origine/référent, et fournit un patch virtuel (disponible sur les plans payants) pour stopper les modèles d'exploitation observés.

---

Qu'est-ce que le CSRF et pourquoi cela compte pour les plugins WordPress

La falsification de requête intersite (CSRF) est une attaque où un attaquant trompe un utilisateur authentifié pour qu'il effectue des actions qu'il n'avait pas l'intention d'exécuter. Pour les sites WordPress, le CSRF est particulièrement dangereux lorsqu'un utilisateur à privilège élevé (Administrateur, Éditeur) est ciblé. Une attaque CSRF ne vole pas directement les identifiants — elle exploite plutôt la session active de la victime (cookie) pour effectuer des actions autorisées en son nom.

Séquence CSRF typique :

1. La victime est connectée au site WordPress cible et a un cookie de session valide.
2. L'attaquant amène la victime à visiter une page malveillante ou à cliquer sur un lien conçu.
3. La page malveillante déclenche une requête vers le site vulnérable (par exemple, un POST vers un point de terminaison de plugin qui effectue une suppression).
4. Parce que le navigateur de la victime inclut son cookie de session, le site traite la requête comme venant de l'utilisateur authentifié et effectue l'action (par exemple, supprimer une publication).

Les plugins WordPress bien écrits se défendent contre le CSRF en incluant et en vérifiant les nonces, en vérifiant les capacités (current_user_can), et en rejetant les requêtes qui manquent de valeurs d'origine/référent attendues lorsque la requête provient d'un site externe.

---

La vulnérabilité du Catalogue de jeux — niveau élevé

Basé sur la divulgation :

• Plugin : Catalogue de jeux
• Versions vulnérables : ≤ 1.2.0
• Classification : Contre‑attaque par requête intersite (CSRF)
• CVE : CVE‑2026‑8418
• Problème principal : Le point de terminaison de suppression sensible accepte des requêtes non authentifiées ou d'origine croisée sans vérification suffisante de nonce ou de capacité, permettant la suppression de publications de jeux arbitraires lorsqu'un utilisateur privilégié est trompé en visitant une page malveillante.

Parce que c'est du CSRF, l'attaquant n'a pas besoin de s'authentifier sur le site cible. L'attaque repose sur un utilisateur privilégié déjà authentifié dans son navigateur.

Contexte important : de nombreux sites WordPress ont plusieurs utilisateurs et administrateurs qui se connectent régulièrement. Les sessions administratives laissées ouvertes dans les navigateurs (ou les configurations de connexion unique) rendent le CSRF très viable.

---

Comment un attaquant pourrait exploiter cela (scénario d'exploitation)

Une exploitation typique suivrait ces étapes :

1. Identifier un site exécutant le Catalogue de jeux ≤ 1.2.0.
2. Trouver ou deviner les paramètres utilisés pour supprimer des publications de jeux (par exemple, un HTTP POST vers une URL d'action de plugin spécifique incluant un ID de jeu).
3. Créer une page malveillante qui émet la requête de suppression lorsqu'elle est visitée (par exemple via un formulaire HTML auto-soumettant, une balise image dans certains contextes, ou un fetch d'origine croisée).
4. Attirer un administrateur vers cette page (email de phishing, lien de forum, annonce, ou site tiers compromis).
5. Le navigateur de l'administrateur, avec ses cookies authentifiés pour le site cible, envoie la requête de suppression et le plugin la traite car il manque de vérifications appropriées de nonce ou de capacité.

Un exemple conceptuel simplifié (ne pas copier et exécuter contre des sites en direct) :

• Le navigateur effectue un POST vers : https://example.com/wp-admin/admin-post.php?action=delete_game&game_id=123
• Parce que le plugin ne nécessite pas de nonce ou ne vérifie pas current_user_can(‘delete_posts’), l'action est acceptée et la publication de jeu est supprimée.

Les détails de la divulgation responsable sont omis ici pour des raisons de sécurité ; l'objectif est d'expliquer le modèle d'attaque afin que les propriétaires de sites et les développeurs puissent se défendre.

---

Impact pratique pour les propriétaires de sites

• Perte de contenu : La suppression de publications de jeu peut supprimer un contenu important, avec des effets en aval sur le SEO et l'expérience utilisateur.
• Charge administrative : La récupération des publications peut nécessiter des restaurations de base de données, une recréation manuelle ou une restauration à partir de sauvegardes.
• Réactions en chaîne : Si l'attaquant supprime une publication sur laquelle d'autres flux de travail dépendent (par exemple, pages liées, avis, contenu utilisateur), cela peut casser des fonctionnalités ou des affichages sur le site.
• Réputation : La perte de contenu visible peut nuire à la confiance et à la crédibilité des utilisateurs.
• Attaques de masse : Les scanners automatisés peuvent exploiter rapidement de nombreux sites une fois qu'un modèle est connu.

Même si cette vulnérabilité est considérée comme “ faible ” selon un score CVSS, les conséquences pratiques pour certaines organisations peuvent être significatives.

---

Pouvez-vous détecter si votre site a été exploité ?

Les signes d'exploitation incluent :

• Publications de jeu manquantes ou publications avec un horodatage de suppression récent correspondant à la fenêtre de divulgation.
• Journaux d'activité admin montrant des demandes de suppression du compte admin sans actions intentionnelles correspondantes.
• Changements inattendus dans la base de données : vérifiez la table wp_posts pour des lignes supprimées, ou la corbeille si des publications y ont été déplacées.
• Journaux du serveur montrant des requêtes POST vers des points de terminaison de plugin provenant d'agents utilisateurs ou de référents inhabituels.
• Journaux d'audit (si activés) montrant l'activité de session admin en même temps que les événements de suppression.
• Fichiers ou tâches planifiées modifiés autour de la même période, indiquant des tentatives de compromission plus larges.

Étapes à suivre pour enquêter :

1. Récupérez les sauvegardes récentes et comparez les entrées wp_posts pour les publications de jeu attendues.
2. Inspectez wp_postmeta pour les métadonnées spécifiques au jeu supprimées ou modifiées.
3. Vérifiez les journaux d'accès pour des requêtes vers des points de terminaison de plugin (cherchez des POST là où des GET sont attendus, ou des en-têtes de référent suspects).
4. Utilisez un scanner/moniteur (scanner de malware WP-Firewall ou similaire) pour rechercher des indicateurs de compromission.
5. Si vous avez un plugin d'audit ou un journal d'activité, identifiez les actions effectuées sous des comptes admin autour du moment de la suppression.

Si vous confirmez des suppressions non autorisées, traitez le site comme compromis jusqu'à ce que vous ayez terminé une enquête complète.

---

Étapes d'atténuation immédiates pour les propriétaires de sites (que faire maintenant)

Si vous exécutez Games Catalog ≤ 1.2.0 et ne pouvez pas immédiatement le mettre à jour ou le supprimer, suivez les étapes suivantes pour réduire le risque :

1. Restreindre l'accès aux comptes administratifs :
   • Bloquer temporairement les comptes administratifs non essentiels.
   • Forcer la déconnexion de tous les utilisateurs (réinitialiser les jetons de session) et exiger une nouvelle authentification.
2. Mettre le site derrière un pare-feu d'application Web (WAF) :
   • Un WAF peut bloquer les POSTs inter-domaines, les modèles de charge utile suspects et les signatures d'exploit connues.
   • Si vous utilisez WP-Firewall, activez les règles WAF gérées qui bloquent les modèles CSRF ciblant les points de terminaison administratifs.
3. Désactivez ou supprimez le plugin jusqu'à ce qu'une version corrigée et sécurisée soit disponible.
4. Limitez les POSTs distants aux points de terminaison wp-admin ou admin :
   • Autorisez uniquement les requêtes de même origine aux points de terminaison du gestionnaire admin.
   • Mettez en œuvre des règles serveur temporaires (voir les exemples ci-dessous).
5. Restreindre l'accès à la zone wp-admin par IP lorsque cela est possible (liste blanche des IPs administratives).
6. Mettre en œuvre ou appliquer l'authentification à 2 facteurs sur les comptes administratifs.
7. Scanner et sauvegarder :
   • Effectuez une sauvegarde complète avant d'apporter des modifications.
   • Exécutez une analyse complète des logiciels malveillants.
   • Si vous détectez des signes d'exploitation, restaurez à partir d'une sauvegarde connue et bonne et faites tourner les identifiants.

---

Règles serveur/WAF temporaires que vous pouvez appliquer maintenant

Si vous pouvez modifier la configuration de votre serveur ou de votre WAF, les mesures défensives suivantes aident à stopper les tentatives CSRF inter-domaines :

• Bloquer les requêtes POST avec un en-tête Origin ou Referer externe vers les points de terminaison administratifs :

Exemple de règle ModSecurity (conceptuelle) :

# Bloquer les POSTs vers les points de terminaison administratifs si l'Origin ou le Referer ne correspond pas au site"

Exemple Nginx (modèle de base) :

location ~* /wp-admin/(admin-post\.php|admin-ajax\.php|.*your-plugin-endpoint.*) {

Important : les règles du serveur doivent être adaptées à votre environnement ; des règles inappropriées peuvent perturber les actions administratives légitimes (par exemple, des POST légitimes provenant d'iframes ou d'intégrations tierces). Testez en staging avant la production.

• Appliquer la politique de cookies same-site :
  • Définir des cookies de session avec SameSite=Lax ou SameSite=Strict pour réduire le risque de CSRF pour les POST inter-sites. Remarque : certaines actions peuvent nécessiter un paramètre moins restrictif.
• Bloquer les agents utilisateurs suspects et les modèles de scan de masse :
  • Les WAF peuvent limiter et bloquer les requêtes à haute fréquence et les scanners qui tentent d'énumérer les points de terminaison.

Si vous utilisez un WAF géré (tel que WP-Firewall), notre équipe peut appliquer ces protections pour vous sans modifications risquées du serveur.

---

Comment les développeurs doivent corriger le plugin (durcissement du code recommandé)

Si vous êtes l'auteur ou le mainteneur du plugin, les éléments suivants sont nécessaires pour fermer les vecteurs CSRF :

1. Utilisez des nonces pour chaque action modifiant l'état :
   • Ajouter wp_nonce_field('supprimer_jeu_' . $game_id, 'supprimer_jeu_nonce') aux formulaires.
   • Vérifiez le nonce lors de la demande : check_admin_referer('supprimer_jeu_' . $game_id, 'supprimer_jeu_nonce').
2. Vérifiez les capacités :
   • Avant toute suppression, vérifiez current_user_can('supprimer_des_articles') ou une capacité appropriée pour le type de publication.
   • Exemple : si les jeux sont des types de publication personnalisés avec des capacités personnalisées, vérifiez current_user_can('supprimer_jeu', $game_id) ou similaire.
3. Assainir et valider l'entrée :
   • Convertir les ID en entiers : $game_id = intval( $_POST['game_id'] ?? 0 );
   • Assurez-vous que le post appartient au type de post attendu.
4. Utilisez les API de suppression appropriées :
   • Utiliser wp_trash_post() ou wp_delete_post( $game_id, true ) selon les exigences.
   • Journalisez les actions administratives, idéalement via des journaux d'audit.
5. Déplacez les actions sensibles vers l'API REST avec un permission_callback:
   • Pour les plugins modernes, envisagez le point de terminaison de l'API REST implémentant permission_callback qui valide les capacités de l'utilisateur actuel.
6. Évitez d'effectuer des actions destructrices via GET :
   • La suppression doit toujours être une action POST/DELETE avec un nonce et des vérifications de capacité.

Exemple d'un gestionnaire sûr (conceptuel) :

function gc_handle_delete_game() {
    // Ensure request method is POST
    if ( 'POST' !== $_SERVER['REQUEST_METHOD'] ) {
        wp_die( 'Invalid request method', 'Error', array( 'response' => 405 ) );
    }

    // Check nonce
    if ( ! isset( $_POST['delete_game_nonce'] ) || ! wp_verify_nonce( $_POST['delete_game_nonce'], 'delete_game_action' ) ) {
        wp_die( 'Security check failed', 'Error', array( 'response' => 403 ) );
    }

    $game_id = isset( $_POST['game_id'] ) ? intval( $_POST['game_id'] ) : 0;
    if ( ! $game_id ) {
        wp_die( 'Invalid game ID', 'Error', array( 'response' => 400 ) );
    }

    // Capability check
    if ( ! current_user_can( 'delete_post', $game_id ) ) {
        wp_die( 'You are not allowed to delete this game', 'Error', array( 'response' => 403 ) );
    }

    // Confirm post type
    $post = get_post( $game_id );
    if ( ! $post || 'game' !== $post->post_type ) {
        wp_die( 'Not a game post', 'Error', array( 'response' => 404 ) );
    }

    // Perform deletion (move to trash)
    $result = wp_delete_post( $game_id, false );
    if ( ! $result ) {
        wp_die( 'Failed to delete', 'Error', array( 'response' => 500 ) );
    }

    // Redirect or return success
    wp_redirect( admin_url( 'edit.php?post_type=game&deleted=1' ) );
    exit;
}

Cet exemple impose la vérification du nonce et les vérifications de capacité avant la suppression.

---

Pourquoi un WAF aide : ce que WP‑Firewall fait pour arrêter les exploits CSRF

Un pare-feu d'application Web (WAF) est une couche critique qui peut arrêter les tentatives d'exploitation — surtout lorsque les plugins n'ont pas encore été corrigés ou lorsque des mises à jour immédiates des plugins sont impraticables.

Comment WP‑Firewall protège les sites WordPress contre ces attaques de type CSRF :

• Validation de l'origine de la requête et du référent : Le WAF bloque les POSTs inter-domaines et les requêtes externes suspectes vers les points de terminaison administratifs, sauf si elles correspondent aux origines ou modèles autorisés.
• Patching virtuel (sur Pro) : Lorsqu'une nouvelle vulnérabilité est divulguée, le patching virtuel permet à notre équipe de créer une règle qui bloque le modèle d'exploitation sans modifier votre plugin. Cela vous donne du temps jusqu'à ce que le fournisseur expédie un correctif.
• Signature de blocage connue : Nous maintenons des règles pour bloquer les modèles d'exploitation CSRF courants (formulaires soumis automatiquement, POST basés sur des images, combinaisons de paramètres suspects ciblant les points de terminaison administratifs).
• Limitation de taux et défense contre les bots : Les scanners de vulnérabilités automatisés et les outils d'exploitation de masse sont ralentis ou bloqués complètement.
• Analyse de logiciels malveillants et détection d'anomalies : L'analyse post-exploitation vous aide à trouver des modifications de fichiers inattendues, du contenu supprimé ou des portes dérobées.

Même avec notre plan de base gratuit, vous bénéficiez d'une protection essentielle : un pare-feu géré avec WAF, une analyse de logiciels malveillants et une atténuation des risques OWASP Top 10, ce qui arrêtera de nombreuses tentatives automatisées et opportunistes d'exploiter des problèmes CSRF.

---

Liste de contrôle de récupération étape par étape si vous avez été exploité.

Si vous soupçonnez ou confirmez une exploitation, suivez cette liste de contrôle priorisée :

1. Mettez le site hors ligne ou passez-le en mode maintenance (si la suppression est sévère).
2. Prenez une sauvegarde complète (fichiers + base de données) pour analyse judiciaire.
3. Faites tourner tous les identifiants administratifs (mots de passe forts + 2FA).
4. Déconnectez tous les sessions utilisateur (invalidez les cookies).
5. Désactivez ou supprimez immédiatement le plugin vulnérable.
6. Restaurez le contenu supprimé à partir de la sauvegarde propre la plus récente si disponible.
7. Si la sauvegarde n'est pas disponible, vérifiez wp_posts et postmeta pour reconstruire les enregistrements ; examinez le cache d'objet ou le cache web comme sources possibles.
8. Scannez le site pour détecter des logiciels malveillants/portes dérobées et supprimez tout ce qui est trouvé.
9. Auditez les utilisateurs : supprimez les comptes administratifs inconnus.
10. Renforcez le site : activez les règles WAF, appliquez 2FA, limitez les IP administratives, définissez des politiques de mots de passe forts.
11. Corrigez le plugin avec une mise à jour officielle dès qu'elle est disponible ou appliquez un correctif de développeur avec des vérifications de nonce + de capacité.
12. Surveillez les réinfections ou les exploitations répétées au cours des 30 à 90 jours suivants.

Si vous avez besoin d'aide pendant la récupération, envisagez d'utiliser un service de sécurité géré ou un répondant aux incidents WordPress expérimenté.

---

Meilleures pratiques préventives pour les propriétaires de sites et les développeurs.

• Gardez les plugins, thèmes et le cœur de WordPress à jour et appliquez rapidement les correctifs de sécurité.
• Évitez les plugins sans mises à jour récentes ou maintenance active.
• Utilisez le principe du moindre privilège : accordez des droits d'administrateur uniquement aux utilisateurs qui en ont réellement besoin.
• Activez l'authentification à deux facteurs pour tous les comptes administrateurs.
• Surveillez et limitez les installations de plugins et les scripts tiers.
• Appliquez des délais d'expiration de session et faites régulièrement tourner les identifiants.
• Utilisez un WAF géré et un scanner de logiciels malveillants (WP‑Firewall Basic fournit cela).
• Mettez en œuvre une journalisation des audits afin que vous puissiez voir qui a fait quoi et quand.
• Pour les développeurs : adoptez des pratiques de codage sécurisées (nonces, vérifications de capacité, rappels de permission de l'API REST, assainissement, échappement).
• Fournissez des valeurs par défaut sécurisées dans les plugins et documentez les étapes de durcissement nécessaires.

---

Exemples de requêtes de détection et de vérifications pour les administrateurs

Vérifiez les publications de jeux manquantes ou supprimées :

• Base de données : SELECT * FROM wp_posts WHERE post_type = 'jeu' ORDER BY post_date DESC;
• Vérifiez la corbeille : SELECT * FROM wp_posts WHERE post_status = 'corbeille' AND post_type = 'jeu';
• Journaux du serveur : grep "admin-post.php?action=delete_game" /var/log/nginx/access.log
• Journaux d'activité WP (si vous utilisez un plugin d'activité) : filtrez par actions ‘delete’ et comptes utilisateurs autour du moment de l'incident.

Si les journaux montrent des POST avec des en-têtes Referer ou Origin externes autour des événements de suppression, c'est un indicateur fort de CSRF.

---

Pourquoi les correctifs des fournisseurs sont importants et à quoi s'attendre

En fin de compte, les auteurs de plugins doivent corriger la cause profonde en ajoutant des vérifications de nonce, des vérifications de capacité et en suivant les meilleures pratiques de sécurité WP. Les correctifs virtuels et les règles WAF sont des défenses essentielles à court terme, mais la véritable solution doit venir du code du plugin.

Attendez-vous à ce qu'un correctif du fournisseur :

• Ajoute la génération et la vérification de nonce.
• Ajoutez des vérifications de capacité (current_user_can).
• Assainissez et validez les paramètres entrants.
• Déplacez éventuellement les points de terminaison dangereux vers l'API REST avec des rappels de permission appropriés.

Jusqu'à ce qu'une version corrigée soit disponible, suivez les mesures de défense ci-dessus.

---

À propos des plans de protection WP‑Firewall (aperçu rapide)

Nous proposons des plans échelonnés adaptés à différents besoins :

• Basique (gratuit)
  • Protection essentielle : pare-feu géré, bande passante illimitée, pare-feu d'application Web (WAF), scanner de logiciels malveillants et atténuation pour le Top 10 de l'OWASP.
• Standard ($50/an)
  • Tout ce qui est dans le plan de base, plus la suppression automatique de malware et la possibilité de mettre sur liste noire/liste blanche jusqu'à 20 IP.
• Pro ($299/an)
  • Tout ce qui est dans Standard, plus des rapports de sécurité mensuels, un patch virtuel automatique des vulnérabilités et l'accès à des modules complémentaires premium tels qu'un Responsable de Compte Dédié, l'Optimisation de Sécurité, le Jeton de Support WP, le Service WP Géré et le Service de Sécurité Géré.

Ces options vous permettent de choisir le bon équilibre entre automatisation, protection sans intervention et support humain.

---

Commencez à protéger votre site WordPress gratuitement aujourd'hui

Si vous souhaitez une protection immédiate et pratique pendant que vous évaluez et appliquez des corrections de développeur, essayez le plan de base (gratuit) de WP‑Firewall. Il comprend un pare-feu géré, un WAF, un scanner de logiciels malveillants et une couverture contre les risques du Top 10 de l'OWASP — l'essentiel pour arrêter les CSRF automatisés et de nombreuses autres tentatives d'exploitation courantes. Inscrivez-vous ici et obtenez une protection en quelques minutes : https://my.wp-firewall.com/buy/wp-firewall-free-plan/

---

Dernières réflexions — prenez le CSRF au sérieux même lorsque la gravité semble faible

Un score numérique CVSS donne une vue rapide, mais le tableau des risques au jour le jour dépend de l'utilisation généralisée du plugin vulnérable, du nombre de comptes utilisateurs privilégiés sur chaque site et de la question de savoir si les administrateurs laissent des sessions ouvertes. Les vulnérabilités CSRF sont particulièrement sournoises car elles nécessitent une ingénierie sociale plutôt qu'un compromis d'identifiants.

Si vous gérez un site qui utilise le plugin Games Catalog (≤ 1.2.0) ou des plugins similaires ayant des points de terminaison qui changent d'état, n'attendez pas. Appliquez les atténuations ci-dessus : restreignez l'accès administrateur, activez un WAF géré, désactivez ou mettez à jour le plugin lorsqu'une mise à jour sûre est disponible, et poussez les fournisseurs à remédier correctement avec des nonces et des vérifications de capacité.

Si vous avez besoin d'aide pour mettre en œuvre l'une des étapes de ce post — du déploiement temporaire de règles WAF à la réponse complète aux incidents et à l'atténuation — l'équipe de sécurité de WP‑Firewall peut vous aider. Notre plan de base gratuit vous offre une protection immédiate ; nos niveaux supérieurs fournissent une suppression automatisée, un patch virtuel et un support humain pour la récupération et le renforcement.

Restez en sécurité, restez prudent et faites des nonces et des vérifications de capacité une partie permanente de votre liste de contrôle de sécurité des plugins.

— Équipe de sécurité WP-Firewall