Payload CMS EUVD-2026-93512

The target collection must use Payload's local-authentication strategy with its account lockout mechanism active (maxLoginAttempts / lockTime), which is the default for local-auth collections. The attacker must already know a valid account identifier (email or username) for the specific account to be targeted - the attack cannot lock arbitrary unknown accounts and does not cause a system-wide outage. Limiting factors: impact is confined to denial of sign-in for the identified account(s) until the lock period expires, with no data exposure, no code execution, and no persistence; affected versions are before 3.90.0 (and canary before 4.0.0-canary.34).

This is a genuine but moderate-severity availability issue, not a top-tier priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) correctly shows a network-reachable, low-complexity, unauthenticated attack, but the only impact metric set is VA:L (limited availability) with no confidentiality or integrity impact and no scope/subsequent-system change, which is why the score lands at 6.9 (Medium) rather than High/Critical. The effective impact is a targeted account-level denial of service: an attacker who already knows a valid email/username can deliberately trip the account lockout mechanism to deny that specific user sign-in. No EPSS score, KEV listing, POC, or SSVC decision data was supplied in the input, so there is no evidence of active exploitation or automatable mass exploitation - treat this as low real-world urgency. One signal conflict to note: the Tag 'Information Disclosure' contradicts the actual mechanism and the CVSS vector, which show an availability-only (VA:L) lockout abuse, not disclosure - the tag appears mislabeled.

An attacker who knows a target user's login email or username repeatedly submits invalid credentials to the local-authentication collection's login endpoint until Payload's account lockout threshold (maxLoginAttempts) is reached, locking the legitimate user out until the lock period expires. No authentication or user interaction is required, and the attack can be repeated to keep a high-value account (e.g., an admin) perpetually locked. No public exploit was identified at time of analysis.