Un avis de sécurité a été publié à propos d’une vulnérabilité découverte dans le plugin Membership Plugin développé par StellarWP, qui permettait d’exposer des données sensibles liées à la configuration des paiements Stripe sur des sites WordPress utilisant ce plugin. Cette faille, exploitable sans aucune authentification, a reçu une note de gravité de 8.2 (High).

Plugin Membership par StellarWP

Le plugin Membership Plugin – Restrict Content de StellarWP est largement employé pour gérer des contenus payants ou réservés aux adhérents sur des sites WordPress. Il offre aux propriétaires de sites la possibilité de restreindre l’accès à des pages, articles et autres ressources, afin que seuls les utilisateurs connectés ou les abonnés payants puissent y accéder. On le retrouve fréquemment sur des plateformes d’adhésion, d’abonnement et sur des services fournissant du contenu protégé.

Vulnérable aux attaquants non authentifiés

Selon l’avis publié par Wordfence, la vulnérabilité pouvait être déclenchée par des attaquants sans nécessiter la création d’un compte WordPress ni une quelconque authentification. Autrement dit, aucun rôle utilisateur ou permission préalable n’était requis pour exploiter la faille. C’est précisément cette absence d’obligation d’authentification qui amplifie le danger : l’attaque peut être lancée à distance, de manière automatisée, et sans que le site cible n’ait préalablement été compromis.

Nature de la vulnérabilité

La faille provient d’un manque de contrôles de sécurité lors de la gestion des opérations liées à Stripe. Plus spécifiquement, le plugin ne protégeait pas correctement les données des Stripe SetupIntent, notamment la valeur nommée client_secret.

Un SetupIntent chez Stripe est utilisé lors d’un parcours de paiement pour enregistrer un moyen de paiement en vue d’opérations futures, sans générer de prélèvement immédiat. Chaque SetupIntent contient un champ client_secret qui est destiné à être transmis de façon sécurisée au navigateur du client lors du processus de configuration du paiement.

L’avis officiel de Wordfence précise :

« Le plugin Membership Plugin – Restrict Content pour WordPress est vulnérable à un défaut d’authentification (Missing Authentication) dans toutes les versions jusqu’à et incluant la 3.2.16, via la fonction rcp_stripe_create_setup_intent_for_saved_card en raison de l’absence d’une vérification des capacités.

De plus, le plugin ne vérifie pas une clé contrôlée par l’utilisateur, ce qui permet à des attaquants non authentifiés de divulguer les valeurs client_secret des Stripe SetupIntent pour n’importe quel abonnement. »

La documentation de Stripe indique que l’API des Setup Intents sert à préparer un moyen de paiement pour des prélèvements futurs, sans effectuer de paiement immédiat. Le champ client_secret doit rester confidentiel : il ne doit pas être stocké, journalisé ou exposé à quiconque autre que le client concerné.

Voici comment la documentation de Stripe décrit l’objectif des Setup Intents :

« Utilisez l’API Setup Intents pour configurer un moyen de paiement en vue de paiements futurs. C’est similaire à un paiement, mais aucun prélèvement n’est réalisé.

L’objectif est de sauvegarder et d’optimiser les informations de paiement pour les paiements futurs, en s’assurant que le moyen de paiement est correctement configuré pour toutes les situations. Lors de la mise en place d’une carte, par exemple, il peut être nécessaire d’authentifier le client ou de vérifier la validité de la carte auprès de la banque du client. Stripe met à jour l’objet SetupIntent tout au long de ce processus. »

La documentation de Stripe précise également que les valeurs client_secret sont destinées à être utilisées côté client pour réaliser des actions liées au paiement et doivent être transmises de façon sécurisée depuis le serveur vers le navigateur. Elles ne doivent ni être conservées dans des journaux, ni être exposées à des tiers non autorisés.

Extrait de la documentation de Stripe concernant la valeur client_secret :

