GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
Common Weakness Enumeration

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

According to WASC, "Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization."

959 vulnerabilities reference this CWE, most recent first.

GHSA-5C3F-6486-3G7G

Vulnerability from github – Published: 2026-06-23 17:03 – Updated: 2026-07-21 13:17
VLAI
Summary
Gogs's password-reset tokens use account-activation lifetime, ignoring RESET_PASSWORD_CODE_LIVES
Details

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

  1. Victim requests reset: POST /user/forget_password → SendResetPasswordMail generates a token embedding ActivateCodeLives = 180 at bytes 12–17.
  2. Email delivered: The reset email says "link valid for 10 minutes" (from ResetPwdCodeLives in the template) but the embedded lifetime is 180.
  3. RESET_PASSWORD_CODE_LIVES window closes: After 10 minutes the victim believes the link has expired.
  4. 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.
  5. Account takeover: Attacker sets a new password and authenticates as the victim.

Proof of Concept

# app.ini configuration that exposes the bug:
[auth]
ACTIVATE_CODE_LIVES = 180
RESET_PASSWORD_CODE_LIVES = 10

# 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.

Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "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": "2026-06-24T21:16:56Z",
    "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-07-21T13:17:14Z",
  "published": "2026-06-23T17:03:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gogs/gogs/security/advisories/GHSA-5c3f-6486-3g7g"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-52809"
    },
    {
      "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"
}

GHSA-5FMW-QRMV-X2MW

Vulnerability from github – Published: 2022-05-24 19:19 – Updated: 2022-05-24 19:19
VLAI
Details

A vulnerability in the web-based management interface of multiple Cisco Small Business Series Switches could allow an unauthenticated, remote attacker to replay valid user session credentials and gain unauthorized access to the web-based management interface of an affected device. This vulnerability is due to insufficient expiration of session credentials. An attacker could exploit this vulnerability by conducting a man-in-the-middle attack against an affected device to intercept valid session credentials and then replaying the intercepted credentials toward the same device at a later time. A successful exploit could allow the attacker to access the web-based management interface with administrator privileges.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-34739"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-11-04T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability in the web-based management interface of multiple Cisco Small Business Series Switches could allow an unauthenticated, remote attacker to replay valid user session credentials and gain unauthorized access to the web-based management interface of an affected device. This vulnerability is due to insufficient expiration of session credentials. An attacker could exploit this vulnerability by conducting a man-in-the-middle attack against an affected device to intercept valid session credentials and then replaying the intercepted credentials toward the same device at a later time. A successful exploit could allow the attacker to access the web-based management interface with administrator privileges.",
  "id": "GHSA-5fmw-qrmv-x2mw",
  "modified": "2022-05-24T19:19:47Z",
  "published": "2022-05-24T19:19:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34739"
    },
    {
      "type": "WEB",
      "url": "https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-smb-switches-tokens-UzwpR4e5"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-5FRQ-4CX3-FRC8

Vulnerability from github – Published: 2024-06-11 12:31 – Updated: 2024-08-06 15:30
VLAI
Details

A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions < V1.2). The affected application does not expire the session. This could allow an attacker to get unauthorized access.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
8.6 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-35206"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-11T12:15:16Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in SINEC Traffic Analyzer (6GK8822-1BG01-0BA0) (All versions \u003c V1.2). The affected application does not expire the session. This could allow an attacker to get unauthorized access.",
  "id": "GHSA-5frq-4cx3-frc8",
  "modified": "2024-08-06T15:30:47Z",
  "published": "2024-06-11T12:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-35206"
    },
    {
      "type": "WEB",
      "url": "https://cert-portal.siemens.com/productcert/html/ssa-196737.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5G48-C3VF-4XC7

Vulnerability from github – Published: 2026-09-02 00:31 – Updated: 2026-09-02 00:31
VLAI
Details

WWBN AVideo fails to validate password recovery token expiration in userRecoverPassSave.json.php, allowing attackers to use expired tokens to reset account passwords indefinitely. Attackers who obtain a recovery token can use it at any time to change the target account's password and gain full account access.

Severity
9.8 (Critical)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
9.3 (Critical)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-84480"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-01T23:17:22Z",
    "severity": "CRITICAL"
  },
  "details": "WWBN AVideo fails to validate password recovery token expiration in userRecoverPassSave.json.php, allowing attackers to use expired tokens to reset account passwords indefinitely. Attackers who obtain a recovery token can use it at any time to change the target account\u0027s password and gain full account access.",
  "id": "GHSA-5g48-c3vf-4xc7",
  "modified": "2026-09-02T00:31:30Z",
  "published": "2026-09-02T00:31:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-j9p7-hm85-9v77"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-84480"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/wwbn-avideo-password-recovery-token-expiration-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-5GVV-3X4Q-5HP6

