CVE-2026-105848: Insufficient Access Control in Payload CMS Stripe REST Proxy

The @payloadcms/plugin-stripe npm package provides integration capabilities between Payload CMS and the Stripe payment platform. When developers enable the optional REST API proxy via the plugin configuration, an endpoint is automatically exposed at /api/stripe/rest to handle incoming payment management queries from frontend components.

A critical design flaw exists in @payloadcms/plugin-stripe versions prior to 3.90.0 and 4.0.0-canary.34 where the REST proxy endpoint does not implement sufficient access control. Any authenticated user, regardless of their role or administrative privileges, can reach this endpoint and interact directly with the Stripe SDK. Because the backend server acts as a proxy, all requests are executed under the authority of the server's master Stripe API Secret Key.

This exposure allows standard authenticated users to execute highly privileged administrative operations directly on the connected Stripe account, bypassing the CMS admin interface. The vulnerability has been assigned CVE-2026-105848 and carries a CVSS v4.0 score of 6.4, indicating moderate-to-high severity. Organizations utilizing this plugin in multi-user environments with the proxy enabled face significant operational risk.

The underlying security issues can be classified under CWE-749 (Exposed Dangerous Method or Function) and CWE-862 (Missing Authorization). When configuring the Stripe plugin with the legacy property rest: true, the application automatically registers a POST route handler named stripeREST in the file packages/plugin-stripe/src/routes/rest.ts. This handler processes incoming client-side payloads and forwards them directly to the Stripe service.

The primary authorization check in vulnerable versions only verifies the existence of a standard user session object in the incoming request. If the user is authenticated in any capacity, the application proceeds to parse the request body. No further role-based access control (RBAC) or attribute-based access control (ABAC) checks are performed to ensure the caller has administrative rights.

Furthermore, the route handler extracts the parameters stripeMethod and stripeArgs directly from the user-controlled POST request body without sanitization. These parameters are passed directly to the stripeProxy() utility function, which invokes the corresponding method on the master Stripe SDK instance. Because the application does not validate the requested method against an allowlist, any valid Stripe SDK method can be invoked dynamically.

To understand the precise vulnerability mechanics, we must examine the difference between the legacy route handler and the patched version implemented in commit 2f94a4205e5ba3ec0e91c92ed54f24f429826dd0. In the vulnerable implementation, the endpoint immediately processed dynamic parameters once basic authentication was confirmed.

The patched implementation addresses both authentication and authorization by introducing a strict allowlist and a custom access callback. The route handler now checks if pluginConfig.rest is configured as a configuration object rather than a boolean value. If it is disabled or is not configured with exact properties, the handler rejects the query immediately with an error.

Below is the refactored code structure implemented in packages/plugin-stripe/src/routes/rest.ts that enforces authorization boundaries and method limits:

// Checking authorization using custom callback or defaulting to admin access
let hasAccess: boolean
if (pluginConfig.rest.access) {
  try {
    hasAccess = await pluginConfig.rest.access({ req })
  } catch (err) {
    return unexpectedErrorResponse({ err, req })
  }
} else {
  try {
    hasAccess = await hasAdminAccess({ req })
  } catch (err) {
    return unexpectedErrorResponse({ err, req })
  }
}
 
if (!hasAccess) {
  return errorResponse({ message: 'Forbidden', status: 403 })
}
 
const { stripeArgs, stripeMethod } = req.data ?? {}
 
// Enforcing strict allowlist validation
if (!pluginConfig.rest.allowedMethods.includes(stripeMethod)) {
  return errorResponse({ message: 'Invalid request', status: 400 })
}

Additionally, the configuration sanitizer in sanitizeStripeRESTConfig.ts prevents wildcard definitions or loose inputs during initialization. If a developer attempts to use rest: true, the configuration sanitizer throws a migration error. It mandates a non-empty allowedMethods array containing exact, literal method names, and rejects any configuration that attempts to use the wildcard character.

Exploitation of CVE-2026-105848 requires standard, low-privilege authentication on the target Payload CMS instance. The attacker must possess credentials or an active JWT session token associated with a basic CMS account. This requirement represents a low barrier to entry, particularly in applications that allow public registration or host standard user-facing features.

The attacker interacts with the target system by sending a crafted HTTP POST request to the /api/stripe/rest endpoint. The request includes the standard authentication headers and a JSON payload specifying the target Stripe method. To perform unauthorized operations, the attacker populates stripeMethod with highly privileged actions, such as refunds.create or subscriptions.del.

An example of an HTTP request designed to issue an unauthorized refund is shown below:

POST /api/stripe/rest HTTP/1.1
Host: target-payload-cms.com
Content-Type: application/json
Authorization: JWT <standard_user_session_token>
 
{
  "stripeMethod": "refunds.create",
  "stripeArgs": [
    {
      "charge": "ch_3MvY2lKxyz..."
    }
  ]
}

The exploitation flow is represented in the diagram below:

Upon receiving this payload, the backend application verifies that the user session is active. It then bypasses any further validation and forwards the arguments to the Stripe SDK. The SDK uses the server's legitimate master credentials to authenticate with Stripe's cloud API, which successfully processes the refund and returns the structured transaction response to the attacker.

The impact of this vulnerability is substantial and directly threatens the financial and operational integrity of organizations using the affected plugin. Because the Stripe REST proxy runs with the server's master API Secret Key, any successful exploitation grants the attacker equivalent administrative power over the connected Stripe account. This level of exposure bypasses all administrative dashboards and payment verification controls.

Attackers can exploit this access to execute disruptive actions, such as issuing massive unauthorized refunds to deplete store balances. They can also delete active customer subscription models, modify billing tiers, or retrieve sensitive customer lists and transactional history. This potential for unauthorized data exfiltration raises severe compliance and privacy concerns under regulations like GDPR and PCI-DSS.

While the vulnerability itself does not lead directly to remote code execution on the local host, the downstream impact on backend business systems is severe. This is reflected in the CVSS v4.0 metrics where subsequent confidentiality and integrity impacts are rated as High (SC:H/SI:H). The attack complexity is low, and no user interaction is required from the victims, making automated exploitation highly feasible once an attacker gains basic access.

Remediation of CVE-2026-105848 requires updating the @payloadcms/plugin-stripe dependency to a secure version. For the 3.x release line, organizations must upgrade to version 3.90.0 or higher. For deployments using the 4.x canary branch, the package must be upgraded to version 4.0.0-canary.34 or higher. These updates remove support for the vulnerable boolean configuration.

After upgrading the library, administrators must refactor their configuration files to replace any instance of rest: true. The secure configuration model requires defining an object that specifies exactly which Stripe methods are permitted. This is accomplished by populating the allowedMethods array and implementing an access callback to restrict execution to administrative roles.

A secure configuration structure is illustrated in the following TypeScript example:

stripePlugin({
  stripeSecretKey: process.env.STRIPE_SECRET_KEY,
  rest: {
    allowedMethods: ['subscriptions.list', 'customers.retrieve'],
    access: async ({ req }) => {
      // Ensure the user has the 'admin' role
      return Boolean(req.user && req.user.roles?.includes('admin'));
    }
  }
})

In environments where immediate patching is not possible, organizations must disable the REST proxy entirely. This is done by setting rest: false or removing the rest property from the plugin configuration, which defaults to undefined (disabled). Furthermore, security teams should audit their Stripe API logs for unusual endpoint invocations originating from backend servers to detect potential prior exploitation.