« client_secret
Le client secret de cette Customer Session. Utilisé côté client pour établir un accès sécurisé au client désigné.

Le client secret peut être utilisé pour fournir un accès au client depuis votre front-end. Il ne doit pas être stocké, journalisé ou exposé à toute personne autre que le client concerné. Assurez-vous que TLS est activé sur toute page incluant le client secret. »

Faute de contrôles appropriés, les valeurs client_secret des SetupIntent pouvaient donc être découvertes par des personnes non autorisées. Concrètement, cela signifie que des données utilisées pour configurer des moyens de paiement liées à des adhésions ont été accessibles au-delà de la portée prévue.

Versions affectées

La vulnérabilité touchait toutes les versions du plugin jusqu’à et y compris la 3.2.16. Wordfence a attribué à ce problème un score CVSS de 8.2, en tenant compte de la sensibilité des données exposées et du fait qu’aucune authentification n’était requise pour exploiter la faille.

Un score de cet ordre reflète une vulnérabilité de haute gravité, exploitable à distance sans privilèges particuliers, ce qui rend l’application rapide d’un correctif d’autant plus critique pour les sites qui s’appuient sur le plugin pour gérer des abonnements ou du contenu restreint.

Disponibilité du correctif

Le plugin a reçu un correctif publié dans la version 3.2.17. Cette mise à jour introduit des vérifications manquantes — notamment des nonce et des contrôles de permissions — lors de l’ajout de moyens de paiement via Stripe, comblant ainsi les conditions qui avaient permis l’exposition des valeurs client_secret.

Un nonce est un jeton de sécurité à usage limité qui permet de s’assurer qu’une action sur un site WordPress a bien été initiée intentionnellement par un utilisateur autorisé et non par un attaquant externe.

Le journal des modifications du plugin signale les changements :

« 3.2.17
Sécurité : Ajout de vérifications de nonce et de permissions pour l’ajout de méthodes de paiement Stripe.
3.2.16
Sécurité : Amélioration de l’échappement et de la sanitisation pour les attributs des shortcodes [restrict] et [register_form]. »

Ce que doivent faire les propriétaires de sites

Les administrateurs de sites qui utilisent le plugin Membership Plugin – Restrict Content doivent mettre à jour leur installation vers la version 3.2.17 ou une version ultérieure sans délai.

Ne pas appliquer la mise à jour laisse la porte ouverte à l’exposition des valeurs client_secret des SetupIntent à des attaquants non authentifiés, ce qui peut compromettre la sécurité des moyens de paiement enregistrés pour des adhérents.

Voici une liste détaillée des mesures recommandées, avec des explications techniques et opérationnelles pour limiter les risques et vérifier l’impact potentiel :

