Le 6 octobre 2026, NVD a publié deux CVE critiques sur Payload, le CMS headless open source en TypeScript. L'une touche le plugin officiel @payloadcms/plugin-stripe, l'autre le jeton d'authentification émis à la connexion. Les deux sont corrigées dans Payload 3.90.0.
Le point commun : dans les deux cas, une option de configuration facultative ouvre un chemin que l'application n'avait pas prévu. Si tu utilises Payload, la question n'est pas seulement « quelle version ? » mais aussi « quelles options ai-je activées ? ».
| CVE | Composant | CVSS 3.1 | Vecteur | Publication NVD | CISA KEV |
|---|---|---|---|---|---|
| CVE-2026-105848 | @payloadcms/plugin-stripe | 9.6 (CRITICAL) | AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:N | 2026-10-06 | non (à la date de rédaction) |
| CVE-2026-105863 | Payload (authentification) | 9.4 (CRITICAL) | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L | 2026-10-06 | non (à la date de rédaction) |
CVE-2026-105848 — le proxy REST Stripe du plugin
Ce que fait la faille
Le plugin Stripe de Payload propose un proxy REST optionnel vers l'API Stripe. NVD le résume ainsi :
an authenticated user who can reach the enabled optional Stripe REST proxy can perform unintended Stripe operations.
Un utilisateur authentifié, même peu privilégié (PR:L), qui atteint ce proxy peut déclencher des opérations Stripe qui ne lui étaient pas destinées. Le proxy parle à Stripe avec la clé secrète du serveur : ce que l'utilisateur obtient, ce sont les droits de cette clé, pas les siens.
Pourquoi c'est grave
Le S:C (changement de portée) dit l'essentiel : l'impact dépasse Payload et atteint ton compte Stripe. Selon les droits de la clé utilisée, cela peut concerner la lecture de données clients et de paiements, ou des opérations qui modifient l'état du compte. NVD ne détaille pas lesquelles : je ne vais pas les énumérer à sa place.
Conditions
- Le plugin Stripe est installé et le proxy REST optionnel est activé.
- L'attaquant dispose d'un compte authentifié sur l'instance. Si l'inscription publique est ouverte, cette condition est triviale.
Versions
Affectées : versions de @payloadcms/plugin-stripe antérieures à 3.90.0, et canary antérieures à 4.0.0-canary.34. Corrigées : 3.90.0 et 4.0.0-canary.34, selon la description NVD.
CVE-2026-105863 — un champ mappé sur un claim d'authentification réservé
Ce que fait la faille
Payload permet de faire figurer certains champs de la collection utilisateurs dans le jeton émis à la connexion. NVD décrit le défaut :
a custom field option that maps a field to a reserved authentication claim name can place unintended values in the authentication token issued at login.
Si un champ est configuré pour être copié sous un nom de claim que Payload utilise lui-même pour l'authentification, sa valeur peut se retrouver à la place de la valeur légitime dans le jeton. Et si ce champ est modifiable par l'utilisateur, c'est lui qui choisit ce que dit son propre jeton.
Pourquoi c'est grave
Le jeton est la preuve d'identité de toutes les requêtes suivantes. Un claim d'authentification falsifié peut faire passer une requête pour celle d'un autre utilisateur ou d'une autre collection. Le vecteur est PR:N : NVD considère qu'aucun privilège préalable n'est requis.
Versions
Affectées : versions postérieures à 3.0.0 et antérieures à 3.90.0. Corrigée : 3.90.0. Les bornes NVD mentionnent aussi la branche 4.0.0 ; vérifie l'avis Payload pour la version canary à utiliser si tu es sur cette branche.
Détection
- Version :
npm ls payload @payloadcms/plugin-stripedans chaque projet, et dans les images déjà déployées, pas seulement dans le dépôt. - Configuration : le proxy REST du plugin Stripe est-il activé ? Des champs de la collection utilisateurs sont-ils inclus dans le jeton, et sous quel nom ?
- Journaux Stripe (tableau de bord → Développeurs → Journaux) : appels API inattendus provenant de ta clé serveur, en particulier des opérations d'écriture que ton application n'effectue jamais.
- Journaux applicatifs : requêtes vers les routes du proxy Stripe par des comptes non administrateurs, comptes récents très actifs.
Mitigation
- Mettre à jour Payload et @payloadcms/plugin-stripe en 3.90.0 (ou 4.0.0-canary.34 sur la branche canary), puis redéployer.
- Désactiver le proxy REST Stripe si tu n'en as pas un besoin explicite. Une fonction optionnelle non utilisée est une surface d'attaque gratuite.
- Restreindre la clé Stripe côté serveur : une clé restreinte limitée aux ressources dont l'application a besoin réduit l'impact de toute faille de ce type.
- Revoir les champs inclus dans le jeton : aucun champ modifiable par l'utilisateur ne doit porter un nom de claim réservé.
- En cas de doute sur une exploitation : faire tourner la clé Stripe, faire tourner le secret de signature des jetons Payload (ce qui invalide toutes les sessions), et examiner les opérations Stripe de la période.
Pourquoi surveiller en continu tes dépendances CMS
Un CMS headless est rarement vu comme un « produit » à inventorier : c'est une dépendance npm dans un projet. Pourtant, il tient les comptes, émet les jetons et, ici, détient une clé vers ton compte de paiement.
Avec cveo.tech, déclare les frameworks et CMS de tes applications avec leur version exacte, et reçois une alerte dès qu'une CVE critique les concerne.