CVE-2026-80196 in Kimai
Summary
by MITRE • 08/26/2026
Kimai before 2.58.0 contains an authentication bypass vulnerability where password reset links remain valid after password changes because the LoginLink signature covers only the user id, not the password hash. Attackers who intercept or cache a password reset link can use it up to 2 additional times within a 1-hour window to log in as the user even after the legitimate user has changed their password.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/26/2026
The vulnerability identified in Kimai versions prior to 2.58.0 represents a critical flaw in the implementation of stateless authentication tokens, specifically affecting the password reset mechanism. This issue stems from an incomplete signature validation strategy where the cryptographic integrity check for login links relies exclusively on the user identifier rather than incorporating dynamic security attributes such as the current password hash or session-specific entropy. By failing to bind the token's validity to the most recent credential state, the system creates a window of opportunity for attackers to exploit stale authentication data that should have been invalidated upon a legitimate password change event.
From a technical perspective, the core defect lies in how the LoginLink signature is constructed and verified. When a user initiates a password reset, the application generates a token signed with a secret key, but the payload or signing input only includes the unique identifier of the account holder. Consequently, if an attacker intercepts this link through network sniffing, log file exposure, or cross-site scripting attacks that steal URL parameters, they possess a valid cryptographic proof of authorization for that user ID. The system does not verify whether the password associated with that identity has been rotated since the token was generated. This design oversight means the authentication mechanism treats all instances of the link as equally valid regardless of subsequent security actions taken by the account owner or administrator.
The operational impact of this vulnerability is significant, particularly for users who rely on the standard recovery workflow to secure compromised accounts. An attacker with access to a cached password reset URL can execute multiple login attempts within a one-hour window following the legitimate user's successful password change. This allows the adversary to bypass the intended security control and gain unauthorized access to the victim's account using credentials that are no longer active in the database. The ability to use the link up two additional times exacerbates the risk, as it provides redundancy against timing-based mitigations or single-use token expectations often assumed by developers implementing such flows.
This vulnerability aligns with CWE-287 Improper Authentication and CWE-613 Insufficient Session Expiration, as the system fails to properly invalidate authentication artifacts when security context changes occur. In terms of offensive security frameworks, this behavior facilitates Account Takeover (T1078) by allowing attackers to leverage previously intercepted credentials or tokens that were not revoked during a standard remediation process. The lack of binding between the token and the current password hash violates fundamental principles of secure session management where state changes must immediately propagate to all active authentication artifacts associated with that identity.
To mitigate this risk, immediate updates to Kimai version 2.58.0 or later are required as these versions address the signature construction logic by incorporating dynamic elements into the token validation process. In environments where upgrading is not immediately feasible, administrators should enforce strict access controls on log files and network traffic to prevent interception of reset links. Additionally, implementing a mechanism that invalidates all active password reset tokens upon any credential change event would provide an additional layer of defense. Security teams should also review their authentication flows to ensure that stateless tokens are always bound to the most recent security-relevant attributes, such as password hashes or multi-factor authentication status, rather than static identifiers alone.