CVE-2026-56710

The Grav Login plugin (grav-plugin-login) versions <= 3.8.11 contain a privilege escalation flaw in the authenticated profile self-update handler (processUserProfile(), the update_user task). Unlike the registration handler, this handler does not strip privilege fields ('groups','access') from user-submitted form data before persisting them. When an administrator has added 'groups' and/or 'access' to plugins.login.user_registration.fields and the default 'regular'/DataUser account backend is in use, a low-privilege authenticated user can POST crafted profile form data (e.g. access[admin][super]=true) to escalate to super-admin, enabling admin panel access, scheduler abuse (RCE), and Twig evaluation. Fixed in 3.8.12.

Grav is a file-based web platform. Prior to 2.0.0-beta.2, the Login::register() method in the Login plugin accepts attacker-controlled groups and access fields from the registration POST data without server-side validation.

The getgrav/grav-plugin-login Composer plugin before 3.9.1 (used by Grav) compares password reset and account activation tokens using a non-constant-time === string comparison instead of hash_equals() in classes/Controller.php (taskReset()) and login.php (activation handler). Because the token-submission endpoint (taskReset) also lacks rate limiting, an attacker could in principle send repeated token guesses against a known username and use the timing differences to attempt to recover a valid token, though the vendor rates the practical exploitability as low and no end-to-end network exploit has been demonstrated.

The Grav Login plugin (getgrav/grav-plugin-login) before 3.9.1 is vulnerable to email address enumeration. The register() method in classes/Login.php throws a distinct exception (EMAIL_NOT_AVAILABLE) when a submitted email address already belongs to an existing account, while allowing registration to proceed otherwise. Because the registration endpoint has no rate limiting, an attacker can enumerate which email addresses have accounts on the site, one guess per request.

The Grav Login plugin prior to 3.8.11 accepts the login.regenerate2FASecret task via a top-level GET request without requiring a nonce, Origin check, or Referer check. Under default SameSite=Lax policy, an off-site navigation can invoke taskRegenerate2FASecret() in a logged-in victim's session, overwrite the TOTP secret, and force two-factor re-enrollment.

The Grav Login plugin before version 3.8.11 contains a vulnerability in the login.regenerate2FASecret task that only checks that the pending-session user exists rather than requiring $user->authorized. After submitting a victim's correct password, an attacker can invoke taskRegenerate2FASecret() during the pending TOTP challenge, overwrite twofa_secret, read the replacement secret from the response, calculate a valid code, and complete authentication without the victim's second factor. This issue is fixed in version 3.8.11.

Grav Login Plugin versions before 3.8.13 contain an insufficient session expiration vulnerability in TokenStorage.php where the findTriplet() method fails to properly validate Remember Me token timestamps. Attackers with a captured Remember Me cookie can authenticate indefinitely instead of the configured timeout period, as the expiry check compares an array to a scalar value which always evaluates incorrectly in PHP.

The Grav Login plugin before version 3.8.11 contains a cross-site request forgery (CSRF) vulnerability in the login.regenerate2FASecret frontend task. An attacker can trick a logged-in user into visiting a malicious page, which regenerates a new TOTP secret without any anti-CSRF nonce or Origin/Referer check, invalidating the existing two-factor authentication key.