CVE-2026-105853 in Payload
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In versions from 3.0.0 before 3.90.0 and canary versions before 4.0.0-canary.34, token refresh responses and password reset responses can independently return hidden or read-restricted fields that the requesting user cannot access. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS contains an information disclosure vulnerability affecting version ranges from 3.0.0 up to, but not including, 3.90.0, as well as canary versions prior to 4.0.0-canary.34. This flaw manifests specifically within the token refresh and password reset API endpoints, where the server fails to properly enforce field-level access controls during response serialization. When a user initiates these authentication-related operations, the backend processes the request and generates a JSON response containing various data fields associated with the user account or session state. However, due to an oversight in the filtering logic applied before sending the response back to the client, certain sensitive fields are included even when they should be hidden from the requesting entity based on its current permission level.
The technical root cause of this vulnerability lies in the serialization process used by Payload CMS for API responses. Typically, content management systems implement a mechanism to strip out restricted or private fields before transmitting data over HTTP to ensure that users only receive information they are authorized to view. In this specific case, the logic governing which fields to include in token refresh and password reset payloads does not adequately check the user's role or permissions against the sensitivity of each field. Consequently, if a standard authenticated user triggers a token refresh or requests a password reset, the resulting JSON object may contain internal identifiers, hashed passwords, secret keys, or other metadata that is marked as read-restricted in the schema definition but remains visible in the raw response body because the filtering step was bypassed for these specific endpoints.
The operational impact of this vulnerability allows an attacker with valid credentials to potentially extract sensitive configuration data or user-specific secrets without needing elevated privileges. While token refresh and password reset actions require initial authentication, meaning a low-level account holder can exploit this flaw, it does not constitute a direct privilege escalation vector on its own. However, the exposure of hidden fields could aid in further attacks such as session hijacking if sensitive tokens are leaked, or provide reconnaissance data that helps an attacker map out the internal structure of the CMS and identify other potential weaknesses. For instance, discovering internal database IDs or secret environment variables exposed through these responses can facilitate targeted phishing campaigns or more complex exploitation chains against the hosting infrastructure.
This issue is classified under CWE-209 as Information Exposure Through an Error Message, although it specifically relates to improper access control over sensitive data elements rather than just error messages. It also aligns with ATT&CK technique T1530, Data from Cloud Storage Object Discovery, in the context of exfiltrating internal system information through API responses. The vulnerability has been addressed in Payload CMS version 3.90.0 and canary build 4.0.0-canary.34 by correcting the serialization logic to ensure that field-level permissions are strictly enforced for all outgoing JSON payloads, regardless of the endpoint triggering them.
To mitigate this risk immediately upon upgrading or while planning migration, administrators should verify their Payload CMS version is updated to at least 3.90.0 or a later stable release containing the fix. For organizations unable to upgrade instantly, implementing an API gateway or reverse proxy with strict response filtering can serve as a compensating control by inspecting outgoing JSON responses and stripping out fields known to be sensitive if they are not explicitly required for the specific operation being performed. Additionally, developers should audit custom endpoints within their Payload CMS instances to ensure that any bespoke logic adheres to the same rigorous field-level access control standards applied in the core framework updates. Regular security audits of API response structures are recommended to detect similar oversights where internal data might be inadvertently exposed through other less obvious entry points.