• Mettre à jour immédiatement : appliquez la version 3.2.17 ou ultérieure du plugin sur tous les environnements (production, staging, test). Testez la mise à jour sur un environnement non critique avant de la déployer en production si possible.
• Vérifier les versions installées : contrôlez toutes les instances WordPress pour repérer les installations du plugin Membership Plugin et notez la version en cours d’utilisation. Vous pouvez rechercher le dossier du plugin dans /wp-content/plugins/restrict-content ou consulter l’interface d’administration > Extensions.
• Analyser les journaux : examinez les logs serveur (accès et erreurs), logs d’application et, le cas échéant, les journaux des pare-feu applicatifs (WAF) pour détecter des requêtes suspectes ciblant des endpoints liés à Stripe ou la fonction rcp_stripe_create_setup_intent_for_saved_card. Recherchez des motifs de requêtes répétées, des paramètres d’URL inhabituels et des accès depuis des adresses IP externes inconnues.
• Rechercher des fuites de données : vérifiez vos systèmes de logs centralisés, vos copies de sécurité, et les outils de monitoring pour vous assurer que les client_secret n’ont pas été stockés de manière non intentionnelle. Si vous identifiez des valeurs client_secret dans des fichiers logs, supprimez-les et considérez-les comme compromises.
• Rotation des clés et sessions : si vous suspectez qu’une exploitation a eu lieu, contactez Stripe pour examiner les SetupIntent concernés et, si nécessaire, révoquez ou régénérez les identifiants ou tokens pertinents. La rotation des clés API est une option à considérer si une compromission systémique des identifiants est suspectée.
• Renforcer la configuration : assurez-vous que TLS (HTTPS) est actif sur toutes les pages manipulant des données de paiement. Activez des en-têtes de sécurité (HSTS, Content Security Policy) et limitez l’exposition de points de terminaison sensibles.
• Activer la surveillance en continu : mettez en place des alertes pour détecter toute activité anormale relative aux opérations de paiement et aux endpoints Stripe. Un système de détection d’intrusion (IDS) ou un WAF peut bloquer des tentatives d’exploitation automatisées.
• Scanner votre site : lancez des analyses de sécurité automatisées et, si possible, des audits manuels ciblés sur les points d’intégration Stripe pour identifier d’autres éventuelles erreurs de configuration ou failles logicielles.
• Conserver des sauvegardes récentes : assurez-vous que des sauvegardes complètes et récentes sont disponibles afin de pouvoir restaurer l’état antérieur si une intervention corrective s’avère nécessaire.
• Informer les parties prenantes : si vous gérez un site pour des clients ou des utilisateurs finaux, établissez un message transparent indiquant que vous avez appliqué le correctif, pourquoi il était nécessaire et les mesures prises pour vérifier l’absence d’impact.

Comment vérifier si vous avez été affecté

Déterminer si une exploitation a eu lieu peut nécessiter une combinaison d’analyses techniques et opérationnelles. Voici des étapes concrètes pour évaluer l’impact :

• Rechercher des requêtes anormales : filtrez les journaux d’accès pour repérer des appels HTTP vers des endpoints contenant des paramètres liés à Stripe ou vers des chemins du plugin /wp-content/plugins/restrict-content/. Les tentatives automatisées peuvent générer un grand nombre de requêtes sur une courte période.
• Inspecter les logs applicatifs : si votre application journalise les payloads ou les réponses, recherchez la présence de champs client_secret ou d’objets SetupIntent. Toute découverte indique une possible exposition.
• Vérifier l’intégrité des fichiers : contrôlez s’il y a eu des modifications récentes du code du plugin ou des fichiers WordPress qui pourraient indiquer une compromission. Utilisez des outils de contrôle d’intégrité (hash, git) si disponibles.
• Examen des comptes utilisateurs : même si la vulnérabilité permette l’accès sans authentification, il est important de vérifier que les comptes administrateurs n’ont pas été utilisés de manière malveillante à la suite d’une attaque séparée.
• Consulter l’historique Stripe : vérifiez dans le tableau de bord Stripe si des SetupIntents ou des méthodes de paiement ont été créés de façon suspecte ou sans correspondance avec des actions utilisateur légitimes.

Impact technique et risques associés

La divulgation d’un champ client_secret d’un SetupIntent n’expose pas automatiquement l’ensemble des données de carte (les numéros de carte complets restent protégés par Stripe), mais elle peut néanmoins permettre à un attaquant :

• d’achever certaines opérations côté client en utilisant ce client_secret pour compléter l’enregistrement d’un moyen de paiement sur un navigateur distant,
• d’effectuer des manipulations permettant d’associer ce moyen de paiement à d’autres comptes ou sessions si d’autres contrôles côté serveur sont défaillants,
• d’orchestrer des attaques plus larges impliquant l’usurpation d’identité d’abonnés (par exemple manipulation d’abonnements, tentatives d’accès à du contenu restreint via des moyens de paiement détournés),
• d’extraire des informations sensibles du flux d’inscription ou de configuration du paiement si des données additionnelles sont transmises par le même mécanisme vulnérable.

