{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/coder/coder/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.23.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-08-28T19:36:04Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Summary\nIf users log in to Coder via OIDC, and the OpenID Identity Provider does not return a refresh token, then Coder may allow their web session to continue beyond the expiration of the token returned by the OpenID Identity Provider.\n\n### Details\nWhen a user logs in via OIDC, Coder stores the OIDC token and refresh token (if any) in its datastore and sets an APIKey in the user\u0027s cookies. If there is a refresh token, then when the OIDC token is expired and a request is made with the APIKey, we attempt to refresh the OIDC token. If refresh fails, the Coder API request is also failed and the user needs to log in again.\n\nHowever, if there is no refresh token provided, then affected versions of Coder fail to enforce the expiry of the OIDC token, and allow users to make API requests even if it is expired so long as their APIKey stored in cookies has not expired.\n\nCoder APIKeys have an expiry and lifetime of 24 hours, but Coder is configured to extend the lifetime of the APIKey by up to 24 hours from the time it is used successfully. So, an APIKey that is used at least once every 24 hours will not expire. (This behavior can be disabled by configuration). \n\n### Impact\nThis could allow a user to access the Coder service beyond the lifetime of the token issued by the OpenID provider, potentially indefinitely, even if they are no loner authorized via OIDC.",
  "id": "GHSA-3rw9-wmc8-8948",
  "modified": "2025-08-28T19:36:05Z",
  "published": "2025-08-28T19:36:04Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/security/advisories/GHSA-3rw9-wmc8-8948"
    },
    {
      "type": "WEB",
      "url": "https://github.com/coder/coder/commit/1a4160803589034ce1518e24a78f232c8d08f996"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/coder/coder"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Coder accepts an APIKey beyond the linked OIDC expiry if there is no refresh token"
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "python-keystoneclient"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.2.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2013-2104"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-29T18:28:22Z",
    "nvd_published_at": "2014-01-21T18:55:00Z",
    "severity": "HIGH"
  },
  "details": "python-keystoneclient before 0.2.4, as used in OpenStack Keystone (Folsom), does not properly check expiry for PKI tokens, which allows remote authenticated users to (1) retain use of a token after it has expired, or (2) use a revoked token once it expires.",
  "id": "GHSA-4rrr-j7ff-r844",
  "modified": "2024-10-25T21:14:44Z",
  "published": "2022-05-17T04:54:13Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-2104"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2013:0944"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2013-2104"
    },
    {
      "type": "WEB",
      "url": "https://bugs.launchpad.net/python-keystoneclient/+bug/1179615"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=965852"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openstack/python-keystoneclient"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/python-keystoneclient/PYSEC-2014-69.yaml"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-updates/2013-06/msg00198.html"
    },
    {
      "type": "WEB",
      "url": "http://rhn.redhat.com/errata/RHSA-2013-0944.html"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2013/05/28/7"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1851-1"
    },
    {
      "type": "WEB",
      "url": "http://www.ubuntu.com/usn/USN-1875-1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "python-keystoneclient missing expiration check in PKI token validation "
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.keycloak:keycloak-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "24.0.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-09-09T22:34:10Z",
    "nvd_published_at": "2024-09-09T19:15:14Z",
    "severity": "MODERATE"
  },
  "details": "# Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-xmmm-jw76-q7vg. This link is maintained to preserve external references.\n\n# Original Description\nA vulnerability was found in Keycloak. Expired OTP codes are still usable when using FreeOTP when the OTP token period is set to 30 seconds (default). Instead of expiring and deemed unusable around 30 seconds in, the tokens are valid for an additional 30 seconds totaling 1 minute.\nA one time passcode that is valid longer than its expiration time increases the attack window for malicious actors to abuse the system and compromise accounts. Additionally, it increases the attack surface because at any given time, two OTPs are valid.",
  "id": "GHSA-57rh-gr4v-j5f6",
  "modified": "2024-12-20T17:49:28Z",
  "published": "2024-09-09T21:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-7318"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6502"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:6503"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-7318"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2301876"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Duplicate Advisory: Keycloak Uses a Key Past its Expiration Date",
  "withdrawn": "2024-12-20T17:49:27Z"
}

{
  "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"
}

