CVE-2026-52809: Gogs Password-Reset Token Lifetime Bypass (v0.14.3 Fix)

Technical summary

The vulnerability stems from incorrect token-generation logic in Gogs password-reset workflows. Reset tokens are generated using conf.Auth.ActivateCodeLives (typically days) rather than conf.Auth.ResetPasswordCodeLives (administrator-configured, often minutes). Because the expiration lifetime is embedded in the token itself at generation time and extracted again at verification time, the configured ResetPasswordCodeLives setting is never enforced. An attacker who intercepts or obtains a password-reset token can use it well beyond the administrator-configured reset window, exploiting the gap between the advertised expiry in the reset email and the actual token validity period determined by the longer activation code lifetime. This affects CWE-324 (Unvalidated Timestamp in Token) and CWE-613 (Insufficient Logging).

Business impact

Organizations using Gogs for self-hosted Git repositories face elevated account-compromise risk, particularly if they have tightened password-reset token lifetimes as part of security policy. An attacker who gains access to a password-reset email (via interception, phishing, or account compromise) has a significantly wider window to reset a target user's password than the organization believes it has configured. This can lead to unauthorized repository access, code theft, malicious commits, or lateral movement within development environments. The false sense of security from a configured short token lifetime may delay incident detection and response.

Affected systems

Gogs versions prior to 0.14.3 are affected. Both self-hosted deployments and any instances where administrators have configured custom password-reset code lifetimes are vulnerable. The issue is most critical in environments where compliance or security policies mandate short reset windows (e.g., 10–30 minutes), as the actual token lifetime will be silently extended to the activation code lifetime without administrator awareness.

Exploitability

Exploitation requires the attacker to obtain a password-reset token, typically through email interception, phishing, or social engineering. The CVSS vector (AV:N/AC:H/PR:N/UI:R) reflects that the vulnerability is remotely exploitable but requires some user interaction (UI:R—the user must initiate a password reset). The high impact on confidentiality and integrity (C:H/I:H) reflects that account compromise grants access to repositories and potentially the Git service itself. The 'H' in Access Complexity reflects that successful exploitation depends on obtaining the reset token, which is non-trivial but achievable in realistic attack scenarios.

Remediation

Upgrade Gogs to version 0.14.3 or later, which correctly uses conf.Auth.ResetPasswordCodeLives for token generation and validation. After patching, password-reset tokens will respect the administrator-configured lifetime. Organizations should also audit password-reset logs for any suspicious or extended-window token usage during the vulnerability window, and consider requiring affected users to change passwords following the patch.

Patch guidance

Apply the upgrade to Gogs 0.14.3 or later. Verify the patch by confirming the version number post-upgrade and testing password-reset functionality in a non-production environment to ensure token expiry aligns with configured RESET_PASSWORD_CODE_LIVES settings. After patching, monitor password-reset events for any anomalies. If you have strict change-control requirements, consider staging the upgrade in a development instance first to validate integration with your Git workflows and any custom authentication extensions.

Detection guidance

Monitor Gogs audit logs for password-reset token generation and validation events. Look for tokens that are used well beyond the configured RESET_PASSWORD_CODE_LIVES window (e.g., if configured for 10 minutes, tokens used after 15+ minutes suggest the vulnerability is active). Review email logs or any external monitoring for reset emails that were sent but not acted upon immediately, followed by account access shortly thereafter. Correlate password-reset events with subsequent unauthorized commits, branch modifications, or repository clones. After patching, the gap between stated and actual token lifetime should close, normalizing reset behavior.

Why prioritize this

Although the CVSS score is moderate (6.8), the vulnerability directly undermines a security control—the administrator-configured password-reset window—creating a false sense of security. In development or code-repository environments, account compromise can lead to code theft, supply-chain attacks, or malicious commits. Organizations with strict token-lifetime policies or compliance requirements (SOC 2, ISO 27001) should prioritize this patch to ensure their controls are actually enforced. The deception aspect (reset emails advertising a false expiry) elevates the practical risk.

Risk score, explained

CVSS 6.8 (MEDIUM) reflects remote exploitability with user interaction required to initiate a password reset, combined with high impact on confidentiality and integrity should the token be obtained. Access complexity is elevated because an attacker must intercept or socially engineer a password-reset token rather than directly attacking the service. The lack of availability impact (A:N) reflects that the vulnerability does not cause denial of service. However, the practical risk is elevated by the administrator-deception component: security teams may not be aware the vulnerability exists because the system appears to be working as configured.

Frequently asked questions