Vulnerability from github – Published: 2022-05-24 17:10 – Updated: 2024-04-04 02:48
VLAI
Details

SAP Enable Now, before version 1908, does not invalidate session tokens in a timely manner. The Insufficient Session Expiration may allow attackers with local access, for instance, to still download the portables.

Severity
3.3 (Low)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-6197"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2020-03-10T21:15:00Z",
    "severity": "LOW"
  },
  "details": "SAP Enable Now, before version 1908, does not invalidate session tokens in a timely manner. The Insufficient Session Expiration may allow attackers with local access, for instance, to still download the portables.",
  "id": "GHSA-5gvv-3x4q-5hp6",
  "modified": "2024-04-04T02:48:59Z",
  "published": "2022-05-24T17:10:43Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-6197"
    },
    {
      "type": "WEB",
      "url": "https://launchpad.support.sap.com/#/notes/2845363"
    },
    {
      "type": "WEB",
      "url": "https://wiki.scn.sap.com/wiki/pages/viewpage.action?pageId=540935305"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-5H3F-885M-V22W

Vulnerability from github – Published: 2026-04-09 17:36 – Updated: 2026-04-28 18:27
VLAI
Summary
OpenClaw: Existing WS sessions survive shared gateway token rotation
Details

Impact

Existing WS sessions survive shared gateway token rotation.

Rotating the shared gateway token did not disconnect existing shared-token WebSocket sessions.

OpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Affected versions: <= 2026.4.1
  • Patched versions: 2026.4.8

Fix

The issue was fixed on main and is available in the patched npm version listed above. The verified fixed tree is commit d7c3210cd6f5fdfdc1beff4c9541673e814354d5.

Verification

The fix was re-checked against main before publication, including targeted regression tests for the affected security boundary.

Credits

Thanks @kexinoh of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting.

Severity
5.9 (Medium)
CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42421"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-09T17:36:02Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Impact\n\nExisting WS sessions survive shared gateway token rotation.\n\nRotating the shared gateway token did not disconnect existing shared-token WebSocket sessions.\n\nOpenClaw is a user-controlled local assistant. This advisory is scoped to the OpenClaw trust model and does not assume a multi-tenant service boundary.\n\n## Affected Packages / Versions\n\n- Package: `openclaw` (npm)\n- Affected versions: `\u003c= 2026.4.1`\n- Patched versions: `2026.4.8`\n\n## Fix\n\nThe issue was fixed on `main` and is available in the patched npm version listed above. The verified fixed tree is commit `d7c3210cd6f5fdfdc1beff4c9541673e814354d5`.\n\n## Verification\n\nThe fix was re-checked against `main` before publication, including targeted regression tests for the affected security boundary.\n\n## Credits\n\nThanks @kexinoh of Tencent zhuque Lab (https://github.com/Tencent/AI-Infra-Guard) for reporting.",
  "id": "GHSA-5h3f-885m-v22w",
  "modified": "2026-04-28T18:27:44Z",
  "published": "2026-04-09T17:36:02Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-5h3f-885m-v22w"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Existing WS sessions survive shared gateway token rotation"
}

