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

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

980 vulnerabilities reference this CWE, most recent first.

GHSA-4M3V-Q747-PC6H

Vulnerability from github – Published: 2026-07-02 17:13 – Updated: 2026-07-02 17:13
VLAI
Summary
OpenClaw: Mattermost slash token revocation could lag until monitor refresh
Details

Summary

Mattermost slash token revocation could lag until monitor refresh. In affected versions, a caller with an old Mattermost slash token during the refresh window could continue accepting the old token until the monitor refreshed.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could invoke slash command behavior briefly after token revocation. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.4.24.

Mitigations

restart or refresh the Mattermost monitor after token rotation until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.4.23"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.4.24"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-02T17:13:01Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nMattermost slash token revocation could lag until monitor refresh. In affected versions, a caller with an old Mattermost slash token during the refresh window could continue accepting the old token until the monitor refreshed.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could invoke slash command behavior briefly after token revocation. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.4.24`.\n\n### Mitigations\n\nrestart or refresh the Mattermost monitor after token rotation until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-4m3v-q747-pc6h",
  "modified": "2026-07-02T17:13:01Z",
  "published": "2026-07-02T17:13:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-4m3v-q747-pc6h"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Mattermost slash token revocation could lag until monitor refresh"
}

GHSA-4M82-P8CX-F94J

Vulnerability from github – Published: 2026-07-01 20:16 – Updated: 2026-07-01 20:16
VLAI
Summary
SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls
Details

A LIVE SELECT subscription records the user's auth state ($auth, $token, $session, $access) when it is registered, and the server uses that recorded state to evaluate the table- and row-level PERMISSIONS clauses for every subsequent notification. The recorded state is never refreshed.

When something changes the user's effective auth state — the originating session is invalidated, the session's TTL expires, or the user signs in, signs up, or authenticates as a different identity on the same connection — the subscription keeps delivering notifications under the old, stale auth state, and the PERMISSIONS that should now apply to the connection are never consulted.

Impact

A user whose session has been revoked, expired, signed out of, or re-authenticated on the same connection continues to receive real-time notifications evaluated against the prior principal. The attacker does not gain access to new resources — only continued access to resources the prior principal was already permitted to read — but that continued access persists past the point the principal change should have ended it, and persists indefinitely until the originating connection is closed.

This is confidentiality-only: the dispatcher does not enable writes evaluated under the stranded principal.

Patches

  • invalidate() and TTL expiryRpcProtocol::invalidate now calls cleanup_lqs(session_id) after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session's exp and skips delivery once it has passed, closing the TTL-expiry leg without requiring the Session object to remain in memory.
  • Principal change on signin / signup / authenticate / refresh — each of these RPC methods now snapshots the session's auth principal (Auth::id() + Auth::level()) before mutating the session and, if the principal has changed after the operation, calls cleanup_lqs(session_id). Token refresh against the same identity is therefore preserved; identity change tears stranded subscriptions down.

Versions 3.1.0 and later are not affected by this issue.

Workarounds

For unpatched versions, clients should call reset() (which tears down all LIVE queries owned by the session) or kill each outstanding live query ID before signing out, signing in as a different identity, or signing up on an existing connection. There is no client-side workaround for the TTL-expiry leg; deployments concerned about it should restrict DURATION FOR SESSION on access methods that have permission to register LIVE queries.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "surrealdb"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T20:16:12Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "A `LIVE SELECT` subscription records the user\u0027s auth state (`$auth`, `$token`, `$session`, `$access`) when it is registered, and the server uses that recorded state to evaluate the table- and row-level `PERMISSIONS` clauses for every subsequent notification. The recorded state is never refreshed. \n\nWhen something changes the user\u0027s effective auth state \u2014 the originating session is invalidated, the session\u0027s TTL expires, or the user signs in, signs up, or authenticates as a different identity on the same connection \u2014 the subscription keeps delivering notifications under the old, stale auth state, and the `PERMISSIONS` that should now apply to the connection are never consulted.\n\n### Impact\n\nA user whose session has been revoked, expired, signed out of, or re-authenticated on the same connection continues to receive real-time notifications evaluated against the prior principal. The attacker does not gain access to new resources \u2014 only continued access to resources the prior principal was already permitted to read \u2014 but that continued access persists past the point the principal change should have ended it, and persists indefinitely until the originating connection is closed.\n\nThis is confidentiality-only: the dispatcher does not enable writes evaluated under the stranded principal.\n\n### Patches\n\n- **`invalidate()` and TTL expiry** \u2014 `RpcProtocol::invalidate` now calls `cleanup_lqs(session_id)` after clearing the session, dropping every LIVE owned by the now-invalidated session. The notification dispatcher additionally reads the originating session\u0027s `exp` and skips delivery once it has passed, closing the TTL-expiry leg without requiring the `Session` object to remain in memory.\n- **Principal change on `signin` / `signup` / `authenticate` / `refresh`** \u2014 each of these RPC methods now snapshots the session\u0027s auth principal (`Auth::id()` + `Auth::level()`) before mutating the session and, if the principal has changed after the operation, calls `cleanup_lqs(session_id)`. Token refresh against the same identity is therefore preserved; identity change tears stranded subscriptions down.\n\nVersions  3.1.0 and later are not affected by this issue.\n\n### Workarounds\n\nFor unpatched versions, clients should call `reset()` (which tears down all LIVE queries owned by the session) or `kill` each outstanding `live query ID` before signing out, signing in as a different identity, or signing up on an existing connection. There is no client-side workaround for the TTL-expiry leg; deployments concerned about it should restrict `DURATION FOR SESSION` on access methods that have permission to register LIVE queries.",
  "id": "GHSA-4m82-p8cx-f94j",
  "modified": "2026-07-01T20:16:12Z",
  "published": "2026-07-01T20:16:12Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/security/advisories/GHSA-4m82-p8cx-f94j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/6cc48412c975d51b47617708ec44abc11ca5a89a"
    },
    {
      "type": "WEB",
      "url": "https://github.com/surrealdb/surrealdb/commit/cbec0a73dc9575994d2b9c1aec26af539dc99878"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/surrealdb/surrealdb"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SurrealDB: LIVE query subscriptions survive session state changes, bypassing access controls"
}

GHSA-4M8G-QFMV-JCQG

Vulnerability from github – Published: 2023-01-05 18:30 – Updated: 2023-01-12 03:30
VLAI
Details

IBM Robotic Process Automation for Cloud Pak 20.12 through 21.0.3 is vulnerable to broken access control. A user is not correctly redirected to the platform log out screen when logging out of IBM RPA for Cloud Pak. IBM X-Force ID: 239081.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-43844"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-01-05T18:15:00Z",
    "severity": "HIGH"
  },
  "details": "IBM Robotic Process Automation for Cloud Pak 20.12 through 21.0.3 is vulnerable to broken access control. A user is not correctly redirected to the platform log out screen when logging out of IBM RPA for Cloud Pak. IBM X-Force ID: 239081.",
  "id": "GHSA-4m8g-qfmv-jcqg",
  "modified": "2023-01-12T03:30:15Z",
  "published": "2023-01-05T18:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-43844"
    },
    {
      "type": "WEB",
      "url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/239081"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/6852663"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4R8W-3JWW-M2RP

Vulnerability from github – Published: 2025-10-16 12:30 – Updated: 2025-10-22 19:36
VLAI
Summary
Strapi is vulnerable to Insufficient Session Expiration
Details

Strapi uses JSON Web Tokens (JWT) for authentication. After logout or account deactivation, the JWT is not invalidated, which allows an attacker who has stolen or intercepted the token to freely reuse it until its expiration date (which is set to 30 days by default, but can be changed). The existence of /admin/renew-token endpoint allows anyone to renew near-expiration tokens indefinitely, further increasing the impact of this attack. This issue has been fixed in version 5.24.1.

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@strapi/strapi"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.24.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-3930"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-16T21:21:44Z",
    "nvd_published_at": "2025-10-16T11:15:29Z",
    "severity": "MODERATE"
  },
  "details": "Strapi uses JSON Web Tokens (JWT) for authentication. After logout or account deactivation, the JWT is not invalidated, which allows an attacker who has stolen or intercepted the token to freely reuse it until its expiration date (which is set to 30 days by default, but can be changed). The existence of /admin/renew-token\u00a0endpoint allows anyone to renew near-expiration tokens indefinitely, further increasing the impact of this attack. This issue has been fixed in version 5.24.1.",
  "id": "GHSA-4r8w-3jww-m2rp",
  "modified": "2025-10-22T19:36:22Z",
  "published": "2025-10-16T12:30:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-3930"
    },
    {
      "type": "WEB",
      "url": "https://cert.pl/en/posts/2025/06/CVE-2025-3930"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/strapi/strapi"
    },
    {
      "type": "WEB",
      "url": "https://strapi.io"
    },
    {
      "type": "WEB",
      "url": "https://strapi.io/blog/security-disclosure-of-vulnerabilities-cve-October-2025"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:L/VI:L/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Strapi is vulnerable to Insufficient Session Expiration"
}

GHSA-4RP7-5W2X-WWVH

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

IBM Aspera Shares 1.9.9 through 1.11.0 does not invalidate session after a password reset which could allow an authenticated user to impersonate another user on the system.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-66483"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-01T23:17:01Z",
    "severity": "MODERATE"
  },
  "details": "IBM Aspera Shares 1.9.9 through 1.11.0 does not invalidate session after a password reset which could allow an authenticated user to impersonate another user on the system.",
  "id": "GHSA-4rp7-5w2x-wwvh",
  "modified": "2026-04-02T00:31:04Z",
  "published": "2026-04-02T00:31:04Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-66483"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7267848"
    }
  ],
  "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"
    }
  ]
}

GHSA-4VXV-4XQ4-P84H

Vulnerability from github – Published: 2026-04-01 22:08 – Updated: 2026-04-06 17:15
VLAI
Summary
CI4MS: Account Deletion Module Grants Full Persistent Unauthorized Access for All‑Roles via Improper Session Invalidation (Logic Flaw)
Details

Summary

Vulnerability: Improper Session Invalidation on Account Deletion (Broken Access Control / Logic Flaw)

  • This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deleted. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.

Description

The application fails to immediately revoke active user sessions when an account is deleted. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.

The system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deleted accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.

Affected Functionality

  • User session management and authentication logic
  • Account deletion mechanism
  • All authenticated endpoints, including administrative and content interfaces

Attack Scenario

  • A user logs into the application.
  • An administrator deletes the user account.
  • The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.
  • The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.
  • Access is only lost if the user manually logs out, which may never occur.

Impact

  • Unauthorized Continued Access: Deleted users retain full access indefinitely, violating intended access control and expected security behavior.
  • Bypass of Administrative Controls: Administrative actions (deletion) fail to immediately restrict active sessions.
  • Logic Flaw Resulting in Broken Behavior: Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.
  • Full Functional Access Retained: Deleted users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before deletion.
  • Privilege Abuse: Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deletion, including accessing user management interfaces and modifying application state.
  • Service Disruption Potential: Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.
  • Attack Persistence: Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.
  • False Sense of Remediation: Administrators may believe a threat has been mitigated while the deleted user remains active within the system.

Endpoint Example: Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.

Steps To Reproduce (PoC)

  1. Create or use an existing user account.
  2. Log into the application using this account.
  3. From an administrative account, delete the logged-in user account.
  4. Observe that the target user remains authenticated.
  5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.
  6. Confirm that the user only loses access after manually logging out (if they choose to do so).

Remediation

  • Immediately invalidate all active sessions when an account is deleted.
  • Enforce account status checks on every authenticated request, not only during login.
  • Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.
  • Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.

Ready Video POC:

https://mega.nz/file/7dlUTQAB#0oXOapF5XYN4DRRG1xYj6DajmuP72MpMdsHqbVBMmWw

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.28.6.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "ci4-cms-erp/ci4ms"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.31.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34570"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1254",
      "CWE-284",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-01T22:08:29Z",
    "nvd_published_at": "2026-04-01T22:16:20Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n### Vulnerability: Improper Session Invalidation on Account Deletion (Broken Access Control / Logic Flaw)\n- This vulnerability is caused by a backend logic flaw that maintains a false trust assumption that already-authenticated users remain trustworthy, even after their accounts are explicitly deleted. As a result, administrative security actions do not behave as intended, allowing persistent unauthorized access.\n\n### Description\nThe application fails to immediately revoke active user sessions when an account is **deleted**. Due to a logic flaw in the backend design, account state changes are enforced only during authentication (login), not for already-established sessions.\n\nThe system implicitly assumes that authenticated users remain trusted for the lifetime of their session. There is no session expiration or account expiration mechanism in place, causing deleted accounts to retain indefinite access until the user manually logs out. This behavior breaks the intended access control policy and results in persistent unauthorized access, representing a critical security flaw.\n\n### Affected Functionality\n- User session management and authentication logic\n- Account **deletion** mechanism\n- All authenticated endpoints, including administrative and content interfaces\n\n### Attack Scenario\n- A user logs into the application.\n- An administrator **deletes** the user account.\n- The user remains fully logged in and can continue performing all actions allowed by their role indefinitely, as there is no session expiration.\n- The user can continue invoking backend methods, triggering application actions, accessing sensitive interfaces (including user management if permitted), and interacting with the system as if the account were still active.\n- Access is only lost if the user manually logs out, which may never occur.\n\n### Impact\n- **Unauthorized Continued Access:** Deleted users retain full access indefinitely, violating intended access control and expected security behavior.\n- **Bypass of Administrative Controls:** Administrative actions (**deletion**) fail to immediately restrict active sessions.\n- **Logic Flaw Resulting in Broken Behavior:** Backend authorization logic relies on a flawed trust assumption that authenticated users remain valid, enforcing account state only at login.\n- **Full Functional Access Retained:** Deleted users can continue invoking application methods, executing actions, interacting with protected endpoints, and using the system exactly as before deletion.\n- **Privilege Abuse:** Users with elevated roles (moderator, editor, administrator) can continue performing privileged actions after account deletion, including accessing user management interfaces and modifying application state.\n- **Service Disruption Potential:** Persistent access allows attackers to disrupt services, manipulate content, or interfere with normal application operations.\n- **Attack Persistence:** Attackers can maintain access indefinitely, increasing the risk of data exfiltration, unauthorized modifications, or further privilege escalation.\n- **False Sense of Remediation:** Administrators may believe a threat has been mitigated while the deleted user remains active within the system.\n\n**Endpoint Example:** Any endpoint accessible to authenticated users, including dashboards, administrative interfaces, user management pages, and API endpoints.\n\n## Steps To Reproduce (PoC)\n1. Create or use an existing user account.\n2. Log into the application using this account.\n3. From an administrative account, **delete** the logged-in user account.\n4. Observe that the target user remains authenticated.\n5. Verify that the user can still access protected functionality, invoke actions, and interact with the application as before.\n6. Confirm that the user only loses access after manually logging out (if they choose to do so).\n\n## Remediation\n- Immediately invalidate all active sessions when an account is **deleted**.\n- Enforce account status checks on every authenticated request, not only during login.\n- Introduce proper session expiration or account expiration mechanisms to prevent indefinite access.\n- Correct the backend logic flaw to ensure access control behavior aligns with intended security design and does not rely on unsafe trust assumptions.\n\n# Ready Video POC:\nhttps://mega.nz/file/7dlUTQAB#0oXOapF5XYN4DRRG1xYj6DajmuP72MpMdsHqbVBMmWw",
  "id": "GHSA-4vxv-4xq4-p84h",
  "modified": "2026-04-06T17:15:26Z",
  "published": "2026-04-01T22:08:29Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/security/advisories/GHSA-4vxv-4xq4-p84h"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34570"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/ci4-cms-erp/ci4ms"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ci4-cms-erp/ci4ms/releases/tag/0.31.0.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "CI4MS: Account Deletion Module Grants Full Persistent Unauthorized Access for All\u2011Roles via Improper Session Invalidation (Logic Flaw)"
}

GHSA-4W59-C3GC-RRHP

Vulnerability from github – Published: 2023-02-28 23:20 – Updated: 2024-11-18 23:10
VLAI
Summary
vantage6 refresh tokens do not expire
Details

From issue:

Problem description Currently, the refresh token is valid indefinitely. This is bad security practice.

Desired solution The refresh token should get a validity of 24-48 hours.

Additional context

When implementing this, also check that the refresh token returns a new refresh token When implementing this, also adapt the UI so that it logs out if refresh token is no longer valid. When implementing this, ensure that nodes refresh their token periodically so that they do not have to be restarted manually.

Impact

Patches

None available

Workarounds

None available

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "vantage6"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.8.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-23929"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-02-28T23:20:05Z",
    "nvd_published_at": "2023-03-04T00:15:00Z",
    "severity": "HIGH"
  },
  "details": "From issue: \n\nProblem description\nCurrently, the refresh token is valid indefinitely. This is bad security practice.\n\nDesired solution\nThe refresh token should get a validity of 24-48 hours.\n\nAdditional context\n\nWhen implementing this, also check that the refresh token returns a new refresh token\nWhen implementing this, also adapt the UI so that it logs out if refresh token is no longer valid.\nWhen implementing this, ensure that nodes refresh their token periodically so that they do not have to be restarted manually.\n\n\n### Impact\n### Patches\nNone available \n\n### Workarounds\nNone available\n\n",
  "id": "GHSA-4w59-c3gc-rrhp",
  "modified": "2024-11-18T23:10:57Z",
  "published": "2023-02-28T23:20:05Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/vantage6/vantage6/security/advisories/GHSA-4w59-c3gc-rrhp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-23929"
    },
    {
      "type": "WEB",
      "url": "https://github.com/vantage6/vantage6/commit/48ebfca42359e9a6743e9598684585e2522cdce8"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/vantage6/PYSEC-2023-54.yaml"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/vantage6/vantage6"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "vantage6 refresh tokens do not expire"
}

GHSA-4W5X-HQJJ-CRCV

Vulnerability from github – Published: 2026-09-15 03:30 – Updated: 2026-09-15 03:30
VLAI
Details

Insufficient session expiration vulnerability in bizwell xClick allows Authentication Bypass.

This issue affects xClick: R2, R3, and R3.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-88262"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T03:17:06Z",
    "severity": "HIGH"
  },
  "details": "Insufficient session expiration vulnerability in bizwell xClick allows Authentication Bypass.\n\nThis issue affects xClick: R2, R3, and R3.1.",
  "id": "GHSA-4w5x-hqjj-crcv",
  "modified": "2026-09-15T03:30:30Z",
  "published": "2026-09-15T03:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-88262"
    },
    {
      "type": "WEB",
      "url": "https://www.bizwell.net/solutions/groupware"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/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-4W9H-QQ4C-69WP

Vulnerability from github – Published: 2025-12-04 21:31 – Updated: 2025-12-08 18:30
VLAI
Details

A vulnerability has been identified in Genexis Platinum P4410 router (Firmware P4410-V2–1.41) that allows a local network attacker to achieve Remote Code Execution (RCE) with root privileges. The issue occurs due to improper session invalidation after administrator logout. When an administrator logs out, the session token remains valid. An attacker on the local network can reuse this stale token to send crafted requests via the router’s diagnostic endpoint, resulting in command execution as root.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-65883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-04T20:16:19Z",
    "severity": "HIGH"
  },
  "details": "A vulnerability has been identified in Genexis Platinum P4410 router (Firmware P4410-V2\u20131.41) that allows a local network attacker to achieve Remote Code Execution (RCE) with root privileges. The issue occurs due to improper session invalidation after administrator logout. When an administrator logs out, the session token remains valid. An attacker on the local network can reuse this stale token to send crafted requests via the router\u2019s diagnostic endpoint, resulting in command execution as root.",
  "id": "GHSA-4w9h-qq4c-69wp",
  "modified": "2025-12-08T18:30:26Z",
  "published": "2025-12-04T21:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-65883"
    },
    {
      "type": "WEB",
      "url": "https://0xw41th.medium.com/my-first-cve-cve-2025-65883-remote-code-execution-in-a-genexis-router-0c35749a99bd"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4X2H-WCJQ-P974

Vulnerability from github – Published: 2026-08-05 18:31 – Updated: 2026-08-05 18:31
VLAI
Details

Flarum before 1.8.16 contains an improper session invalidation vulnerability that allows attackers who hold a valid session token to retain full account access after a victim changes their password, because the access_tokens table is never cleared on password change events. The TokensClearer::clearPasswordTokens() function only removes rows from the password_tokens table while leaving all active session cookies and API bearer tokens intact, including long-lived RememberAccessToken entries, and administrator-forced password resets via the user update endpoint are equally ineffective at revoking attacker-held sessions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-39924"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-05T16:16:56Z",
    "severity": "HIGH"
  },
  "details": "Flarum before 1.8.16 contains an improper session invalidation vulnerability that allows attackers who hold a valid session token to retain full account access after a victim changes their password, because the access_tokens table is never cleared on password change events. The TokensClearer::clearPasswordTokens() function only removes rows from the password_tokens table while leaving all active session cookies and API bearer tokens intact, including long-lived RememberAccessToken entries, and administrator-forced password resets via the user update endpoint are equally ineffective at revoking attacker-held sessions.",
  "id": "GHSA-4x2h-wcjq-p974",
  "modified": "2026-08-05T18:31:35Z",
  "published": "2026-08-05T18:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39924"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/pull/4546"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/commit/5f080293a029d0d273eb9678d597c74ea86a3bcc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/flarum/framework/releases/tag/v1.8.16"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/flarum-session-persistence-via-improper-access-token-revocation"
    }
  ],
  "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:H/AT:N/PR:L/UI:N/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"
    }
  ]
}

Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.