Payload Stripe Plugin EUVD-2026-93490

Exploitation requires ALL of: (1) the application depends on @payloadcms/plugin-stripe at a vulnerable version (< 3.90.0, or 4.0.0-canary.0 through < 4.0.0-canary.34); (2) the Stripe REST proxy endpoint /api/stripe/rest is active - notably the vulnerable rest config option defaulted to true, so the endpoint was exposed by default unless explicitly disabled; and (3) the attacker possesses an authenticated Payload user account whose session can reach the proxy. The vendor advisory explicitly states an authenticated user is required, which limits exploitation to actors with valid accounts; impact is further bounded to operations exposed by the Stripe REST API rather than the host system. Deployments that do not enable the proxy are not affected, and the fix constrains callers to an explicit allowlist of exact Stripe method names with a configurable access callback.

This is a GitHub-advisory-sourced flaw (GHSA-r9v2-gg2j-22q5, CWE-749 Exposed Dangerous Method) in the @payloadcms/plugin-stripe package where the optional Stripe REST proxy performs insufficient access control, letting an authenticated user invoke arbitrary Stripe REST API methods. No CVSS score or vector is provided (N/A), no EPSS probability is available, the CVE is not in CISA KEV, and no public POC is referenced - so all quantitative exploitation signals are absent and cannot be compared. SSVC-style reasoning must therefore rely on the vendor advisory alone: exploitation status is 'none observed', the technical impact is partial-to-total over the connected Stripe account rather than the host, and automatability is limited because an attacker first needs a valid authenticated account that can reach the proxy. A notable aggravating factor visible in the patch diff is that the vulnerable rest option defaulted to true (the code carried a 'TODO: in the next major version, default this to false'), so the dangerous endpoint was exposed by default wherever the plugin was installed, not only where an operator deliberately enabled it. On balance this is a real but conditional access-control issue - meaningful for the subset of Payload deployments that install this plugin and expose authenticated users to it, but not a broad internet-wide emergency given the authentication requirement, the niche product footprint, and the lack of any exploitation or POC evidence.

An attacker who holds (or registers) a low-privilege authenticated account on a Payload application that ships the Stripe plugin with the REST proxy enabled sends a POST to /api/stripe/rest specifying an arbitrary Stripe method such as subscriptions.list or a mutating call. Because the proxy did not restrict callers to an allowlist of specific Stripe methods, the request is forwarded to Stripe using the server's secret key, letting the user read or manipulate Stripe data beyond their intended permissions. No public exploit code is referenced, but the attack requires only a standard HTTP request and a valid session.