{
  "affected": [],
  "aliases": [
    "CVE-2024-25679"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-09T10:15:08Z",
    "severity": "MODERATE"
  },
  "details": "In PQUIC before 5bde5bb, retention of unused initial encryption keys allows attackers to disrupt a connection with a PSK configuration by sending a CONNECTION_CLOSE frame that is encrypted via the initial key computed. Network traffic sniffing is needed as part of exploitation.",
  "id": "GHSA-65j3-gr82-45jh",
  "modified": "2024-02-15T21:31:27Z",
  "published": "2024-02-09T12:30:26Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25679"
    },
    {
      "type": "WEB",
      "url": "https://github.com/p-quic/pquic/issues/35"
    },
    {
      "type": "WEB",
      "url": "https://github.com/p-quic/pquic/pull/39"
    },
    {
      "type": "WEB",
      "url": "https://www.rfc-editor.org/rfc/rfc9001#name-discarding-unused-keys"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/foxcpp/maddy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2022-24732"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-03-07T16:59:31Z",
    "nvd_published_at": "2022-03-09T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\n\nAny configuration on any maddy version \u003c0.5.4 using auth.pam is affected.\n\nNo password expiry or account expiry checking is done when authenticating using PAM.\n\n### Patches\n\nPatch is available as part of the 0.5.4 release.\n\n### Workarounds\n\nIf /etc/shadow authentication is used, it is possible to replace auth.pam with auth.shadow which is not affected.\n\nIt is possible to blacklist expired accounts via existing filtering mechanisms (e.g. auth_map to invalid accounts in storage.imapsql).\n\n### References\n\n* https://github.com/foxcpp/maddy/blob/3412e59a2c92106e194fa69f2f1017c020037c9c/internal/auth/pam/pam.c\n* https://linux.die.net/man/3/pam_acct_mgmt\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in https://github.com/foxcpp/maddy\n* Email fox.cpp@disroot.org\n",
  "id": "GHSA-6cp7-g972-w9m9",
  "modified": "2022-03-18T20:12:30Z",
  "published": "2022-03-07T16:59:31Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/security/advisories/GHSA-6cp7-g972-w9m9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-24732"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/commit/7ee6a39c6a1939b376545f030a5efd6f90913583"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/foxcpp/maddy"
    },
    {
      "type": "WEB",
      "url": "https://github.com/foxcpp/maddy/releases/tag/v0.5.4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Use of a Key Past its Expiration Date and Insufficient Session Expiration in Maddy Mail Server"
}

{
  "affected": [],
  "aliases": [
    "CVE-2019-3790"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324",
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-06-06T19:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Pivotal Ops Manager, 2.2.x versions prior to 2.2.23, 2.3.x versions prior to 2.3.16, 2.4.x versions prior to 2.4.11, and 2.5.x versions prior to 2.5.3, contain configuration that circumvents refresh token expiration. A remote authenticated user can gain access to a browser session that was supposed to have expired, and access Ops Manager resources.",
  "id": "GHSA-73vj-wxr6-3pq5",
  "modified": "2024-04-04T00:53:33Z",
  "published": "2022-05-24T16:47:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-3790"
    },
    {
      "type": "WEB",
      "url": "https://pivotal.io/security/cve-2019-3790"
    },
    {
      "type": "WEB",
      "url": "http://www.securityfocus.com/bid/108512"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-33012"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-11-07T19:15:46Z",
    "severity": "MODERATE"
  },
  "details": "IBM Db2 10.5.0 through 10.5.11, 11.1.0 through 11.1.4.7, 11.5.0 through 11.5.9, and 12.1.0 through 12.1.3 for Linux could allow an authenticated user to regain access after account lockout due to password use after expiration date.",
  "id": "GHSA-fgjg-3fmq-57hw",
  "modified": "2025-11-07T21:31:20Z",
  "published": "2025-11-07T21:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-33012"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7250469"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [],
  "aliases": [
    "CVE-2025-48813"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-324"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-10-14T17:15:42Z",
    "severity": "MODERATE"
  },
  "details": "Use of a key past its expiration date in Virtual Secure Mode allows an authorized attacker to perform spoofing locally.",
  "id": "GHSA-h47g-rccf-mmx4",
  "modified": "2025-10-14T18:30:29Z",
  "published": "2025-10-14T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-48813"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-48813"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/contao"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.7.0"
            },
            {
              "fixed": "4.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "contao/core-bundle"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.7.0"
            },
            {
              "fixed": "4.7.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-10643"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-324"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-25T23:15:07Z",
    "nvd_published_at": "2019-04-17T19:29:00Z",
    "severity": "CRITICAL"
  },
  "details": "Security researcher Ali Razzaq has discovered that confirming an opt-in token does not invalidate previous opt-in tokens in Contao 4.7.",
  "id": "GHSA-j99g-qjvx-995g",
  "modified": "2024-04-25T23:15:07Z",
  "published": "2022-05-13T01:07:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10643"
    },
    {
      "type": "WEB",
      "url": "https://github.com/contao/contao/commit/70348cc812b110831ad66a4f9857883f75649b88"
    },
    {
      "type": "WEB",
      "url": "https://contao.org/en/news.html"
    },
    {
      "type": "WEB",
      "url": "https://contao.org/en/news/security-vulnerability-cve-2019-10643.html"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/contao/contao/CVE-2019-10643.yaml"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/contao/core-bundle/CVE-2019-10643.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Contao Does Not Expire Tokens Correctly"
}