Grav Login CVE-2026-56710

Exploitation requires the attacker to already possess an authenticated Grav account holding the api.users.write permission - this is a limiting prerequisite, not a default-open condition, and directly contradicts the PR:N in the supplied CVSS vector. The target must be a higher-privilege account (specifically admin.super) that currently has a lockout counter to clear, and the Login plugin must be a vulnerable version below 1.0.16. Exploitation is limited by the fact that clearing the lockout does not itself compromise the account; it only removes brute-force throttling, so a successful takeover additionally depends on the attacker being able to run a password-guessing campaign and the target password being guessable (MFA or a strong password materially blunts the outcome).

This is best understood as a security-control-removal / privilege-boundary flaw rather than direct code execution or data theft. The vendor scores it CVSS 4.0 9.3 with PR:N, but that conflicts with the description, which plainly requires the attacker to already hold api.users.write - so exploitation is NOT unauthenticated, and the PR:N in the supplied vector should be treated as an error; realistic risk is contingent on an attacker already having a privileged operator role. The direct impact is that lockout protection is removed from super-admin accounts, which only becomes account takeover when combined with a follow-on password-guessing or credential-stuffing campaign, so the raw VC:H/VI:H/VA:H impact rating overstates the immediate effect. There is no KEV listing and no POC referenced, so this is not confirmed active exploitation; treat it as a genuine hardening priority for any multi-operator Grav deployment (an organization that delegates user administration to staff who are not meant to be super admins should patch promptly), but not an emergency drop-everything internet-wide worm risk. If your Grav instance has only a single trusted super-admin operator and no delegated api.users.write roles, real-world exposure is low.

A Grav deployment delegates day-to-day user management to a staff member granted api.users.write but not super-admin rights. That user invokes the unlock action against the site's admin.super account, clearing its lockout counter, then runs an automated password-guessing tool against that account with brute-force protection now disabled. No public POC is referenced at time of analysis.