GHSA-5HFV-C864-QCQ9

Vulnerability from github – Published: 2026-05-04 20:50 – Updated: 2026-05-08 20:14
VLAI
Summary
CI4MS has a Deactivated User Session Bypass (active=0)
Details

Summary

The auth filter has the deactivated/banned user check commented out.

Details

CodeIgniter Shield's loggedIn() re-checks the status field (catching status='banned'), but does not re-check the active field for existing sessions. When an admin deactivates a user (active=0) after they have already logged in: - Their session cookie remains valid - auth()->loggedIn() still returns true - The commented-out code is the only mechanism that would have checked !$user->active

Evidence

image

Impact

  • User deactivation does NOT immediately revoke backend access
  • Deactivated user retains full access until session expires (default: 7200s)

Additional note

The commented-out block appears to be a deferred placeholder — it was written but disabled from the very first commit that introduced the filter, and has never been active. The later addition of SessionTracker (v0.31.4.0) suggests the dev was aware of the session revocation gap, but account-level deactivation (users.active = 0) remains unenforced. Could you verify if this is intentionally pending or simply forgotten and not documented?.

Severity
5.3 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.31.7.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.26.0"
            },
            {
              "fixed": "0.31.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41891"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T20:50:55Z",
    "nvd_published_at": "2026-05-07T04:16:33Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\nThe auth filter has the deactivated/banned user check commented out. \n\n### Details\nCodeIgniter Shield\u0027s `loggedIn()` re-checks the `status` field (catching `status=\u0027banned\u0027`), but does **not** re-check the `active` field for existing sessions. When an admin deactivates a user (`active=0`) after they have already logged in:\n- Their session cookie remains valid\n- `auth()-\u003eloggedIn()` still returns `true`\n- The commented-out code is the only mechanism that would have checked `!$user-\u003eactive`\n\n### Evidence\n\u003cimg width=\"981\" height=\"654\" alt=\"image\" src=\"https://github.com/user-attachments/assets/6f75d144-5bcf-4a3f-bc35-bb0715c3ed05\" /\u003e\n\n\n### Impact\n- User deactivation does NOT immediately revoke backend access\n- Deactivated user retains full access until session expires (default: 7200s)\n\n### Additional note\nThe commented-out block appears to be a deferred placeholder \u2014 it was written but disabled from the very first commit that introduced the filter, and has never been active. The later addition of SessionTracker (v0.31.4.0) suggests the dev was aware of the session revocation gap, but account-level deactivation (users.active = 0) remains unenforced. Could you verify if this is intentionally pending or simply forgotten and not documented?.",
  "id": "GHSA-5hfv-c864-qcq9",
  "modified": "2026-05-08T20:14:41Z",
  "published": "2026-05-04T20:50:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-5hfv-c864-qcq9"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41891"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/commit/2f38284281ce6b435ea42003951f14109ac2cea7"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.8.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "CI4MS has a Deactivated User Session Bypass (active=0)"
}

GHSA-5MRQ-X3X5-8V8F

Vulnerability from github – Published: 2026-05-05 17:03 – Updated: 2026-06-06 00:27
VLAI
Summary
Jupyter Server's Authentication Cookies Remain Valid After Password Reset and Server Restart
Details

Summary

A persistent cookie secret vulnerability allows authenticated users to maintain indefinite access even after password changes.

The cookie secret used to sign authentication cookies is stored in a permanent file (~/.local/share/jupyter/runtime/jupyter_cookie_secret) that is never automatically rotated or cleared, allowing stolen or compromised cookies to remain valid indefinitely regardless of password resets.

