CWE-613
Allowed-with-ReviewInsufficient 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."
1017 vulnerabilities reference this CWE, most recent first.
GHSA-W8W3-M5JX-QWWR
Vulnerability from github – Published: 2022-05-14 03:20 – Updated: 2022-05-14 03:20A denial of service vulnerability exists in Schneider Electric's MiCOM Px4x (P540 range excluded) with legacy Ethernet board, MiCOM P540D Range with Legacy Ethernet Board, and MiCOM Px4x Rejuvenated could lose network communication in case of TCP/IP open requests on port 20000 (DNP3oE) if an older TCI/IP session is still open with identical IP address and port number.
{
"affected": [],
"aliases": [
"CVE-2018-7758"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-04-18T20:29:00Z",
"severity": "MODERATE"
},
"details": "A denial of service vulnerability exists in Schneider Electric\u0027s MiCOM Px4x (P540 range excluded) with legacy Ethernet board, MiCOM P540D Range with Legacy Ethernet Board, and MiCOM Px4x Rejuvenated could lose network communication in case of TCP/IP open requests on port 20000 (DNP3oE) if an older TCI/IP session is still open with identical IP address and port number.",
"id": "GHSA-w8w3-m5jx-qwwr",
"modified": "2022-05-14T03:20:49Z",
"published": "2022-05-14T03:20:49Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2018-7758"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2018-074-02"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2018-074-03"
},
{
"type": "WEB",
"url": "https://www.schneider-electric.com/en/download/document/SEVD-2018-074-04"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W9G9-CC2C-QXCQ
Vulnerability from github – Published: 2022-05-24 17:30 – Updated: 2022-05-24 17:30IBM Security Access Manager Appliance 9.0.7 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 179358.
{
"affected": [],
"aliases": [
"CVE-2020-4395"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-10-14T17:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Security Access Manager Appliance 9.0.7 does not invalidate session after logout which could allow an authenticated user to impersonate another user on the system. IBM X-Force ID: 179358.",
"id": "GHSA-w9g9-cc2c-qxcq",
"modified": "2022-05-24T17:30:40Z",
"published": "2022-05-24T17:30:40Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4395"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/179358"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6347592"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WFGV-4XH4-MFF6
Vulnerability from github – Published: 2023-02-20 18:30 – Updated: 2023-03-06 21:30Expired sessions were not securely terminated in the RestAPI for Tribe29's Checkmk <= 2.1.0p10 and Checkmk <= 2.0.0p28 allowing an attacker to use expired session tokens when communicating with the RestAPI.
{
"affected": [],
"aliases": [
"CVE-2022-48317"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-02-20T17:15:00Z",
"severity": "CRITICAL"
},
"details": "Expired sessions were not securely terminated in the RestAPI for Tribe29\u0027s Checkmk \u003c= 2.1.0p10 and Checkmk \u003c= 2.0.0p28 allowing an attacker to use expired session tokens when communicating with the RestAPI.",
"id": "GHSA-wfgv-4xh4-mff6",
"modified": "2023-03-06T21:30:19Z",
"published": "2023-02-20T18:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-48317"
},
{
"type": "WEB",
"url": "https://checkmk.com/werk/14485"
}
],
"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"
}
]
}
GHSA-WHGG-X7CG-V7R9
Vulnerability from github – Published: 2022-05-24 17:41 – Updated: 2022-05-24 17:41IBM Security Identity Governance and Intelligence 5.2.6 does not invalidate session after logout which could allow a user to obtain sensitive information from another users' session. IBM X-Force ID: 192912.
{
"affected": [],
"aliases": [
"CVE-2020-4995"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-02-09T15:15:00Z",
"severity": "MODERATE"
},
"details": "IBM Security Identity Governance and Intelligence 5.2.6 does not invalidate session after logout which could allow a user to obtain sensitive information from another users\u0027 session. IBM X-Force ID: 192912.",
"id": "GHSA-whgg-x7cg-v7r9",
"modified": "2022-05-24T17:41:31Z",
"published": "2022-05-24T17:41:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-4995"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/192912"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6413393"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-WHQG-8C4F-4GWX
Vulnerability from github – Published: 2024-07-25 18:32 – Updated: 2024-07-25 18:32IBM Security Directory Integrator 7.2.0 and IBM Security Verify Directory Integrator 10.0.0 uses insufficient session expiration which could allow an unauthorized user to obtain sensitive information. IBM X-Force ID: 228565.
{
"affected": [],
"aliases": [
"CVE-2022-32759"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-25T18:15:02Z",
"severity": "MODERATE"
},
"details": "IBM Security Directory Integrator 7.2.0 and IBM Security Verify Directory Integrator 10.0.0 uses insufficient session expiration which could allow an unauthorized user to obtain sensitive information. IBM X-Force ID: 228565.",
"id": "GHSA-whqg-8c4f-4gwx",
"modified": "2024-07-25T18:32:36Z",
"published": "2024-07-25T18:32:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-32759"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/228565"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7161446"
}
],
"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"
}
]
}
GHSA-WJWR-XFP9-R66P
Vulnerability from github – Published: 2026-09-10 22:41 – Updated: 2026-09-10 22:41Summary
A user who is demoted from admin by an identity provider keeps admin-level read and write access to every user's notes, over any Socket.IO connection that was already open when the demotion happened. Open WebUI caches the user's role on the socket at connection time, and the two SSO role-sync paths, the reverse-proxy trusted role header and OAuth role mapping, changed the role in the database without tearing that cached session down. Only the admin user-management endpoints invalidated sessions, so a demotion driven by the identity provider left the old privileges live on the socket.
Preconditions
A role-sync SSO mode has to be enabled. Either trusted-header authentication with WEBUI_AUTH_TRUSTED_ROLE_HEADER set, which is unset by default, or OAuth with role mapping enabled, which is off by default. Deployments that change roles only through the admin panel are not affected, because that path already invalidated the user's sockets.
The account has to be an admin at the moment it opens a Socket.IO connection, has to keep that connection open across the demotion, and has to be demoted through the SSO path rather than through the admin panel. Signing out, reloading the page, or any network interruption ends the exposure, because the reconnect reads a fresh role from the database.
Impact
Until the socket closes, the demoted account can open and edit any user's note through the collaborative-notes socket handlers, which grant admins access to every note. That is read and write access to other users' private notes, held by someone the operator has already removed from the admin role.
The rest of the product is not affected. Every HTTP endpoint reads the role fresh from the database on each request, so the demoted account has no admin access to the REST API, no user management, no settings and no model or connection configuration. The exposure ends the moment the connection drops, and the account controls that only by keeping the browser tab open.
The realistic case is off-boarding or a least-privilege downgrade performed in the identity provider, which is a normal administrative action rather than a misconfiguration.
Fix
Fixed in 0.11.1 by commit ce3c175e260709f359d7e6cbb3132f0572098b95. Role changes and user deletions now publish an internal event, and a session handler tears down that user's Socket.IO connections whenever the event fires, so every path that can change a role invalidates cached sessions instead of only the admin endpoints. Upgrading is sufficient, no configuration change is needed.
Root cause
Affected components:
backend/open_webui/routers/auths.py, the trusted-header role sync in the sign-in handler.backend/open_webui/utils/oauth.py, the OAuth role sync run on login.backend/open_webui/socket/main.py, which caches the user record on the socket and authorizes the collaborative-notes handlers against that cached copy.
Session invalidation on role change was added as an explicit call, made at the call sites that changed a role rather than inside the role-change itself. The admin user-management endpoints made that call, the two SSO sync paths did not, and nothing else refreshed the role cached on an open socket. The socket keep-alive rewrites the cached record to reset the idle timer and preserves the stale role while doing so, so a connection that stays active is never reaped. Because the notes handlers grant full access to any note when the cached role reads admin, the gap turned into read and write access over all notes for as long as the connection lived.
Proof of concept
Deploy Open WebUI with trusted-header authentication and WEBUI_AUTH_TRUSTED_ROLE_HEADER set, or with OAuth role mapping enabled. Sign in as an admin and leave the browser open on a page holding a Socket.IO connection. Demote the account through the identity provider, meaning the next sign-in carries the role header set to user, or the account's group is changed at the OAuth provider. The database role is now user.
Over the connection that is still open, join and edit another user's note by its id. Both are granted, because the role cached on that socket still reads admin. Performing the same demotion through the admin panel instead drops the connection and revokes the access, which is the behaviour the SSO paths were missing.
This was established by source inspection against 0.11.0 rather than by an executed exploit.
Credits
Reported by @mtholmquist.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "open-webui"
},
"ranges": [
{
"events": [
{
"introduced": "0.9.0"
},
{
"fixed": "0.11.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-87014"
],
"database_specific": {
"cwe_ids": [
"CWE-613",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-10T22:41:34Z",
"nvd_published_at": "2026-09-09T21:17:06Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA user who is demoted from admin by an identity provider keeps admin-level read and write access to every user\u0027s notes, over any Socket.IO connection that was already open when the demotion happened. Open WebUI caches the user\u0027s role on the socket at connection time, and the two SSO role-sync paths, the reverse-proxy trusted role header and OAuth role mapping, changed the role in the database without tearing that cached session down. Only the admin user-management endpoints invalidated sessions, so a demotion driven by the identity provider left the old privileges live on the socket.\n\n## Preconditions\n\nA role-sync SSO mode has to be enabled. Either trusted-header authentication with `WEBUI_AUTH_TRUSTED_ROLE_HEADER` set, which is unset by default, or OAuth with role mapping enabled, which is off by default. Deployments that change roles only through the admin panel are not affected, because that path already invalidated the user\u0027s sockets.\n\nThe account has to be an admin at the moment it opens a Socket.IO connection, has to keep that connection open across the demotion, and has to be demoted through the SSO path rather than through the admin panel. Signing out, reloading the page, or any network interruption ends the exposure, because the reconnect reads a fresh role from the database.\n\n## Impact\n\nUntil the socket closes, the demoted account can open and edit any user\u0027s note through the collaborative-notes socket handlers, which grant admins access to every note. That is read and write access to other users\u0027 private notes, held by someone the operator has already removed from the admin role.\n\nThe rest of the product is not affected. Every HTTP endpoint reads the role fresh from the database on each request, so the demoted account has no admin access to the REST API, no user management, no settings and no model or connection configuration. The exposure ends the moment the connection drops, and the account controls that only by keeping the browser tab open.\n\nThe realistic case is off-boarding or a least-privilege downgrade performed in the identity provider, which is a normal administrative action rather than a misconfiguration.\n\n## Fix\n\nFixed in 0.11.1 by commit `ce3c175e260709f359d7e6cbb3132f0572098b95`. Role changes and user deletions now publish an internal event, and a session handler tears down that user\u0027s Socket.IO connections whenever the event fires, so every path that can change a role invalidates cached sessions instead of only the admin endpoints. Upgrading is sufficient, no configuration change is needed.\n\n## Root cause\n\nAffected components:\n\n- `backend/open_webui/routers/auths.py`, the trusted-header role sync in the sign-in handler.\n- `backend/open_webui/utils/oauth.py`, the OAuth role sync run on login.\n- `backend/open_webui/socket/main.py`, which caches the user record on the socket and authorizes the collaborative-notes handlers against that cached copy.\n\nSession invalidation on role change was added as an explicit call, made at the call sites that changed a role rather than inside the role-change itself. The admin user-management endpoints made that call, the two SSO sync paths did not, and nothing else refreshed the role cached on an open socket. The socket keep-alive rewrites the cached record to reset the idle timer and preserves the stale role while doing so, so a connection that stays active is never reaped. Because the notes handlers grant full access to any note when the cached role reads admin, the gap turned into read and write access over all notes for as long as the connection lived.\n\n## Proof of concept\n\nDeploy Open WebUI with trusted-header authentication and `WEBUI_AUTH_TRUSTED_ROLE_HEADER` set, or with OAuth role mapping enabled. Sign in as an admin and leave the browser open on a page holding a Socket.IO connection. Demote the account through the identity provider, meaning the next sign-in carries the role header set to `user`, or the account\u0027s group is changed at the OAuth provider. The database role is now `user`.\n\nOver the connection that is still open, join and edit another user\u0027s note by its id. Both are granted, because the role cached on that socket still reads admin. Performing the same demotion through the admin panel instead drops the connection and revokes the access, which is the behaviour the SSO paths were missing.\n\nThis was established by source inspection against 0.11.0 rather than by an executed exploit.\n\n## Credits\n\nReported by @mtholmquist.",
"id": "GHSA-wjwr-xfp9-r66p",
"modified": "2026-09-10T22:41:34Z",
"published": "2026-09-10T22:41:34Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-wjwr-xfp9-r66p"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-87014"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/commit/ce3c175e260709f359d7e6cbb3132f0572098b95"
},
{
"type": "PACKAGE",
"url": "https://github.com/open-webui/open-webui"
},
{
"type": "WEB",
"url": "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Open WebUI: Admin demoted through SSO role sync keeps read and write access to all users\u0027 notes"
}
GHSA-WMM3-H9QJ-P5V6
Vulnerability from github – Published: 2026-05-12 22:23 – Updated: 2026-06-09 10:32Summary
Changing a user’s password does not invalidate existing sessions, allowing an attacker with a stolen cookie to retain access even after the victim resets their password.
Details
SillyTavern relies on cookie-session for authentication, storing all session data (user handle, permissions) in a signed cookie. The endpoints POST /api/users/change-password and POST /api/users/recover-step2 only update the password hash in the database but do not expire current sessions. Because the session is stateless and stored entirely in the client cookie, there is no server-side mechanism to revoke a token once issued.
PoC
1.Log into the same SillyTavern account from two different browsers (e.g., Chrome and Firefox private mode). 2.In Chrome, change the account password under User Settings → Change Password. 3.In Firefox, refresh the page or perform a protected action (e.g., view API keys). 4.Expected: Firefox session should be invalidated and ask for login. 5.Actual: Firefox remains fully authenticated, able to perform all actions as the targeted user.
Impact
An attacker who obtains a valid session cookie (via XSS, MITM, physical access, etc.) can continue using it indefinitely, even after the legitimate user changes their password. This nullifies the most common recovery measure against session theft. The default cookie lifespan is 400 days, giving an attacker a very long exploitation window.
Resolution
A fix was released in the version 1.18.0, invalidating a session cookie on account password change.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.17.0"
},
"package": {
"ecosystem": "npm",
"name": "sillytavern"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.18.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-44648"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-05-12T22:23:20Z",
"nvd_published_at": "2026-05-29T19:16:24Z",
"severity": "HIGH"
},
"details": "### Summary\nChanging a user\u2019s password does not invalidate existing sessions, allowing an attacker with a stolen cookie to retain access even after the victim resets their password.\n\n### Details\nSillyTavern relies on cookie-session for authentication, storing all session data (user handle, permissions) in a signed cookie. The endpoints POST /api/users/change-password and POST /api/users/recover-step2 only update the password hash in the database but do not expire current sessions. Because the session is stateless and stored entirely in the client cookie, there is no server-side mechanism to revoke a token once issued.\n\n### PoC\n1.Log into the same SillyTavern account from two different browsers (e.g., Chrome and Firefox private mode).\n2.In Chrome, change the account password under User Settings \u2192 Change Password.\n3.In Firefox, refresh the page or perform a protected action (e.g., view API keys).\n4.Expected: Firefox session should be invalidated and ask for login.\n5.Actual: Firefox remains fully authenticated, able to perform all actions as the targeted user.\n\n### Impact\nAn attacker who obtains a valid session cookie (via XSS, MITM, physical access, etc.) can continue using it indefinitely, even after the legitimate user changes their password.\nThis nullifies the most common recovery measure against session theft.\nThe default cookie lifespan is 400 days, giving an attacker a very long exploitation window.\n\n### Resolution\nA fix was released in the version 1.18.0, invalidating a session cookie on account password change.",
"id": "GHSA-wmm3-h9qj-p5v6",
"modified": "2026-06-09T10:32:03Z",
"published": "2026-05-12T22:23:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/SillyTavern/SillyTavern/security/advisories/GHSA-wmm3-h9qj-p5v6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-44648"
},
{
"type": "PACKAGE",
"url": "https://github.com/SillyTavern/SillyTavern"
},
{
"type": "WEB",
"url": "https://github.com/SillyTavern/SillyTavern/releases/tag/1.18.0"
}
],
"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:H",
"type": "CVSS_V3"
}
],
"summary": "SillyTavern: Existing sessions are not invalidated after password change, allowing session reuse and account takeover"
}
GHSA-WMM5-59WM-X34P
Vulnerability from github – Published: 2025-05-13 12:31 – Updated: 2025-05-13 12:31A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions < V4.1 Update 3), SIMATIC PCS neo V5.0 (All versions < V5.0 Update 1). Affected products do not correctly invalidate user sessions upon user logout. This could allow a remote unauthenticated attacker, who has obtained the session token by other means, to re-use a legitimate user's session even after logout.
{
"affected": [],
"aliases": [
"CVE-2025-40566"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-05-13T10:15:26Z",
"severity": "HIGH"
},
"details": "A vulnerability has been identified in SIMATIC PCS neo V4.1 (All versions \u003c V4.1 Update 3), SIMATIC PCS neo V5.0 (All versions \u003c V5.0 Update 1). Affected products do not correctly invalidate user sessions upon user logout. This could allow a remote unauthenticated attacker, who has obtained the session token by other means, to re-use a legitimate user\u0027s session even after logout.",
"id": "GHSA-wmm5-59wm-x34p",
"modified": "2025-05-13T12:31:36Z",
"published": "2025-05-13T12:31:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-40566"
},
{
"type": "WEB",
"url": "https://cert-portal.siemens.com/productcert/html/ssa-339086.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/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: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-WRMQ-9FC4-GWWJ
Vulnerability from github – Published: 2026-06-16 21:31 – Updated: 2026-06-18 13:03Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-q99w-vh6v-q3v7. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.5.26 contains an authorization bypass vulnerability where a surviving pairing-scoped device session can re-establish node token authority after revocation. Attackers with a paired device can regain WebSocket node-level access without renewed approval, weakening revocation controls and maintaining unauthorized access longer than intended.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c 2026.5.26"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-18T13:03:03Z",
"nvd_published_at": "2026-06-16T19:17:01Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-q99w-vh6v-q3v7. This link is maintained to preserve external references.\n\n## Original Description\nOpenClaw before 2026.5.26 contains an authorization bypass vulnerability where a surviving pairing-scoped device session can re-establish node token authority after revocation. Attackers with a paired device can regain WebSocket node-level access without renewed approval, weakening revocation controls and maintaining unauthorized access longer than intended.",
"id": "GHSA-wrmq-9fc4-gwwj",
"modified": "2026-06-18T13:03:03Z",
"published": "2026-06-16T21:31:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-q99w-vh6v-q3v7"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53843"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-node-token-revocation-bypass-via-pairing-scoped-device-session"
}
],
"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/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"
}
],
"summary": "Duplicate Advisory: Pairing-scoped device session could restore revoked node token authority",
"withdrawn": "2026-06-18T13:03:03Z"
}
GHSA-WRVX-PXXF-G8FG
Vulnerability from github – Published: 2026-08-26 00:30 – Updated: 2026-08-26 21:31Insufficient Session Expiration vulnerability in Apache Tomcat meant that if the session ID for an authenticated HTTP session was changed after a WebSocket connection had been established under that authenticated HTTP session, the WebSokcet session would not be closed as required by the Jakarta WebSocket specification when the HTTP session ended.
This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120.
The following versions were EOL at the time the CVE was created but are known to be affected: from 8.5.0 through 8.5.100, from 7.0.43 through 7.0.109. Other unsupported versions may also be affected.
Users are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue.
{
"affected": [],
"aliases": [
"CVE-2026-73180"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-25T22:17:06Z",
"severity": "MODERATE"
},
"details": "Insufficient Session Expiration vulnerability in Apache Tomcat meant that if the session ID for an authenticated HTTP session was changed after a WebSocket connection had been established under that authenticated HTTP session, the WebSokcet session would not be closed as required by the Jakarta WebSocket specification when the HTTP session ended.\n\n\n\nThis issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.24, from 10.1.0-M1 through 10.1.57, from 9.0.0.M1 through 9.0.120.\n\n\n\nThe following versions were EOL at the time the CVE was created but are \nknown to be affected: from 8.5.0 through 8.5.100, from 7.0.43 through 7.0.109.\u00a0Other unsupported versions may also be affected.\n\n\n\nUsers are recommended to upgrade to version 11.0.25, 10.1.58 or 9.0.121, which fix the issue.",
"id": "GHSA-wrvx-pxxf-g8fg",
"modified": "2026-08-26T21:31:39Z",
"published": "2026-08-26T00:30:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-73180"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/3j15vztszpyqss253mjq5v1kp7s6hooq"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/08/26/10"
}
],
"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"
}
]
}
Mitigation
Set sessions/credentials expiration date.
No CAPEC attack patterns related to this CWE.