| Nom du plugin | Équipe HRM |
|---|---|
| Type de vulnérabilité | vulnérabilité du contrôle d'accès |
| Numéro CVE | CVE-2026-27351 |
| Urgence | Faible |
| Date de publication du CVE | 2026-06-02 |
| URL source | CVE-2026-27351 |
Contrôle d'accès défaillant dans le plugin Crew HRM (<=1.2.2, CVE‑2026‑27351) — Ce que cela signifie pour les propriétaires de sites WordPress et comment WP‑Firewall vous protège
Aujourd'hui, nous publions une analyse pratique et orientée vers les experts d'une vulnérabilité récemment divulguée liée à un contrôle d'accès défaillant affectant le plugin WordPress “Crew HRM” (versions jusqu'à et y compris 1.2.2), suivie sous le nom de CVE‑2026‑27351. Nous avons écrit cela pour aider les propriétaires de sites, les administrateurs et les développeurs à comprendre :
- quel est le problème et pourquoi il est important,
- des scénarios d'exploitation réalistes et l'impact probable,
- comment détecter si votre site a été ciblé ou compromis,
- des mesures d'atténuation immédiates et à long terme que vous pouvez prendre dès maintenant,
- comment WP‑Firewall aide à vous protéger — même si vous ne pouvez pas mettre à jour immédiatement.
Ceci est écrit de notre perspective en tant qu'équipe de sécurité WordPress qui gère un pare-feu d'application web WordPress (WAF) et fournit des services de sécurité gérés. Nous nous concentrons sur des conseils techniques clairs et des étapes pratiques que vous ou votre équipe d'hébergement pouvez prendre immédiatement pour réduire les risques.
Résumé rapide
- Vulnérabilité : Contrôle d'accès défaillant dans le plugin Crew HRM (<= 1.2.2).
- CVE : CVE‑2026‑27351.
- Classification : OWASP A1 — Contrôle d'accès défaillant.
- CVSS : 5.4 (gravité moyenne / faible-moyenne pour les déploiements WordPress typiques).
- Versions concernées : <= 1.2.2.
- Version corrigée : 1.2.3 (mise à jour recommandée).
- Privilège requis pour exploiter : Abonné (c'est-à-dire, un utilisateur authentifié à faible privilège).
- Risque principal : Un utilisateur à faible privilège peut effectuer des actions privilégiées en raison de l'absence de vérifications d'autorisation.
Bien que le score CVSS et la classification du fournisseur qualifient cela de priorité “faible” par rapport aux RCE distants non authentifiés ou aux SQLi critiques, les problèmes de contrôle d'accès défaillant peuvent être très utiles aux attaquants. Lorsqu'ils sont combinés avec d'autres faiblesses (mots de passe administratifs faibles, comptes utilisateurs par défaut, thèmes/plugins vulnérables ou hébergement mal configuré), ils deviennent une pierre angulaire fiable dans des compromissions réelles.
Qu'est-ce que le “contrôle d'accès défaillant” ?
Le contrôle d'accès défaillant couvre une classe de problèmes où un utilisateur est capable d'effectuer des actions qu'il ne devrait pas pouvoir effectuer parce que l'application n'a pas vérifié si l'utilisateur est autorisé. Les causes typiques incluent :
- vérifications de capacité manquantes (par exemple, échec d'appeler current_user_can()),
- vérifications de nonce manquantes pour les soumissions de formulaires ou les points de terminaison AJAX,
- points de terminaison de l'API REST manquant des rappels de permission,
- dépendre de la logique côté client (par exemple, masquer l'interface utilisateur) plutôt que d'imposer des vérifications côté serveur.
Dans les plugins WordPress, les développeurs doivent vérifier à la fois l'authentification (l'utilisateur est-il connecté ?) et l'autorisation (l'utilisateur a-t-il le rôle / la capacité requise ?) pour toute action qui modifie la configuration, lit des données sensibles ou change l'état du compte utilisateur. Lorsque cela est omis, tout utilisateur authentifié — même un abonné — peut être en mesure d'appeler la fonction directement (via admin-ajax.php ou l'API REST) et de déclencher un comportement privilégié.
Comment cette vulnérabilité spécifique fonctionne (niveau élevé)
La vulnérabilité signalée indique que certains points de terminaison ou fonctions de plugin sont appelables par des utilisateurs à faible privilège parce que l'auteur du plugin a échoué à valider les privilèges de l'appelant ou a omis une vérification de nonce/de permission appropriée. L'avis indique qu'un compte d'abonné est suffisant pour effectuer l'action ou les actions en question.
Causes racines techniques possibles (modèles communs que nous voyons) :
- Un gestionnaire de formulaire/action admin est accessible via admin-ajax.php sans une vérification appropriée de current_user_can() ou check_ajax_referer().
- Un point de terminaison REST est enregistré sans un permission_callback approprié.
- Une fonction destinée à être accessible uniquement par des administrateurs est invoquée par un chemin public ou à faible privilège.
Parce que le bug est lié à une autorisation manquante plutôt qu'à une exécution de code à distance, l'exploitation nécessite un compte authentifié sur le site cible. Cependant, de nombreux sites WordPress permettent l'enregistrement des utilisateurs ou ont des comptes d'abonnés existants, et dans certains cas, les attaquants obtiennent des identifiants par le biais de credential stuffing, d'ingénierie sociale ou d'incidents complètement non liés sur le même site (par exemple, une inscription à une newsletter divulguée).
Scénarios d'exploitation réalistes
Même si la vulnérabilité elle-même n'exécute pas de PHP arbitraire, la fonctionnalité privilégiée accessible pourrait être abusée de plusieurs manières :
- Exposer des données personnelles/employées : Les plugins RH stockent couramment des informations sensibles sur les employés. Si un utilisateur à faible privilège peut récupérer ou exporter des données RH, des problèmes de confidentialité et de conformité (RGPD, HIPAA dans certains contextes) se posent.
- Modifier la configuration du plugin : Un attaquant pourrait changer les paramètres du plugin pour activer l'exportation de données ou ajouter des URL malveillantes qui exfiltrent des données.
- Créer ou modifier des comptes utilisateurs : Si l'action vulnérable permet de créer des utilisateurs ou d'élever des rôles, cela peut conduire à un accès administratif persistant.
- Chaîner avec d'autres vulnérabilités : Un contrôle d'accès défaillant peut être combiné avec XSS ou d'autres défauts pour créer des chaînes de mouvement latéral ou d'escalade de privilèges.
- Installation de porte dérobée : Si un attaquant peut écrire du contenu qui est ensuite exécuté ou déclenche un mécanisme de mise à jour non sécurisé, il peut persister sur le site.
Remarque : la facilité d'exploitation dépend de la configuration de votre site (inscriptions ouvertes, nombre de comptes d'abonnés, configurations multi-sites). Une seule exploitation réussie est souvent un point d'entrée pour des attaques ultérieures.
Pourquoi le CVSS pourrait sous-estimer le risque commercial réel
Le CVSS est une métrique comparative utile, mais il ne capture pas pleinement l'impact commercial. Le CVSS se concentre sur la gravité technique et les facteurs d'exploitation communs. Pour les propriétaires de sites WordPress :
- Un score technique “ moyen ” qui permet l'exfiltration des données des dossiers des employés peut avoir un impact commercial élevé.
- Même une exploitation de faible sophistication peut entraîner des dommages à la réputation, des amendes réglementaires ou une perte d'accès et de revenus.
- Les écosystèmes WordPress voient fréquemment des campagnes d'exploitation massives qui automatisent l'utilisation des vulnérabilités des utilisateurs à faible privilège à grande échelle.
Nous considérons cela comme actionnable : mettez à jour maintenant et appliquez des mesures d'atténuation si une mise à jour immédiate n'est pas possible.
Comment vérifier rapidement si vous êtes affecté
- Inventaire des plugins : Connectez-vous à votre tableau de bord WordPress, allez dans Plugins → Plugins installés, et vérifiez la version de Crew HRM. Si c'est 1.2.2 ou plus ancien, vous êtes concerné.
- Vérifiez les comptes d'abonnés : Allez dans Utilisateurs → Tous les utilisateurs et examinez les comptes d'abonnés existants. Recherchez des sous-comptes inconnus ou récemment créés.
- Examinez les journaux d'accès pour des demandes suspectes provenant de comptes authentifiés :
- Recherchez des requêtes POST vers admin‑ajax.php ou des points de terminaison de l'API REST qui correspondent aux opérations HRM.
- Des IP inhabituelles, un accès rapide et répété ou des demandes provenant de géolocalisations inattendues sont des signaux.
- Vérifiez les paramètres du plugin et les données RH pour des modifications non autorisées récentes, de nouvelles exportations ou des jetons/points de terminaison inconnus.
- Analysez votre site : Effectuez une analyse complète des logiciels malveillants et un contrôle de l'intégrité des fichiers. Recherchez des fichiers récemment modifiés, de nouveaux utilisateurs administrateurs ou du code malveillant.
Si vous trouvez des signes d'exploitation probable, considérez le site comme potentiellement compromis et passez aux étapes de réponse à l'incident ci-dessous.
Liste de contrôle d'action immédiate (ordre recommandé)
Si vous gérez un site avec Crew HRM <= 1.2.2, suivez ces étapes immédiatement :
- Mettez à jour le plugin vers la version 1.2.3 (ou la dernière version disponible).
- C'est la correction principale — les auteurs du plugin ont publié un correctif pour ajouter les vérifications manquantes.
- Faites cela pendant une période de faible trafic si possible ; sauvegardez toujours avant les mises à jour.
- Si vous ne pouvez pas mettre à jour en toute sécurité immédiatement :
- Désactivez temporairement le plugin via wp‑admin ou via SFTP en renommant le dossier du plugin (wp‑content/plugins/crew‑hrm).
- Si vous devez le garder actif pour des raisons professionnelles, appliquez des contrôles compensatoires (voir les atténuations WP‑Firewall ci-dessous).
- Réinitialisez les mots de passe de tous les comptes administrateurs et autres comptes privilégiés.
- Encouragez ou imposez des mots de passe forts et annulez les sessions lorsque cela est possible.
- Passez en revue les comptes utilisateurs :
- Supprimez ou suspendez les comptes d'abonnés inconnus.
- Auditez les utilisateurs avec des privilèges élevés et supprimez les rôles inutiles.
- Bloquez ou limitez les points de terminaison potentiellement abusifs :
- Au niveau du pare-feu, bloquez les demandes non authentifiées ou à faible privilège vers les points de terminaison de plugin ou les actions admin‑ajax utilisées par le plugin. Voir les suggestions ci-dessous.
- Effectuez une analyse complète et un examen judiciaire :
- Vérifications de l'intégrité des fichiers, audit de la base de données pour les changements récents et analyse approfondie des logiciels malveillants.
- Restaurez à partir de sauvegardes connues et fiables si vous confirmez une compromission et ne pouvez pas remédier complètement.
- Informez les parties prenantes et les régulateurs si la loi ou la politique l'exige.
Nous développons les atténuations au niveau du pare-feu et les mesures défensives à long terme dans les sections suivantes.
Comment WP‑Firewall peut protéger votre site dès maintenant
Nous abordons la protection avec plusieurs couches : prévenir les demandes malveillantes, détecter les comportements suspects et corriger virtuellement les vulnérabilités connues lorsque les mises à jour ne sont pas immédiatement réalisables.
Voici les manières concrètes dont notre produit et nos services aident :
- Règles WAF gérées (patches virtuels)
- Nous pouvons déployer des règles WAF ciblées pour bloquer les modèles d'exploitation de cette vulnérabilité au niveau HTTP. Cela empêche les demandes malveillantes d'atteindre l'environnement WordPress pendant que la mise à jour du plugin est programmée.
- Le patching virtuel est particulièrement utile pour les sites qui ne peuvent pas être mis à jour immédiatement en raison de contraintes de compatibilité ou de mise en scène.
- Blocage des abus à faible privilège
- Notre WAF peut être configuré pour bloquer ou limiter les demandes POST/PUT vers les points de terminaison de plugin si l'appelant ne présente pas de cookies authentifiés valides et de nonces attendus.
- Nous pouvons restreindre l'accès aux pages d'administration de plugin et à des points de terminaison spécifiques à des plages IP ou uniquement à des rôles authentifiés à privilège élevé.
- Limitation de taux et détection d'anomalies
- Nous détectons les tentatives répétées d'exercer la fonctionnalité du plugin et limitons ou bloquons automatiquement les adresses IP fautives.
- Des anomalies telles que de grandes demandes d'exportation initiées par des comptes d'abonnés déclenchent des alertes.
- Réponse gérée et nettoyage
- Nos intervenants en cas d'incident aident à isoler les sites affectés, à examiner les journaux, à supprimer les signes de compromission et à fournir des conseils pour restaurer les opérations en toute sécurité.
- Surveillance continue et alertes
- Pour les clients ayant des plans gérés, nous surveillons en continu les modèles suspects liés à cette classe de vulnérabilité et alertons les administrateurs en temps réel.
Parce que cette vulnérabilité nécessite un utilisateur authentifié pour être exploitée, bloquer les enregistrements suspects, les adresses IP ou l'accès direct aux points de terminaison du plugin réduit considérablement le risque.
Exemples de stratégies d'atténuation WAF (génériques, sûres à mettre en œuvre)
Voici des modèles et techniques génériques que nous appliquons couramment comme protections temporaires ; chaque site nécessite un réglage avant déploiement.
- Bloquer l'accès POST direct aux points de terminaison d'administration du plugin suspects depuis des comptes non administrateurs :
- Refuser tout POST aux URI contenant “/wp‑admin/admin‑ajax.php” où les paramètres de requête ou les corps POST incluent des noms d'actions spécifiques au plugin (par exemple, des actions commençant par hrm_, crew_ ou des jetons de nom de plugin). Utilisez des modèles conservateurs — essayez d'éviter les faux positifs.
- Exiger un cookie d'admin authentifié pour les points de terminaison sensibles :
- Si un point de terminaison doit être accessible uniquement par des administrateurs, imposez que les requêtes contiennent des cookies d'admin WordPress (généralement la présence d'un cookie de session connecté et des jetons d'authentification correspondants).
- Limiter les points de terminaison d'exportation/téléchargement :
- Appliquez des limites de taux aux points de terminaison qui génèrent des exports ou des téléchargements de données lourds afin qu'un seul abonné ne puisse pas exfiltrer massivement.
- Bloquer les enregistrements automatisés et la création d'utilisateurs suspects :
- Activer CAPTCHA et limiter le taux de nouvelles inscriptions. Prévenir les fournisseurs d'emails jetables si approprié.
- Géobloquer ou mettre en quarantaine les nouveaux comptes :
- Pour les périodes de risque accru, restreindre l'accès depuis des géographies inhabituelles ou placer les nouveaux utilisateurs dans une file d'attente de révision.
Important: Ce sont des atténuations génériques. Nous recommandons fortement de tester toute règle en mode surveillance/apprentissage d'abord pour éviter des interruptions de service accidentelles.
Détection — signes qu'un attaquant a tenté ou réussi
- Exportations de données inattendues : vérifiez les CSV récemment créés, les exports ou les grandes sauvegardes de base de données initiées par des comptes qui n'en ont pas besoin.
- Nouveaux comptes administrateurs ou éditeurs que vous n'avez pas créés.
- Changements récents dans les paramètres des plugins ou entrées de configuration étranges.
- Tâches planifiées inattendues (wp‑cron) qui font référence à des scripts de plugins.
- Trafic POST inhabituel vers admin‑ajax.php avec des paramètres d'action spécifiques au plugin.
- Pics anormaux d'activité du serveur ou de la base de données, ou trafic sortant élevé.
- Code inconnu inséré dans les fichiers de thème, mu‑plugins ou répertoires de téléchargements.
Si vous voyez ces indicateurs, supposez une compromission jusqu'à preuve du contraire. Conservez les journaux (journaux du serveur web, journaux d'application, journaux de base de données) pour une analyse judiciaire.
Flux de travail de réponse à l'incident et de remédiation
Si une compromission est suspectée, suivez ce flux de travail :
- Isoler:
- Mettez le site en mode maintenance, bloquez le trafic des IP suspectes au niveau du WAF, ou déconnectez le site de l'accès public si c'est grave.
- Préserver:
- Collectez les journaux et les instantanés pour un examen judiciaire. Ne vous fiez pas uniquement au panneau de contrôle d'hébergement — rassemblez les journaux bruts du serveur web, PHP et de la base de données.
- Identifier :
- Déterminez le(s) point(s) d'entrée : recherchez les points de terminaison de plugin exploités, les comptes inhabituels ou les actions suspectes complétées.
- Supprimez :
- Nettoyez ou supprimez les fichiers malveillants et les entrées de base de données.
- Si le nettoyage est incertain, restaurez à partir d'une sauvegarde antérieure à la compromission.
- Correctif :
- Mettez à jour le plugin Crew HRM vulnérable vers 1.2.3 (ou la dernière version).
- Mettez à jour le cœur de WordPress et tous les autres plugins et thèmes vers les versions actuelles.
- Récupérer:
- Réémettez les mots de passe et faites tourner les clés API. Forcez la déconnexion de toutes les sessions.
- Vérifiez la fonctionnalité du site et surveillez les journaux pour des tentatives de ré-entrée.
- Signalez et apprenez :
- Si des données personnelles ont été exposées, respectez les lois locales sur la notification des violations.
- Effectuez un post-mortem et renforcez les systèmes pour éviter des problèmes similaires.
Nos clients de réponse aux incidents gérés bénéficient d'un support prioritaire et d'aide pour les enquêtes et la récupération.
Recommandations de durcissement pour réduire les risques futurs
- Tenez tout à jour
- Corrigez rapidement le cœur de WordPress, les plugins et les thèmes. Maintenez un environnement de staging pour tester les mises à jour.
- Appliquer le principe du moindre privilège
- Limitez les rôles et privilèges des utilisateurs. Ne donnez pas de capacités d'éditeur ou d'auteur aux comptes qui n'en ont pas besoin. Supprimez les comptes d'abonnés inutiles.
- Renforcez l'inscription et l'intégration
- Utilisez CAPTCHA, vérification par e-mail ou des flux de travail sur invitation uniquement pour réduire les comptes frauduleux.
- Utilisez des nonces et des vérifications de capacité dans le développement
- Si vous développez des plugins/thèmes, vérifiez toujours les nonces, current_user_can() et définissez des rappels de permission pour les points de terminaison REST.
- Mettez en œuvre l'authentification multi-facteurs (MFA).
- La MFA réduit considérablement le risque de prise de contrôle de compte par bourrage d'identifiants ou phishing.
- Auditez régulièrement le code des plugins (en particulier les plugins qui gèrent des PII).
- Les plugins RH et de paie stockent des données personnelles sensibles. Traitez-les comme à haut risque et auditez leur source et la réputation de l'auteur.
- Surveillez les journaux et appliquez la détection d'anomalies.
- La surveillance continue détecte les activités suspectes tôt.
- Utilisez un WAF géré et un scan de vulnérabilités.
- Un WAF correctement configuré bloque de nombreuses classes d'attaques et peut mettre en œuvre des correctifs virtuels pour les vulnérabilités connues.
Divulgation responsable et transparence.
Les chercheurs en sécurité jouent un rôle essentiel dans l'amélioration de l'écosystème WordPress. Ce bug a été signalé de manière responsable (chronologie de divulgation : signalé au développeur du plugin fin 2025 ; avis rendu public mi-2026) et a un correctif disponible. Nous recommandons toujours aux propriétaires de sites de mettre à jour rapidement et d'appliquer des contrôles compensatoires s'ils ne peuvent pas corriger immédiatement.
Nous recommandons également aux auteurs de plugins de suivre les meilleures pratiques de codage sécurisé : vérifiez toujours les permissions de l'appelant côté serveur et utilisez des nonces et des rappels de permission pour les points de terminaison AJAX et REST.
Foire aux questions (FAQ)
Q : Si mon site n'a pas d'abonné ou d'enregistrement public activé, suis-je en sécurité ?
R : Le risque est considérablement réduit, mais vérifiez toujours les comptes compromis. Parfois, les attaquants peuvent créer des abonnés via d'autres plugins vulnérables ou par l'assistance d'un administrateur (ingénierie sociale). Appliquez toujours une défense en profondeur.
Q : La désactivation du plugin supprime-t-elle le risque ?
R : En général oui — si le code du plugin n'est pas exécuté, la vulnérabilité ne peut pas être déclenchée. Cependant, si le site a déjà été compromis, la désactivation ne supprime pas les portes dérobées qui ont pu être installées. Effectuez un scan.
Q : Les scanners automatisés détectent-ils cela immédiatement ?
R : Certains flux de vulnérabilités répertorieront rapidement ce problème, mais la détection de l'exploitation sur votre site nécessite un examen des journaux et une surveillance active.
Q : WP‑Firewall peut-il me protéger automatiquement même si j'oublie de mettre à jour ?
R : Oui — notre WAF géré peut déployer des correctifs virtuels pour bloquer les tentatives d'exploitation des vulnérabilités connues pendant que vous planifiez et testez les mises à jour. Le patching virtuel est une atténuation, pas un remplacement des mises à jour.
Exemples pratiques : ce que nous recherchons dans les journaux (pour votre équipe admin/dev)
Voici des modèles d'exemple à examiner dans vos journaux (ceux-ci sont illustratifs et doivent être adaptés à chaque site) :
- POSTs vers admin‑ajax.php où le paramètre “action” inclut hrm, crew, staff, employee, export, ou des mots-clés similaires.
- POSTs vers des points de terminaison REST tels que /wp/v2/crew‑hrm ou /wp/v2/hrm/ avec des contextes d'authentification non administratifs.
- Requêtes provenant d'ID d'utilisateur authentifiés (ID de cookie) qui déclenchent ensuite des téléchargements de fichiers volumineux ou des exports de base de données.
Lorsque vous voyez ces modèles associés à des comptes d'abonnés ou à des comptes inconnus, escaladez à une enquête manuelle.
Commencez à protéger votre site avec WP‑Firewall Free
Protégez votre site WordPress avec une protection essentielle et sans coût de WP‑Firewall. Notre plan de base gratuit comprend un pare-feu géré, une bande passante illimitée, un WAF activement maintenu, un scanner de logiciels malveillants et une atténuation pour le OWASP Top 10 — tout ce dont vous avez besoin pour réduire l'exposition pendant que vous mettez à jour et renforcez votre site.
Commencez votre plan gratuit ici :
https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Pourquoi cela aide : Le plan gratuit vous offre le bouclier immédiat d'un WAF géré et d'un scan de logiciels malveillants afin que vous n'ayez pas à attendre que les mises à jour des plugins soient appliquées sur tous les sites. C'est une étape rapide et efficace pour réduire le risque de contrôle d'accès défaillant et de nombreuses autres vulnérabilités.
Liste de contrôle finale — que faire dès maintenant.
- Vérifiez la version du plugin : si Crew HRM <= 1.2.2, planifiez une mise à jour immédiate vers 1.2.3.
- Si vous ne pouvez pas mettre à jour maintenant, désactivez temporairement le plugin ou activez un correctif virtuel via WP‑Firewall.
- Auditez les comptes utilisateurs — supprimez les abonnés inconnus et réinitialisez les mots de passe administratifs.
- Activer l'authentification multi-facteurs pour tous les comptes privilégiés.
- Exécutez un scan complet du site pour détecter les logiciels malveillants et examinez les journaux pour une activité suspecte.
- Appliquez des contrôles d'enregistrement stricts (CAPTCHA, vérification par e-mail).
- Envisagez un service de sécurité géré ou un WAF pour bloquer les tentatives d'exploitation pendant que vous remédiez.
Notes de clôture de WP‑Firewall
Les vulnérabilités de contrôle d'accès brisé comme CVE‑2026‑27351 sont un rappel opportun : la sécurité concerne à la fois la correction du code et les défenses en couches. Même lorsqu'un problème spécifique est étiqueté “ faible ”, l'impact commercial peut être sévère si des données sensibles sont exposées ou si des attaquants peuvent combiner plusieurs faiblesses.
Si vous gérez des sites WordPress, considérez cela comme une mise à jour programmée et une tâche d'atténuation : appliquez rapidement le correctif, renforcez votre environnement et assurez-vous d'avoir un WAF et une surveillance en place pour détecter les comportements suspects tôt.
Si vous avez besoin d'aide — que ce soit un correctif virtuel temporaire, un examen judiciaire ou une surveillance continue — notre équipe est disponible pour vous assister. Commencez avec notre plan de protection de base gratuit et voyez comment les règles WAF gérées et le scan continu peuvent réduire le risque immédiatement : https://my.wp-firewall.com/buy/wp-firewall-free-plan/
Soyez prudent,
Équipe de sécurité WP-Firewall
Références et lectures complémentaires
- CVE‑2026‑27351 (avis public)
- OWASP Top 10 — conseils sur le contrôle d'accès défaillant
- Manuel du développeur WordPress — nonces, current_user_can() et permission_callback REST
(Si vous avez besoin d'une réponse adaptée pour un site spécifique, incluez les journaux du serveur et les informations sur la version du plugin lorsque vous contactez notre équipe — nous vous aiderons à prioriser les prochaines étapes.)
