CVE-2026-72700 in Grav
Summary
by MITRE • 08/25/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified in getgrav/grav-plugin-login versions prior to 3.9.1 represents a classic implementation error involving cryptographic timing attacks. The core technical flaw lies within the authentication logic for password reset and account activation workflows, specifically located in classes/Controller.php during the taskReset operation and in login.php during the activation handler sequence. In these code paths, the plugin performs string comparisons of security tokens using the strict equality operator === rather than a constant-time comparison function such as hash_equals(). This distinction is critical because standard string comparison operators typically return false upon encountering the first mismatched character, causing the execution time to vary proportionally with the number of correct characters matched. An attacker leveraging this timing side-channel can systematically deduce valid tokens by measuring response latencies across multiple requests, effectively bypassing the intended security controls through statistical analysis rather than brute force guessing alone.
From an operational perspective, while the vendor has assessed the practical exploitability as low due to the absence of demonstrated end-to-end network exploits and potential mitigating factors such as server-side processing overhead or network jitter, the theoretical risk remains significant for high-value targets. The vulnerability is compounded by a lack of rate limiting on the token-submission endpoint responsible for handling password reset requests. This architectural oversight allows an attacker to send a high volume of repeated guesses against a known username without immediate account lockout or request throttling. By combining the timing oracle provided by the non-constant-time comparison with the ability to make unlimited attempts, an adversary could potentially reconstruct valid activation or reset tokens for targeted user accounts, leading to unauthorized access and potential full system compromise if these credentials are reused elsewhere.
This vulnerability aligns with CWE-208, which describes Observable Timing Discrepancy, a category of flaws where sensitive information is leaked through variations in processing time. Furthermore, the exploitation technique falls under MITRE ATT&CK tactic T1595, specifically subtechnique Active Scanning, as it involves gathering data about target security mechanisms to identify weaknesses. The lack of rate limiting also relates to CWE-307, Improper Restriction of Excessive Authentication Attempts, which fails to adequately limit the number of failed login or token validation attempts within a given timeframe. These combined deficiencies create an environment where automated tools could theoretically be employed to extract valid tokens with sufficient precision to bypass authentication controls.
To mitigate this vulnerability, immediate remediation requires upgrading the getgrav/grav-plugin-login component to version 3.9.1 or later, which addresses the string comparison logic by implementing constant-time algorithms that ensure execution time remains independent of input content. In addition to patching, administrators should implement robust rate limiting mechanisms on all authentication-related endpoints, including password reset and account activation handlers, to prevent high-frequency automated guessing attacks regardless of timing side-channels. It is also advisable to enforce short expiration windows for security tokens and to monitor logs for anomalous patterns in token validation requests that may indicate ongoing exploitation attempts. Regular security audits focusing on cryptographic implementation details are recommended to ensure compliance with secure coding standards such as OWASP Cryptographic Storage Cheat Sheet, which mandates the use of constant-time comparisons for sensitive data verification.