PT-2026-51627 · Go · Gogs.Io/Gogs

Publicado

2026-06-23

Atualizado

2026-06-23

CVE-2026-52809

CVSS v3.1

6.8

Média

Vetor

AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Summary

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.

Severity

Medium (CVSS 3.1: 6.8)

CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N

Attack Vector: Network — the reset endpoint is reachable over HTTP/S.
Attack Complexity: High — successful exploitation requires (1) the instance to be configured with RESET PASSWORD CODE LIVES < ACTIVATE CODE LIVES, AND (2) the attacker to have intercepted the victim's reset token (e.g., from a compromised or shared email inbox).
Privileges Required: None — no Gogs account is required.
User Interaction: Required — the victim must have triggered a password-reset request.
Scope: Unchanged — the impact is confined to the victim's Gogs account.
Confidentiality Impact: High — successful exploitation leads to account takeover, exposing all private repositories and data.
Integrity Impact: High — the attacker can change the victim's password and gain full write access.
Availability Impact: None.

Affected component

internal/userx/userx.go — GenerateActivateCode() (line 39)
internal/email/email.go — SendResetPasswordMail() (line 132)
internal/route/user/auth.go — verifyUserActiveCode() (lines 426–439) and ResetPasswdPost() (line 621)

CWE

CWE-324: Use of a Key Past Its Expiration Date
CWE-613: Insufficient Session Expiration

Description

The reset token lifetime is hardcoded to `ActivateCodeLives` at generation

GenerateActivateCode (called for both account activation and password reset) bakes conf.Auth.ActivateCodeLives — not ResetPasswordCodeLives — into the token as a 6-digit field:

// internal/userx/userx.go:36-46
func GenerateActivateCode(userID int64, email, name, password, rands string) string {
  code := tool.CreateTimeLimitCode(
    fmt.Sprintf("%d%s%s%s%s", userID, email, strings.ToLower(name), password, rands),
    conf.Auth.ActivateCodeLives,  // ← always ActivateCodeLives, never ResetPasswordCodeLives
    nil,
  )
  code += hex.EncodeToString([]byte(strings.ToLower(name)))
  return code
}

CreateTimeLimitCode embeds the minutes value at positions 12–17 of the token:

Token format: YYYYMMDDHHMM (12) | 000180 (6-digit lives) | SHA1 (40) | hex-username

SendResetPasswordMail calls u.GenerateEmailActivateCode(u.Email()) — which resolves to GenerateActivateCode — with no option to pass a different lifetime:

// internal/email/email.go:131-132
func SendResetPasswordMail(c *macaron.Context, u User) error {
  return SendUserMail(c, u, tmplAuthResetPassword, u.GenerateEmailActivateCode(u.Email()), ...)
}

`ResetPasswordCodeLives` is used only for display, not enforcement

VerifyTimeLimitCode discards the minutes argument and re-extracts the lifetime directly from the token itself:

// internal/tool/tool.go:62-86
func VerifyTimeLimitCode(data string, minutes int, code string) bool {
  start := code[:12]
  lives := code[12:18]
  if d, err := strconv.Atoi(lives); err == nil {
    minutes = d  // ← argument overridden by value baked into the token
  }
  retCode := CreateTimeLimitCode(data, minutes, start)
  if retCode == code && minutes > 0 {
    before,  := time.ParseInLocation("200601021504", start, time.Local)
    if before.Add(time.Minute * time.Duration(minutes)).Unix() > now.Unix() {
      return true
    }
  }
  return false
}

The verifyUserActiveCode caller passes conf.Auth.ActivateCodeLives as minutes, but it makes no difference:

// internal/route/user/auth.go:426-439
func verifyUserActiveCode(code string) (user *database.User) {
  minutes := conf.Auth.ActivateCodeLives  // passed to VerifyTimeLimitCode but immediately overridden
  if user = parseUserFromCode(code); user != nil {
    prefix := code[:tool.TimeLimitCodeLength]
    data := strconv.FormatInt(user.ID, 10) + user.Email + user.LowerName + user.Password + user.Rands
    if tool.VerifyTimeLimitCode(data, minutes, prefix) {
      return user
    }
  }
  return nil
}

ResetPasswdPost validates the reset token through verifyUserActiveCode, so it inherits the same flaw:

