On October 6, 2026, NVD published two critical CVEs in Payload, the open source TypeScript headless CMS. One affects the official @payloadcms/plugin-stripe, the other the authentication token issued at login. Both are fixed in Payload 3.90.0.
What they share: in each case an optional configuration setting opens a path the application never intended. If you run Payload, the question isn't just "which version?" but also "which options did I turn on?".
| CVE | Component | CVSS 3.1 | Vector | NVD published | 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 | no (as of writing) |
| CVE-2026-105863 | Payload (authentication) | 9.4 (CRITICAL) | AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:L | 2026-10-06 | no (as of writing) |
CVE-2026-105848 — the Stripe plugin's REST proxy
What the flaw does
Payload's Stripe plugin offers an optional REST proxy to the Stripe API. NVD sums it up:
an authenticated user who can reach the enabled optional Stripe REST proxy can perform unintended Stripe operations.
An authenticated user, even a low-privileged one (PR:L), who can reach that proxy can trigger Stripe operations that weren't meant for them. The proxy talks to Stripe with the server's secret key: what the user gets is that key's permissions, not their own.
Why it matters
The S:C (scope change) says it all: the impact goes beyond Payload and lands on your Stripe account. Depending on the key's permissions, that can mean reading customer and payment data, or operations that change account state. NVD doesn't list which ones, and I won't list them for it.
Conditions
- The Stripe plugin is installed and the optional REST proxy is enabled.
- The attacker has an authenticated account on the instance. With open public sign-up, that's trivial.
Versions
Affected: @payloadcms/plugin-stripe versions before 3.90.0, and canary versions before 4.0.0-canary.34. Fixed: 3.90.0 and 4.0.0-canary.34, per the NVD description.
CVE-2026-105863 — a field mapped to a reserved auth claim
What the flaw does
Payload lets you include some fields from the users collection in the token issued at login. NVD describes the bug:
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.
If a field is configured to be copied under a claim name Payload itself relies on for authentication, its value can end up in the token instead of the legitimate one. And if users can edit that field, they decide what their own token says.
Why it matters
The token is the proof of identity for every subsequent request. A spoofed authentication claim can make a request look like it comes from another user or another collection. The vector is PR:N: NVD treats it as requiring no prior privileges.
Versions
Affected: versions after 3.0.0 and before 3.90.0. Fixed: 3.90.0. NVD's bounds also mention the 4.0.0 branch; check Payload's advisory for the canary release to use if you're on it.
Detection
- Version:
npm ls payload @payloadcms/plugin-stripein every project, and in already-deployed images, not just the repository. - Configuration: is the Stripe plugin's REST proxy enabled? Are users-collection fields included in the token, and under which names?
- Stripe logs (Dashboard → Developers → Logs): unexpected API calls from your server key, especially write operations your application never performs.
- Application logs: requests to the Stripe proxy routes from non-admin accounts, very active recent accounts.
Mitigation
- Upgrade Payload and @payloadcms/plugin-stripe to 3.90.0 (or 4.0.0-canary.34 on the canary branch), then redeploy.
- Disable the Stripe REST proxy unless you explicitly need it. An unused optional feature is free attack surface.
- Restrict the server-side Stripe key: a restricted key scoped to the resources the app actually needs limits the impact of any flaw like this one.
- Review fields included in the token: no user-editable field should carry a reserved claim name.
- If you suspect exploitation: rotate the Stripe key, rotate Payload's token signing secret (which invalidates every session), and review Stripe operations over the period.
Why Continuous Monitoring of Your CMS Dependencies Matters
A headless CMS is rarely seen as a "product" to inventory: it's an npm dependency in a project. Yet it holds the accounts, issues the tokens and, here, holds a key to your payment account.
With cveo.tech, register your applications' frameworks and CMSs with exact versions, and get alerted whenever a critical CVE affects them.