PoC

  • Start a Jupyter server with password authentication: jupyter server password, jupyter server
  • Log in with the password and capture the authentication cookie (e.g., just login with a browser).
  • Change the password to revoke access: jupyter server password
  • Restart the server
  • Use the old stolen cookie => remains valid and provides full authenticated access.

Impact

  • All jupyter-server deployments using password authentication where security incidents may occur
  • Multi-user systems where one user's compromised session should be revocable by administrators
  • Shared or public-facing Jupyter servers where credential rotation is a security requirement
  • Any deployment where password changes are expected to revoke existing sessions

Patches

Jupyter Server 2.18+

Workaround

rm ~/.local/share/jupyter/runtime/jupyter_cookie_secret
# Then restart the server
Severity
6.8 (Medium)
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
7.6 (High)
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.17.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "jupyter-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.18.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40934"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-05T17:03:24Z",
    "nvd_published_at": "2026-05-05T22:16:00Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nA persistent cookie secret vulnerability allows authenticated users to maintain indefinite access even after password changes. \n\nThe cookie secret used to sign authentication cookies is stored in a permanent file (`~/.local/share/jupyter/runtime/jupyter_cookie_secret`) that is never automatically rotated or cleared, allowing stolen or compromised cookies to remain valid indefinitely regardless of password resets.\n\n## PoC\n\n- Start a Jupyter server with password authentication: `jupyter server password`, `jupyter server`\n- Log in with the password and capture the authentication cookie (e.g., just login with a browser).\n- Change the password to revoke access: `jupyter server password`\n- Restart the server\n- Use the old stolen cookie =\u003e remains valid and provides full authenticated access.\n\n## Impact\n\n- All jupyter-server deployments using password authentication where security incidents may occur\n- Multi-user systems where one user\u0027s compromised session should be revocable by administrators\n- Shared or public-facing Jupyter servers where credential rotation is a security requirement\n- Any deployment where password changes are expected to revoke existing sessions\n\n## Patches\n\nJupyter Server 2.18+\n\n## Workaround\n\n```bash\nrm ~/.local/share/jupyter/runtime/jupyter_cookie_secret\n# Then restart the server\n```",
  "id": "GHSA-5mrq-x3x5-8v8f",
  "modified": "2026-06-06T00:27:08Z",
  "published": "2026-05-05T17:03:24Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jupyter-server/jupyter_server/security/advisories/GHSA-5mrq-x3x5-8v8f"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40934"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jupyter-server/jupyter_server"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/jupyter-server/PYSEC-2026-69.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Jupyter Server\u0027s Authentication Cookies Remain Valid After Password Reset and Server Restart"
}

GHSA-5MVJ-RVP8-RF45

Vulnerability from github – Published: 2023-07-28 15:35 – Updated: 2023-07-28 15:35
VLAI
Summary
Insufficient Session Expiration after a password change
Details

TL;DR