En résumé, même si la faille ne donne pas accès directement aux données de carte brute, l’exposition des tokens et secrets liés aux moyens de paiement est suffisante pour constituer une atteinte sérieuse à la sécurité des opérations de paiement et à la confidentialité des abonnés.

Comprendre la note CVSS et l’importance de la mise à jour

La note CVSS 8.2 attribuée par Wordfence reflète un risque élevé : une vulnérabilité distante, exploitable sans authentification, exposant des informations sensibles. Un tel score implique que l’exploit est relativement simple à automatiser et qu’il peut être massivement ciblé contre des installations vulnérables.

Dans ce contexte, maintenir les plugins et le noyau WordPress à jour est une première ligne de défense essentielle. Les correctifs comme celui introduit en 3.2.17 corrigent des lacunes de validation et d’autorisation qui, lorsqu’elles sont ignorées, ouvrent la porte à des atteintes graves.

Bonnes pratiques pour l’intégration de passerelles de paiement

Pour réduire la surface d’attaque et limiter les conséquences en cas de vulnérabilité future, voici des recommandations générales applicables à toute intégration de solutions de paiement :

• Séparer les responsabilités : limitez les droits des extensions et scripts qui manipulent les paiements. Appliquez le principe du moindre privilège pour les comptes et les processus.
• Valider et sanitiser : toute donnée provenant du client doit être validée et nettoyée côté serveur, même si elle semble provenir d’une source de confiance.
• Utiliser des tokens : privilégiez les tokens temporaires et les mécanismes qui évitent le passage de données sensibles dans des logs ou via des URL en clair.
• Activer TLS : forcez le HTTPS sur toutes les pages manipulant des opérations de paiement et sur les endpoints d’API.
• Réduire la persistance : n’enregistrez pas les secrets côté serveur, et évitez de stocker des valeurs client_secret dans des bases de données ou des fichiers de logs.
• Surveiller et alerter : mettez en place des alertes pour les modifications de configurations sensibles et pour toute utilisation anormale des API Stripe.
• Audits réguliers : effectuez des revues de sécurité périodiques des plugins et des thèmes, surtout lorsqu’ils intègrent des fonctions de paiement.

Responsabilité et communication après divulgation

La découverte et la divulgation de cette vulnérabilité suivent la chaîne de responsabilités attendue : identification par une entité de sécurité (Wordfence), notification responsable au projet du plugin, puis publication d’un correctif. Les équipes ont documenté la correction dans le changelog officiel du plugin.

Pour les propriétaires de sites, la communication transparente à destination des utilisateurs concernés (par exemple, abonnés) est importante si vous concluez qu’une exposition a pu affecter leurs moyens de paiement. Expliquez les actions prises, les mesures de mitigation et les étapes recommandées, tout en évitant les formulations alarmistes.

Conclusion

La vulnérabilité découverte dans le plugin Membership Plugin – Restrict Content de StellarWP mettait en péril la confidentialité des valeurs client_secret associées aux Stripe SetupIntent, et permettait à des attaquants non authentifiés d’y accéder. Le correctif publié en 3.2.17 corrige le problème en ajoutant les vérifications de nonce et de permissions nécessaires.

Les administrateurs de sites doivent appliquer la mise à jour sans délai, vérifier leurs journaux et configurations, et envisager des actions complémentaires (rotation d’identifiants, audit, surveillance renforcée) si une exploitation est suspectée. Adopter des bonnes pratiques pour les intégrations de paiement et une politique de mise à jour rigoureuse réduit significativement le risque d’incidents similaires à l’avenir.

Featured Image by Shutterstock/file404

Références

• Avis Wordfence sur la vulnérabilité
• Documentation Stripe — Setup Intents
• Documentation Stripe — client_secret (Customer Session)
• Journal des modifications officiel du plugin (changelog)