CVE-2026-105853: 
JavaScript vulnerability analysis and mitigation

CVE-2026-105853 is an information disclosure vulnerability in Payload CMS, an open-source headless content management system, where token refresh and password reset responses may expose hidden or read-restricted user fields to the requesting user. It affects Payload versions >= 3.0.0 and < 3.90.0, as well as canary versions >= 4.0.0-canary.0 and < 4.0.0-canary.34. The vulnerability was published on September 18, 2026, and assigned a CVSS v4 base score of 7.1 (High) (Github Advisory, Feedly).

The root cause is classified as CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). Prior to the fix, Payload's authentication response handlers for token refresh (/refresh-token) and password reset operations did not apply field-level access control or hidden-field filtering before returning the user document in the response. This meant any authenticated user with low privileges could trigger a token refresh or password reset flow and receive fields in the response that their access control rules should have restricted or hidden. The fix, applied in commit f5f1283, adds collection identity validation during token refresh and ensures authentication responses apply field access and hidden-field filtering before returning user documents (Github Advisory, Payload Commit).

Successful exploitation allows an authenticated attacker with low privileges to retrieve sensitive user fields that are explicitly marked as hidden or read-restricted within an authentication collection, bypassing the intended access control model. The impact is limited to confidentiality — there is no integrity or availability impact — but exposed fields could include sensitive personal data, internal identifiers, or other protected attributes depending on the application's schema. Applications are only affected if their authentication collections contain hidden or read-restricted fields (Github Advisory).

No public proof-of-concept exploit code or evidence of in-the-wild exploitation has been reported as of the time of disclosure. The EPSS score is 0.0, indicating a very low probability of exploitation in the near term, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires a valid authenticated session (low privileges), making it accessible to any registered user of an affected Payload application (Github Advisory, Feedly).

1. Obtain a valid user account: Register or obtain credentials for any low-privileged user account on a Payload CMS instance running a vulnerable version (>= 3.0.0, < 3.90.0 or >= 4.0.0-canary.0, < 4.0.0-canary.34).
2. Authenticate and obtain a JWT token: Log in via the Payload REST API (e.g., POST /api/<collection>/login) to receive a JWT token.
3. Trigger a token refresh request: Send a POST request to the token refresh endpoint (e.g., POST /api/<collection>/refresh-token) with the JWT in the Authorization: JWT <token> header.
4. Inspect the response: Examine the JSON response body for user document fields that should be hidden or read-restricted according to the collection's access control configuration — these fields will be present in the unpatched response.
5. Optionally trigger via password reset: Initiate a password reset flow for the target account and inspect the response for similarly exposed restricted fields.
6. Collect sensitive data: Extract any sensitive field values (e.g., internal IDs, restricted profile data) returned in the response for further use or reconnaissance (Github Advisory, Payload Commit).

• Network: Unusual or repeated POST requests to /<collection>/refresh-token or password reset endpoints from authenticated users, particularly if the same token is refreshed frequently or from unexpected IP addresses.
• Logs: API access logs showing authenticated requests to refresh-token or password reset endpoints from users who do not normally perform these operations, or from accounts that appear to be probing multiple collections.
• Logs: HTTP 403 responses to refresh-token requests targeting a different collection than the one the user authenticated against (indicative of cross-collection refresh attempts, which the patch now blocks).

The vendor has released patched versions 3.90.0 and 4.0.0-canary.34, which apply field access control and hidden-field filtering to authentication responses before returning user documents. There is no complete workaround available — upgrading is the only recommended remediation. After upgrading, users should regenerate Payload types (pnpm payload generate:types) and, if using a relational database, run the required migrations. Note that custom authentication strategies remain responsible for filtering user documents returned through custom responses (Github Advisory, Payload v3.90.0 Release).

The Payload CMS maintainers flagged the v3.90.0 release as containing a set of critical security fixes and urged users to upgrade as soon as possible, intentionally omitting exploit details and attack surface descriptions from the release notes to limit exposure (Payload v3.90.0 Release). No notable independent researcher commentary or significant social media discussion has been identified beyond standard CVE aggregator coverage.