CVE-2026-52809 in Gogs
Summary
by MITRE • 06/25/2026
Gogs is an open source self-hosted Git service. Prior to 0.14.3, password-reset tokens are generated using conf.Auth.ActivateCodeLives (the account-activation lifetime), not conf.Auth.ResetPasswordCodeLives. The token lifetime is baked into the token itself at generation time and is re-extracted from the token at verification time, making RESET_PASSWORD_CODE_LIVES irrelevant to actual enforcement. When an administrator configures a shorter reset window (e.g., 10 minutes) for compliance or security reasons, reset tokens remain exploitable for the full activation lifetime instead, while the reset email falsely advertises the shorter expiry. This vulnerability is fixed in 0.14.3.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 06/25/2026
This vulnerability affects Gogs version 0.14.2 and earlier, where the password reset functionality suffers from a critical configuration mismatch that undermines security controls. The flaw stems from improper token generation logic where password reset tokens utilize the account activation lifetime parameter instead of the dedicated reset password code lifetime parameter. This misconfiguration creates a fundamental disconnect between administrative security policies and actual system behavior, as administrators can configure shorter reset windows for compliance or security reasons yet the system continues to honor the longer activation window for password reset operations.
The technical implementation of this vulnerability involves token generation and verification mechanisms that bake the expiration time directly into the token itself during creation. When tokens are validated, the system extracts the expiration timestamp from within the token rather than consulting the current configuration settings. This architectural design choice means that even if administrators adjust the ResetPasswordCodeLives parameter to enforce shorter validity periods, the existing tokens continue to function according to their originally baked-in expiration times. The mismatch between advertised security policies and actual operational behavior creates a significant window of opportunity for attackers to exploit reset tokens beyond the intended timeframe.
The operational impact of this vulnerability is substantial as it effectively neutralizes any security benefits that administrators might expect from configuring shorter password reset windows. Attackers who intercept reset emails can continue to use valid tokens for the full activation lifetime period rather than the configured reset duration, potentially extending their attack window by hours or days depending on the system configuration. This vulnerability directly violates security principles related to least privilege and time-based access controls, as it allows unauthorized exploitation beyond the intended temporal boundaries. The false advertising of shorter expiry times in reset emails creates confusion for users and system administrators who may believe they have implemented proper security controls.
This vulnerability aligns with CWE-284 Access Control Issues and specifically relates to improper enforcement of access control policies through incorrect parameter usage. From an ATT&CK framework perspective, this represents a privilege escalation vector through credential access techniques that leverage insecure configuration management. The flaw also demonstrates poor input validation and parameter handling practices that could be classified under CWE-20 Improper Input Validation, as the system fails to properly validate or enforce the intended security parameters during token lifecycle management. Organizations implementing Gogs for version control and collaboration services face increased risk of unauthorized account access and potential data breaches when this vulnerability remains unpatched.
The mitigation strategy involves updating to Gogs version 0.14.3 or later, where the fix correctly implements separate lifetime parameters for activation and password reset operations. Administrators should also review their current token configurations and verify that security policies are properly enforced through updated system behavior. Regular security audits of authentication mechanisms should be conducted to identify similar parameter misconfigurations, and continuous monitoring of access logs can help detect suspicious activities related to account recovery operations. Additionally, organizations should implement defense-in-depth strategies including multi-factor authentication and rate limiting for reset requests to further reduce the attack surface associated with credential recovery processes.