Payload CMS CVE-2026-105849

Two concrete conditions must both hold: (1) an authentication collection has the auth option useAPIKey set to true, and (2) users are granted read access to other users' authentication documents in that collection (cross-user read, not self-read-only). The attacker must be an authenticated user with at least ordinary read access (PR:L). Exploitation is limited where deployments restrict users to reading only their own auth document, disable useAPIKey, or override the generated apiKey field's access control - these are the vendor-listed workarounds. Single-tenant or self-read-only configurations are not exploitable, which meaningfully narrows the exposed population despite the network attack vector.

This is a credible, upper-medium priority issue for environments that actually use the vulnerable feature, but not a drop-everything internet-wide emergency. The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) and vendor advisory agree that exploitation is network-reachable and technically trivial, but gated behind two real prerequisites: an attacker must already hold a valid low-privileged account (PR:L) and the target deployment must have enabled useAPIKey on an auth collection AND granted users read access to other users' documents (AT:P - attack requirement present). The VC:H/VI:H/VA:H impact is well justified: a leaked active API key is effectively account takeover of the target identity until the key is rotated. Mitigating the urgency: there is no CISA KEV listing, no public POC referenced, and no EPSS score supplied, so there is no evidence of active or at-scale exploitation - this is a disclosed-and-patched flaw, not a weaponized one. One signal to weigh honestly: EPSS and POC data are simply absent from the input (not low - missing), so exploitation probability cannot be quantified and should be treated as unknown rather than assumed low. The practical risk is therefore concentrated in multi-tenant or team Payload deployments where ordinary users can read each other's auth documents; single-user or self-read-only configurations are not exposed.

In a Payload instance where an auth collection has useAPIKey enabled and ordinary users can read other users' documents, a low-privileged authenticated user issues a normal read request against another (e.g. higher-privileged) user's auth document and receives that account's active API key in the response. The attacker then uses the harvested key to authenticate as the victim and perform any action the victim is authorized for until the key is rotated or disabled. No public exploit is identified at time of analysis, but exploitation requires only standard read API calls and no special tooling.