CVE-2026-105853: Sensitive Information Disclosure and Authentication Collection Boundary Bypass in Payload CMS

Payload CMS is an open-source headless content management system built on Node.js. It features authentication-enabled collections, allowing developers to manage different classes of users (such as public users and administrators) with fine-grained access control policies. Each collection has its own schema where developers can define security attributes, including fields hidden from API responses (hidden: true) or fields restricted by custom read-access controls.

In affected versions, the endpoints responsible for processing token refresh and password reset operations contain integration flaws. They bypass the standard field-level serialization and sanitization pipelines. This omission exposes the raw user document directly to the client, undermining the security guarantees defined in the application schema.

Furthermore, the system fails to validate authorization boundaries between separate authentication collections during token refresh operations. This allows an authenticated user from a low-privilege collection to query the refresh endpoint of a high-privilege collection. The vulnerability represents a serious risk of internal privilege escalation and data harvesting in multi-tenant or multi-collection installations.

The underlying security issue is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). It stems from two distinct logical errors in the authentication controllers.

First, standard Payload CMS operations run user documents through a sanitization pipeline before returning them to the client. This pipeline checks permissions and strips any fields flagged as hidden or fields that the requester does not have read-access to. However, the token refresh and password reset controllers directly retrieved user objects from the database and serialized them straight into the JSON response. This omission allowed any requester capable of triggering these endpoints to inspect internal system fields, custom roles, password reset tokens, and API keys.

Second, the token refresh operation did not enforce boundaries between different authenticated collections. When an authenticated client invokes the refresh endpoint, the application decodes the JSON Web Token (JWT) and validates the session. However, the system failed to verify whether the collection associated with the active token (req.user.collection) matched the target collection route being called (collectionConfig.slug). Consequently, a low-privilege user could submit their token to a high-privilege refresh route, bypassing namespace isolation and forcing the server to return the non-sanitized user document.

The fix for the collection-boundary validation bypass was introduced in commit f5f1283d275c58b30e2faa6be7cdc4d49451ea91 inside the file packages/payload/src/auth/operations/refresh.ts.

Prior to the patch, the refreshOperation handler validated the presence of the authenticated user in the request context but did not verify the collection source:

// Before Patch
if (!args.req.user) {
  throw new Forbidden(args.req.t)
}

The patch introduced strict checking of the user's collection against the collection configuration of the active route:

// After Patch
import { status as httpStatus } from 'http-status'
import { APIError, Forbidden } from '../../errors/index.js'
 
// ... within refreshOperation ...
if (!args.req.user) {
  throw new Forbidden(args.req.t)
}
if (args.req.user.collection !== collectionConfig.slug) {
  throw new APIError('Incorrect collection', httpStatus.FORBIDDEN)
}

This addition ensures that if the authenticated user's collection identifier does not match the target collection slug, an explicit 403 Forbidden APIError is raised immediately. To mitigate the broader field-leakage issue, additional sanitization wrappers were added to the endpoint outputs, ensuring that all returned objects are filtered using the standard schema access-control rules.

An attacker can exploit this vulnerability through two separate vectors, depending on their level of access. In the first vector, the attacker exploits the cross-collection boundary to obtain hidden metadata. The workflow is demonstrated in the sequence diagram below:

In the second vector, an attacker triggers the password reset flow using the /api/users/forgot-password and /api/users/reset-password endpoints. When the reset is completed, the server returns the updated user document to the client. Because the handler lacks serialization, the response includes fields that are explicitly designated as hidden, such as internal access levels or secret keys.

The impact of this vulnerability is significant for multi-tenant and multi-role configurations. The disclosure of hidden fields allows attackers to read internal access control attributes, backend flags, and reference IDs that are crucial for application logic.

While the vulnerability does not directly allow remote code execution or unauthorized database modification, the leaked metadata often contains the information necessary to construct subsequent high-impact attacks. For example, exposing internal user roles or secret configuration variables can allow an attacker to identify flaws in custom access control hooks.

According to the CVSS v4.0 calculator, the base score is 7.1 (High) with the vector string CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N. This calculation indicates that the network-accessible, low-complexity exploit has high confidentiality impact on the target system.

The primary recommendation is to update the application dependencies to a secure version. The vendor has released patches that address both the collection validation logical flaw and the field-level leakage.

Users operating on the 3.x release branch must upgrade the core payload package to version 3.90.0 or higher. Users on the 4.x development or canary branches must upgrade to version 4.0.0-canary.34 or higher.

Additionally, developers utilizing custom authentication strategies must review their implementations. The vendor advisory notes that custom authentication strategies remain responsible for filtering user documents returned through custom responses. Developers must ensure that all custom login, token-refresh, or identity-validation endpoints manually run user records through the standard Payload sanitization utilities prior to transmitting payload structures.