Grav Login Plugin CVE-2026-109312

Exploitation requires three concrete conditions drawn from the advisory: (1) the attacker must already know the victim's account password and have an in-progress front-end login that has reached but not completed the 2FA step; (2) front-end two-factor authentication must be enabled on the target account (twofa_enabled true) - this is the control being bypassed; and (3) the attacker must be able to publish a Grav page form that has no access rule and that reaches the update_user task handled by processUserProfile(). Limiting factors that reduce real-world risk: the dependence on prior credential compromise (PR:L, not PR:N), the non-default requirement of a publishable form without an access rule, and relevance only to sites actually using the Login plugin's front-end 2FA. No user interaction by the victim is required (UI:N).

Signals are moderately consistent and point to a genuine but conditional threat rather than an internet-wide emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) describes a network-reachable, low-complexity attack requiring low privileges, with high confidentiality and integrity impact and no scope change (SC/SI/SA:N) - consistent with an account-takeover flaw confined to the Grav Login plugin. PR:L is the key moderator: the attacker is not fully unauthenticated but rather already possesses the victim's password and an in-progress, not-yet-2FA-authorized front-end session, so this is best understood as a 2FA-defeat primitive that presupposes prior credential compromise, not a standalone remote break-in. No EPSS score, SSVC decision, KEV listing, or POC was provided in the input; there is no public exploit identified at time of analysis, and the absence of KEV means there is no evidence of active exploitation. The practical bar is raised further by a non-default precondition - the attacker must be able to publish a page form without an access rule that reaches the update_user task. Net: a legitimately high-severity authentication-bypass worth prioritizing for any Grav site that relies on front-end two-factor authentication as a compensating control, but the required victim-password + publishable-form preconditions make opportunistic mass exploitation unlikely absent corroborating EPSS/POC data, which is missing here.

An attacker who has already phished or otherwise obtained a victim's Grav password logs in, triggering the pending front-end 2FA challenge but deliberately not completing it. Instead of submitting the one-time code, they use a published page form (lacking an access rule) to invoke the update_user action, which processUserProfile() accepts because it only verifies the session user exists - not that 2FA was satisfied - letting them set twofa_enabled to false and fully take over the account. No public exploit was identified at time of analysis, so the chain would need to be built from the advisory details.