// internal/route/user/auth.go:621
if u := verifyUserActiveCode(code); u != nil {

ResetPasswordCodeLives appears only in email template data and in the admin config display — it has zero effect on actual token validation:

// internal/email/email.go:109 — template data only, not used to generate the token
"ResetPwdCodeLives": conf.Auth.ResetPasswordCodeLives / 60,

Full execution chain

Victim requests reset: POST /user/forget password → SendResetPasswordMail generates a token embedding ActivateCodeLives = 180 at bytes 12–17.
Email delivered: The reset email says "link valid for 10 minutes" (from ResetPwdCodeLives in the template) but the embedded lifetime is 180.
RESET PASSWORD CODE LIVES window closes: After 10 minutes the victim believes the link has expired.
Attacker submits the token: POST /user/reset password?code=<TOKEN> → ResetPasswdPost → verifyUserActiveCode → VerifyTimeLimitCode extracts 000180 from the token → confirms the token has not yet reached the 180-minute mark → returns the user object → password is updated.
Account takeover: Attacker sets a new password and authenticates as the victim.

Proof of Concept

ini

# app.ini configuration that exposes the bug:
[auth]
ACTIVATE CODE LIVES = 180
RESET PASSWORD CODE LIVES = 10

bash

# 1) Request password reset for victim account
curl -i -X POST -d 'email=victim@example.com' http://HOST/user/forget password

# 2) Obtain the reset link from the email.
#  Wait 11 minutes (past RESET PASSWORD CODE LIVES, within ACTIVATE CODE LIVES).

# 3) Submit the "expired" reset code — it still succeeds
curl -i -X POST 
 -d 'code=<CODE FROM EMAIL>&password=AttackerNewPass' 
 'http://HOST/user/reset password?code=<CODE FROM EMAIL>'

# Expected: HTTP 302 redirect to /user/login — password successfully changed
# despite the reset window having "closed" 10 minutes ago.

Impact

An administrator who sets RESET PASSWORD CODE LIVES shorter than ACTIVATE CODE LIVES to limit the window of exposure for intercepted reset emails gets no security benefit from that configuration.
Reset tokens remain valid for the full activation lifetime (default 3 hours), giving an attacker who has intercepted a reset email a much larger window to use it.
The reset email actively misleads users by advertising a shorter expiry that is never enforced.
All password-reset operations are affected; there is no per-user or per-request way to issue a correctly-expiring token.

Recommended remediation

Option 1: Add a `ResetPasswordCodeLives`-aware generation function (preferred)

Introduce a dedicated code-generation path that passes conf.Auth.ResetPasswordCodeLives instead of ActivateCodeLives:

// internal/userx/userx.go
func GenerateResetPasswordCode(userID int64, email, name, password, rands string) string {
  code := tool.CreateTimeLimitCode(
    fmt.Sprintf("%d%s%s%s%s", userID, email, strings.ToLower(name), password, rands),
    conf.Auth.ResetPasswordCodeLives,  // ← correct lifetime
    nil,
  )
  code += hex.EncodeToString([]byte(strings.ToLower(name)))
  return code
}

Update email.User to expose this through the interface:

// internal/email/email.go interface
GenerateResetPasswordCode(email string) string

Update SendResetPasswordMail to call it:

func SendResetPasswordMail(c *macaron.Context, u User) error {
  return SendUserMail(c, u, tmplAuthResetPassword, u.GenerateResetPasswordCode(u.Email()), ...)
}

Because VerifyTimeLimitCode reads the lifetime from the token itself, no change to the verification side is required — tokens generated with ResetPasswordCodeLives will automatically expire at the correct time.

Option 2: Validate the extracted lifetime against the configured maximum

Add a post-extraction check in VerifyTimeLimitCode or in the reset-specific verification function to reject tokens whose embedded lifetime exceeds ResetPasswordCodeLives:

// in verifyUserActiveCode, after extracting the prefix:
embeddedLives := ... // parse positions 12-18 of the code
if embeddedLives > conf.Auth.ResetPasswordCodeLives {
  return nil // reject tokens with a longer-than-allowed lifetime
}

This is a defence-in-depth measure but does not fix the root cause; Option 1 is preferred.

Credit

This vulnerability was discovered and reported by bugbunny.ai.

Correção

Insufficient Session Expiration

Encontrou algum problema na descrição? Tem algo a acrescentar? Fique à vontade para nos escrever 👾

dbugs@ptsecurity.com

Enumeração de Fraquezas

CWE-324CWE-613

Identificadores relacionados

CVE-2026-52809

GHSA-5C3F-6486-3G7G

Produtos afetados

Gogs.Io/Gogs

PT-2026-51627 · Go · Gogs.Io/Gogs

CVE-2026-52809

Summary

Severity

Affected component

CWE

Description

The reset token lifetime is hardcoded to ActivateCodeLives at generation

ResetPasswordCodeLives is used only for display, not enforcement

Full execution chain

Proof of Concept

Impact

Recommended remediation

Option 1: Add a ResetPasswordCodeLives-aware generation function (preferred)

Option 2: Validate the extracted lifetime against the configured maximum

Credit

Enumeração de Fraquezas

Identificadores relacionados

Produtos afetados

Referências · 6

The reset token lifetime is hardcoded to `ActivateCodeLives` at generation

`ResetPasswordCodeLives` is used only for display, not enforcement

Option 1: Add a `ResetPasswordCodeLives`-aware generation function (preferred)