Payload CMS CVE-2026-105805

Exploitation requires a specific, concurrent set of conditions in the Payload deployment: (1) a collection whose read/query access is granted to the untrusted attacker, (2) the attacker able to control the sort parameter on that collection's query, and (3) at least one field on that collection protected by field-level read access control that the attacker selects as the sort key. The disclosure is limited - the attacker infers partial information about protected field values from result ordering, not the raw values. Limiting factors that reduce real-world risk: deployments that do not expose collections to untrusted/anonymous users, that restrict or fix the sort parameter, or that do not mix readable collections with field-level-protected fields are not exploitable. The vendor workaround (prevent untrusted users from controlling sort parameters, or restrict access to affected collections) directly removes conditions 1-2.

This is a genuine but modest-severity information-disclosure weakness (CWE-200) that should be treated as a routine, low-urgency patch rather than an emergency. The only quantitative signal provided is the vendor/NVD CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N, score 6.9), which describes a network-reachable, low-complexity attack with no privileges or user interaction but only LOW confidentiality impact and zero integrity/availability impact - the impact is explicitly limited to inferring partial information about protected field values via a sort-order side channel, not reading them directly. No EPSS score, no CISA KEV listing, and no public exploit were supplied, so this is 'no public exploit identified at time of analysis'; there is no evidence of active exploitation and these signals should not be invented. The PR:N rating in the vector is somewhat optimistic for the real world: the GHSA advisory states the attacker must be an 'untrusted user who can query a readable collection,' so exploitability hinges on the deployment exposing a collection to untrusted/anonymous users while simultaneously protecting individual fields on it - a specific access-control configuration, not a universal default. Net: real, confirmed by the vendor advisory and a fix commit, but a side-channel inference bug of limited value, appropriate to patch on a normal cycle rather than as a drop-everything priority.

An application built on Payload exposes a collection that untrusted users may read, but with certain fields (e.g. an internal status, score, or flag) protected by field-level access control. The attacker repeatedly issues list/query requests sorting by the protected field and, by observing how records reorder across queries, infers limited information about those hidden field values they are not permitted to read. No public proof-of-concept was provided, and the attack yields only partial inference rather than direct field disclosure.