This vulnerability affects all Kirby sites with user accounts (unless Kirby's API and Panel are disabled in the config).

It can only be abused if a Kirby user is logged in on a device or browser that is shared with potentially untrusted users or if an attacker already maliciously used a previous password to log in to a Kirby site as the affected user.

Introduction

Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.

In the variation described in this advisory, it allows attackers to stay logged in to a Kirby site on another device or browser even if the logged in user has since changed their password.

Impact

Kirby did not invalidate old user sessions after the user password was changed by the user or by a site admin.

If a user changed their password to lock out an attacker who was already in possession of the previous password or of a login session on another device or browser, the attacker would not be reliably prevented from accessing the Kirby site as the affected user.

Patches

The problem has been patched in Kirby 3.5.8.3, Kirby 3.6.6.3, Kirby 3.7.5.2, Kirby 3.8.4.1 and Kirby 3.9.6. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have updated the authentication implementation to keep track of the last time the password was changed. If a new password was set since the login, the session is invalidated. To enforce this fix even if the vulnerability was previously abused, all users are logged out from the Kirby site after updating to one of the patched releases.

Credits

Thanks to Shankar Acharya (@5hank4r) for responsibly reporting the identified issue.

Severity
7.3 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.5.8.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.6.0"
            },
            {
              "fixed": "3.6.6.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.7.0"
            },
            {
              "fixed": "3.7.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.8.0"
            },
            {
              "fixed": "3.8.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "getkirby/cms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.9.0"
            },
            {
              "fixed": "3.9.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-38489"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-07-28T15:35:25Z",
    "nvd_published_at": "2023-07-27T15:15:12Z",
    "severity": "HIGH"
  },
  "details": "### TL;DR\n\nThis vulnerability affects all Kirby sites with user accounts (unless Kirby\u0027s API and Panel are disabled in the config).\n\nIt can only be abused if a Kirby user is logged in on a device or browser that is shared with potentially untrusted users or if an attacker already maliciously used a previous password to log in to a Kirby site as the affected user.\n\n----\n\n### Introduction\n\nInsufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization.\n\nIn the variation described in this advisory, it allows attackers to stay logged in to a Kirby site on another device or browser even if the logged in user has since changed their password.\n\n### Impact\n\nKirby did not invalidate old user sessions after the user password was changed by the user or by a site admin.\n\nIf a user changed their password to lock out an attacker who was already in possession of the previous password or of a login session on another device or browser, the attacker would not be reliably prevented from accessing the Kirby site as the affected user.\n\n### Patches\n\nThe problem has been patched in [Kirby 3.5.8.3](https://github.com/getkirby/kirby/releases/tag/3.5.8.3), [Kirby 3.6.6.3](https://github.com/getkirby/kirby/releases/tag/3.6.6.3), [Kirby 3.7.5.2](https://github.com/getkirby/kirby/releases/tag/3.7.5.2), [Kirby 3.8.4.1](https://github.com/getkirby/kirby/releases/tag/3.8.4.1) and [Kirby 3.9.6](https://github.com/getkirby/kirby/releases/tag/3.9.6). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability.\n\nIn all of the mentioned releases, we have updated the authentication implementation to keep track of the last time the password was changed. If a new password was set since the login, the session is invalidated. To enforce this fix even if the vulnerability was previously abused, all users are logged out from the Kirby site after updating to one of the patched releases.\n\n### Credits\n\nThanks to Shankar Acharya (@5hank4r) for responsibly reporting the identified issue.",
  "id": "GHSA-5mvj-rvp8-rf45",
  "modified": "2023-07-28T15:35:25Z",
  "published": "2023-07-28T15:35:25Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/security/advisories/GHSA-5mvj-rvp8-rf45"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-38489"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/commit/7a0a2014c69fdb925ea02f30e7793bb50115e931"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/getkirby/kirby"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.5.8.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.6.6.3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.7.5.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.8.4.1"
    },
    {
      "type": "WEB",
      "url": "https://github.com/getkirby/kirby/releases/tag/3.9.6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Insufficient Session Expiration after a password change"
}

GHSA-5Q53-X3G6-993R

Vulnerability from github – Published: 2022-09-22 00:00 – Updated: 2022-09-25 00:00
VLAI
Details

Rapid7 InsightVM suffers from an information exposure issue whereby, when the user's session has ended due to inactivity, an attacker can use the Inspect Element browser feature to remove the login panel and view the details available in the last webpage visited by previous user

Severity
5.3 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2019-5641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-21T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Rapid7 InsightVM suffers from an information exposure issue whereby, when the user\u0027s session has ended due to inactivity, an attacker can use the Inspect Element browser feature to remove the login panel and view the details available in the last webpage visited by previous user",
  "id": "GHSA-5q53-x3g6-993r",
  "modified": "2022-09-25T00:00:26Z",
  "published": "2022-09-22T00:00:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5641"
    },
    {
      "type": "WEB",
      "url": "https://docs.rapid7.com/release-notes/insightvm/20220830"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list