Grav Login Plugin EUVD-2026-62540

The attacker must possess the target account's valid password - this is the dominant prerequisite and the primary limiting factor. Two-factor authentication (TOTP) must be enabled for the targeted Grav account; accounts without 2FA are unaffected by this specific bypass. The attack must be executed during the pending session window between successful password submission and session timeout, imposing a timing constraint. Prior to the patch, no CSRF nonce was required, so the regenerate task could be invoked with a simple POST carrying only the session cookie - no user interaction by the victim was needed. Exploitation is not limited by server-side configuration beyond 2FA being enabled. The CVSS PR:N rating is accurate because the attacker creates their own pending session using the victim's credentials rather than hijacking an existing authorized session.

The CVSS 7.4 score (AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N) accurately reflects the attack profile: fully remote and requiring no interaction, but constrained by AC:H because the attacker must independently possess the victim's password. EPSS data and KEV status are absent from the provided intelligence, so exploitation probability cannot be quantified and no confirmed mass exploitation is known. The impact is severe for affected deployments: this is a complete 2FA bypass yielding account takeover equivalent to full credential compromise, negating the entire second-factor control. The primary real-world risk moderator is the password prerequisite - this is a defense-layer collapse attack, not a credential-free attack. Organizations relying on Grav's 2FA as their primary defense against credential stuffing or phishing should treat this as urgent, since that control is entirely negated. The discovery of the secondary CSRF vector in the same patch suggests the endpoint was historically poorly hardened.

An attacker who has obtained a target's Grav password via phishing or credential stuffing submits that password to initiate a login session, landing in the pending TOTP challenge state. Before entering any TOTP code, the attacker sends a crafted POST to the login controller invoking task=regenerate2FASecret, which overwrites the victim's stored TOTP secret and returns the new secret in the HTTP response. The attacker computes a valid TOTP code from the returned secret and immediately completes login, gaining full account access while the victim's authenticator app becomes permanently invalid.