{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "gogs.io/gogs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.14.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-52809"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-23T17:03:25Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nPassword-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.\n\n## Severity\n\n**Medium** (CVSS 3.1: 6.8)\n\n`CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N`\n\n- **Attack Vector:** Network \u2014 the reset endpoint is reachable over HTTP/S.\n- **Attack Complexity:** High \u2014 successful exploitation requires (1) the instance to be configured with `RESET_PASSWORD_CODE_LIVES \u003c ACTIVATE_CODE_LIVES`, AND (2) the attacker to have intercepted the victim\u0027s reset token (e.g., from a compromised or shared email inbox).\n- **Privileges Required:** None \u2014 no Gogs account is required.\n- **User Interaction:** Required \u2014 the victim must have triggered a password-reset request.\n- **Scope:** Unchanged \u2014 the impact is confined to the victim\u0027s Gogs account.\n- **Confidentiality Impact:** High \u2014 successful exploitation leads to account takeover, exposing all private repositories and data.\n- **Integrity Impact:** High \u2014 the attacker can change the victim\u0027s password and gain full write access.\n- **Availability Impact:** None.\n\n## Affected component\n\n- `internal/userx/userx.go` \u2014 `GenerateActivateCode()` (line 39)\n- `internal/email/email.go` \u2014 `SendResetPasswordMail()` (line 132)\n- `internal/route/user/auth.go` \u2014 `verifyUserActiveCode()` (lines 426\u2013439) and `ResetPasswdPost()` (line 621)\n\n## CWE\n\n- **CWE-324**: Use of a Key Past Its Expiration Date\n- **CWE-613**: Insufficient Session Expiration\n\n## Description\n\n### The reset token lifetime is hardcoded to `ActivateCodeLives` at generation\n\n`GenerateActivateCode` (called for both account activation and password reset) bakes `conf.Auth.ActivateCodeLives` \u2014 not `ResetPasswordCodeLives` \u2014 into the token as a 6-digit field:\n\n```go\n// internal/userx/userx.go:36-46\nfunc GenerateActivateCode(userID int64, email, name, password, rands string) string {\n    code := tool.CreateTimeLimitCode(\n        fmt.Sprintf(\"%d%s%s%s%s\", userID, email, strings.ToLower(name), password, rands),\n        conf.Auth.ActivateCodeLives,   // \u2190 always ActivateCodeLives, never ResetPasswordCodeLives\n        nil,\n    )\n    code += hex.EncodeToString([]byte(strings.ToLower(name)))\n    return code\n}\n```\n\n`CreateTimeLimitCode` embeds the `minutes` value at positions 12\u201317 of the token:\n\n```\nToken format: YYYYMMDDHHMM (12) | 000180 (6-digit lives) | SHA1 (40) | hex-username\n```\n\n`SendResetPasswordMail` calls `u.GenerateEmailActivateCode(u.Email())` \u2014 which resolves to `GenerateActivateCode` \u2014 with no option to pass a different lifetime:\n\n```go\n// internal/email/email.go:131-132\nfunc SendResetPasswordMail(c *macaron.Context, u User) error {\n    return SendUserMail(c, u, tmplAuthResetPassword, u.GenerateEmailActivateCode(u.Email()), ...)\n}\n```\n\n### `ResetPasswordCodeLives` is used only for display, not enforcement\n\n`VerifyTimeLimitCode` discards the `minutes` argument and re-extracts the lifetime directly from the token itself:\n\n```go\n// internal/tool/tool.go:62-86\nfunc VerifyTimeLimitCode(data string, minutes int, code string) bool {\n    start := code[:12]\n    lives := code[12:18]\n    if d, err := strconv.Atoi(lives); err == nil {\n        minutes = d    // \u2190 argument overridden by value baked into the token\n    }\n    retCode := CreateTimeLimitCode(data, minutes, start)\n    if retCode == code \u0026\u0026 minutes \u003e 0 {\n        before, _ := time.ParseInLocation(\"200601021504\", start, time.Local)\n        if before.Add(time.Minute * time.Duration(minutes)).Unix() \u003e now.Unix() {\n            return true\n        }\n    }\n    return false\n}\n```\n\nThe `verifyUserActiveCode` caller passes `conf.Auth.ActivateCodeLives` as `minutes`, but it makes no difference:\n\n```go\n// internal/route/user/auth.go:426-439\nfunc verifyUserActiveCode(code string) (user *database.User) {\n    minutes := conf.Auth.ActivateCodeLives   // passed to VerifyTimeLimitCode but immediately overridden\n    if user = parseUserFromCode(code); user != nil {\n        prefix := code[:tool.TimeLimitCodeLength]\n        data := strconv.FormatInt(user.ID, 10) + user.Email + user.LowerName + user.Password + user.Rands\n        if tool.VerifyTimeLimitCode(data, minutes, prefix) {\n            return user\n        }\n    }\n    return nil\n}\n```\n\n`ResetPasswdPost` validates the reset token through `verifyUserActiveCode`, so it inherits the same flaw:\n\n```go\n// internal/route/user/auth.go:621\nif u := verifyUserActiveCode(code); u != nil {\n```\n\n`ResetPasswordCodeLives` appears only in email template data and in the admin config display \u2014 it has zero effect on actual token validation:\n\n```go\n// internal/email/email.go:109 \u2014 template data only, not used to generate the token\n\"ResetPwdCodeLives\": conf.Auth.ResetPasswordCodeLives / 60,\n```\n\n### Full execution chain\n\n1. **Victim requests reset**: `POST /user/forget_password` \u2192 `SendResetPasswordMail` generates a token embedding `ActivateCodeLives = 180` at bytes 12\u201317.\n2. **Email delivered**: The reset email says \"link valid for 10 minutes\" (from `ResetPwdCodeLives` in the template) but the embedded lifetime is 180.\n3. **`RESET_PASSWORD_CODE_LIVES` window closes**: After 10 minutes the victim believes the link has expired.\n4. **Attacker submits the token**: `POST /user/reset_password?code=\u003cTOKEN\u003e` \u2192 `ResetPasswdPost` \u2192 `verifyUserActiveCode` \u2192 `VerifyTimeLimitCode` extracts `000180` from the token \u2192 confirms the token has not yet reached the 180-minute mark \u2192 returns the user object \u2192 password is updated.\n5. **Account takeover**: Attacker sets a new password and authenticates as the victim.\n\n## Proof of Concept\n\n```ini\n# app.ini configuration that exposes the bug:\n[auth]\nACTIVATE_CODE_LIVES = 180\nRESET_PASSWORD_CODE_LIVES = 10\n```\n\n```bash\n# 1) Request password reset for victim account\ncurl -i -X POST -d \u0027email=victim@example.com\u0027 http://HOST/user/forget_password\n\n# 2) Obtain the reset link from the email.\n#    Wait 11 minutes (past RESET_PASSWORD_CODE_LIVES, within ACTIVATE_CODE_LIVES).\n\n# 3) Submit the \"expired\" reset code \u2014 it still succeeds\ncurl -i -X POST \\\n  -d \u0027code=\u003cCODE_FROM_EMAIL\u003e\u0026password=AttackerNewPass\u0027 \\\n  \u0027http://HOST/user/reset_password?code=\u003cCODE_FROM_EMAIL\u003e\u0027\n\n# Expected: HTTP 302 redirect to /user/login \u2014 password successfully changed\n# despite the reset window having \"closed\" 10 minutes ago.\n```\n\n## Impact\n\n- 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.\n- 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.\n- The reset email actively misleads users by advertising a shorter expiry that is never enforced.\n- All password-reset operations are affected; there is no per-user or per-request way to issue a correctly-expiring token.\n\n## Recommended remediation\n\n### Option 1: Add a `ResetPasswordCodeLives`-aware generation function (preferred)\n\nIntroduce a dedicated code-generation path that passes `conf.Auth.ResetPasswordCodeLives` instead of `ActivateCodeLives`:\n\n```go\n// internal/userx/userx.go\nfunc GenerateResetPasswordCode(userID int64, email, name, password, rands string) string {\n    code := tool.CreateTimeLimitCode(\n        fmt.Sprintf(\"%d%s%s%s%s\", userID, email, strings.ToLower(name), password, rands),\n        conf.Auth.ResetPasswordCodeLives,   // \u2190 correct lifetime\n        nil,\n    )\n    code += hex.EncodeToString([]byte(strings.ToLower(name)))\n    return code\n}\n```\n\nUpdate `email.User` to expose this through the interface:\n\n```go\n// internal/email/email.go interface\nGenerateResetPasswordCode(email string) string\n```\n\nUpdate `SendResetPasswordMail` to call it:\n\n```go\nfunc SendResetPasswordMail(c *macaron.Context, u User) error {\n    return SendUserMail(c, u, tmplAuthResetPassword, u.GenerateResetPasswordCode(u.Email()), ...)\n}\n```\n\nBecause `VerifyTimeLimitCode` reads the lifetime from the token itself, no change to the verification side is required \u2014 tokens generated with `ResetPasswordCodeLives` will automatically expire at the correct time.\n\n### Option 2: Validate the extracted lifetime against the configured maximum\n\nAdd a post-extraction check in `VerifyTimeLimitCode` or in the reset-specific verification function to reject tokens whose embedded lifetime exceeds `ResetPasswordCodeLives`:\n\n```go\n// in verifyUserActiveCode, after extracting the prefix:\nembeddedLives := ... // parse positions 12-18 of the code\nif embeddedLives \u003e conf.Auth.ResetPasswordCodeLives {\n    return nil  // reject tokens with a longer-than-allowed lifetime\n}\n```\n\nThis is a defence-in-depth measure but does not fix the root cause; Option 1 is preferred.\n\n## Credit\n\nThis vulnerability was discovered and reported by [bugbunny.ai](https://bugbunny.ai).",
  "id": "GHSA-5c3f-6486-3g7g",
  "modified": "2026-06-23T17:03:25Z",
  "published": "2026-06-23T17:03:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-5c3f-6486-3g7g"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/pull/8328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/commit/187e9c557930eb4a8b9b1502ee45cccf3255ee7f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gogs/gogs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/releases/tag/v0.14.3"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gogs\u0027s password-reset tokens use account-activation lifetime, ignoring RESET_PASSWORD_CODE_LIVES"
}