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."
957 vulnerabilities reference this CWE, most recent first.
GHSA-25XC-R4X7-G46H
Vulnerability from github – Published: 2022-11-22 03:30 – Updated: 2025-04-29 18:30Fusiondirectory 1.3 suffers from Improper Session Handling.
{
"affected": [],
"aliases": [
"CVE-2022-36179"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-22T01:15:00Z",
"severity": "CRITICAL"
},
"details": "Fusiondirectory 1.3 suffers from Improper Session Handling.",
"id": "GHSA-25xc-r4x7-g46h",
"modified": "2025-04-29T18:30:40Z",
"published": "2022-11-22T03:30:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-36179"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/07/msg00009.html"
},
{
"type": "WEB",
"url": "https://yoroi.company/research/cve-advisory-full-disclosure-multiple-vulnerabilities"
},
{
"type": "WEB",
"url": "http://fusiondirectory.com"
}
],
"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-26XR-J83G-4FMM
Vulnerability from github – Published: 2026-03-06 18:31 – Updated: 2026-05-05 21:31The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.
{
"affected": [],
"aliases": [
"CVE-2026-27764"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-03-06T16:16:11Z",
"severity": "MODERATE"
},
"details": "The WebSocket backend uses charging station identifiers to uniquely associate sessions but allows multiple endpoints to connect using the same session identifier. This implementation results in predictable session identifiers and enables session hijacking or shadowing, where the most recent connection displaces the legitimate charging station and receives backend commands intended for that station. This vulnerability may allow unauthorized users to authenticate as other users or enable\u00a0a malicious actor to cause a denial-of-service condition by overwhelming the backend with valid session requests.",
"id": "GHSA-26xr-j83g-4fmm",
"modified": "2026-05-05T21:31:15Z",
"published": "2026-03-06T18:31:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-27764"
},
{
"type": "WEB",
"url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-062-06.json"
},
{
"type": "WEB",
"url": "https://mobiliti.hu/emobilitas/ugyfeltamogatas/ugyfelszolgalat"
},
{
"type": "WEB",
"url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-062-06"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/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-275C-XPVC-JGFW
Vulnerability from github – Published: 2026-07-02 17:11 – Updated: 2026-08-24 21:06Summary
Slack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after secrets.reload.
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 deliver webhook events briefly after the operator expected 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.22.
Mitigations
restart the affected channel runtime after rotating webhook secrets 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.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2026.4.21"
},
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.4.22"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-53830"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-02T17:11:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\nSlack and Zalo webhook secrets could remain active after secrets.reload. In affected versions, a caller with an old webhook secret during the stale-secret window could keep accepting the previous secret after `secrets.reload`.\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 deliver webhook events briefly after the operator expected 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.22`.\n\n### Mitigations\n\nrestart the affected channel runtime after rotating webhook secrets 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-275c-xpvc-jgfw",
"modified": "2026-08-24T21:06:11Z",
"published": "2026-07-02T17:11:03Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-275c-xpvc-jgfw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53830"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-webhook-secret-revocation-bypass-via-secrets-reload"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "OpenClaw: Slack and Zalo webhook secrets could remain active after secrets.reload"
}
GHSA-289X-5MJ7-XHG5
Vulnerability from github – Published: 2026-06-26 00:32 – Updated: 2026-06-26 00:32Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.
{
"affected": [],
"aliases": [
"CVE-2025-71335"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-25T22:16:59Z",
"severity": "HIGH"
},
"details": "Flowise before 3.0.10 (affected versions 3.0.7 and earlier) fails to invalidate existing sessions and session tokens after a user changes their password. An attacker who already holds an active session, for example via a stolen session token or a device left logged in, remains authenticated as the legitimate user even after the user rotates their credentials, undermining the security purpose of the password change.",
"id": "GHSA-289x-5mj7-xhg5",
"modified": "2026-06-26T00:32:05Z",
"published": "2026-06-26T00:32:05Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x7rp-qj2h-ghgw"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71335"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/flowise-session-invalidation-failure-after-password-change"
}
],
"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:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/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"
}
]
}
GHSA-297V-QP46-84H5
Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-09 00:00NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the "ghost domain names" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound's delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.
{
"affected": [],
"aliases": [
"CVE-2022-30698"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-08-01T15:15:00Z",
"severity": "MODERATE"
},
"details": "NLnet Labs Unbound, up to and including version 1.16.1 is vulnerable to a novel type of the \"ghost domain names\" attack. The vulnerability works by targeting an Unbound instance. Unbound is queried for a subdomain of a rogue domain name. The rogue nameserver returns delegation information for the subdomain that updates Unbound\u0027s delegation cache. This action can be repeated before expiry of the delegation information by querying Unbound for a second level subdomain which the rogue nameserver provides new delegation information. Since Unbound is a child-centric resolver, the ever-updating child delegation information can keep a rogue domain name resolvable long after revocation. From version 1.16.2 on, Unbound checks the validity of parent delegation records before using cached delegation information.",
"id": "GHSA-297v-qp46-84h5",
"modified": "2022-08-09T00:00:27Z",
"published": "2022-08-02T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30698"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00024.html"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/5L3ZFWZZFPBIL654BG75RWXUMPFQJ5EC"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/D35CX4SCZVNKZTWJXPDFTHWZHINMGEZD"
},
{
"type": "WEB",
"url": "https://security.gentoo.org/glsa/202212-02"
},
{
"type": "WEB",
"url": "https://www.nlnetlabs.nl/downloads/unbound/CVE-2022-30698_CVE-2022-30699.txt"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-29FP-GVQM-7XX9
Vulnerability from github – Published: 2022-05-17 02:12 – Updated: 2025-04-20 03:33An issue was discovered in dnaTools dnaLIMS 4-2015s13. dnaLIMS is vulnerable to session hijacking by guessing the UID parameter.
{
"affected": [],
"aliases": [
"CVE-2017-6529"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-03-09T19:59:00Z",
"severity": "HIGH"
},
"details": "An issue was discovered in dnaTools dnaLIMS 4-2015s13. dnaLIMS is vulnerable to session hijacking by guessing the UID parameter.",
"id": "GHSA-29fp-gvqm-7xx9",
"modified": "2025-04-20T03:33:56Z",
"published": "2022-05-17T02:12:38Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6529"
},
{
"type": "WEB",
"url": "https://www.exploit-db.com/exploits/41578"
},
{
"type": "WEB",
"url": "https://www.shorebreaksecurity.com/blog/product-security-advisory-psa0002-dnalims"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/96823"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-2C5P-55QJ-5P58
Vulnerability from github – Published: 2022-01-29 00:00 – Updated: 2022-02-04 00:00A CWE-614 Insufficient Session Expiration vulnerability exists that could allow an attacker to maintain an unauthorized access over a hijacked session to the charger station web server even after the legitimate user account holder has changed his password. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)
{
"affected": [],
"aliases": [
"CVE-2021-22820"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-01-28T20:15:00Z",
"severity": "CRITICAL"
},
"details": "A CWE-614 Insufficient Session Expiration vulnerability exists that could allow an attacker to maintain an unauthorized access over a hijacked session to the charger station web server even after the legitimate user account holder has changed his password. Affected Products: EVlink City EVC1S22P4 / EVC1S7P4 (All versions prior to R8 V3.4.0.2 ), EVlink Parking EVW2 / EVF2 / EVP2PE (All versions prior to R8 V3.4.0.2), and EVlink Smart Wallbox EVB1A (All versions prior to R8 V3.4.0.2)",
"id": "GHSA-2c5p-55qj-5p58",
"modified": "2022-02-04T00:00:44Z",
"published": "2022-01-29T00:00:45Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22820"
},
{
"type": "WEB",
"url": "https://download.schneider-electric.com/files?p_Doc_Ref=SEVD-2021-348-02"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-2FPX-W7MW-JHXJ
Vulnerability from github – Published: 2026-09-11 00:31 – Updated: 2026-09-11 00:31IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute flows and obtain sensitive information due to insufficient session expiration of API keys after user deactivation.
{
"affected": [],
"aliases": [
"CVE-2026-81268"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-10T22:17:02Z",
"severity": "HIGH"
},
"details": "IBM Langflow OSS 1.0.0 through 1.11.5 could allow a remote authenticated attacker to execute flows and obtain sensitive information due to insufficient session expiration of API keys after user deactivation.",
"id": "GHSA-2fpx-w7mw-jhxj",
"modified": "2026-09-11T00:31:15Z",
"published": "2026-09-11T00:31:15Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-81268"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7286662"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-2MG4-PFGX-64CF
Vulnerability from github – Published: 2026-03-30 17:35 – Updated: 2026-03-30 17:35Summary
The verifyTokenSocket() function in plugin/YPTSocket/functions.php has its token timeout validation commented out, causing WebSocket tokens to never expire despite being generated with a 12-hour timeout. This allows captured or legitimately obtained tokens to provide permanent WebSocket access, even after user accounts are deleted, banned, or demoted from admin. Admin tokens grant access to real-time connection data for all online users including IP addresses, browser info, and page locations.
Details
WebSocket tokens are generated via getEncryptedInfo() which calls getToken(43200) to create a token with a 12-hour expiration window. The token is encrypted and contains security-critical claims: isAdmin, from_users_id, user_name, IP, browser, and device ID.
The regular HTTP token verification at objects/functions.php:3437-3439 enforces the timeout:
// objects/functions.php:3437-3439
if (!($time >= $obj->time && $time <= $obj->timeout)) {
_error_log("verifyToken token timout...");
return false; // <-- enforced
}
But the WebSocket-specific verification at plugin/YPTSocket/functions.php:65-82 has the enforcement commented out:
// plugin/YPTSocket/functions.php:77-80
if (!($time >= $obj->time && $time <= $obj->timeout)) {
//_error_log("verifyToken token timout...");
//return false; // <-- NOT enforced, always falls through to return true
}
return true;
Execution flow:
- Client connects to WebSocket with
?webSocketToken=TOKENin URL query onOpen()(Message.php:34) callsgetDecryptedInfo($wsocketGetVars['webSocketToken'])(line 48)getDecryptedInfo()(functions.php:49) decrypts the token and callsverifyTokenSocket($json->token)(line 54)verifyTokenSocket()validates the salt (passes) but the timeout check at line 77 evaluates the condition without acting on failure —return falseis commented out- Function returns
true— connection established with all token claims (isAdmin,from_users_id) trusted
Impact amplification via isAdmin:
When a connection has isAdmin=true (from token, Message.php:58), the getTotals() function (Message.php:419-432) includes detailed data about every connected client in periodic broadcast messages:
// Message.php:419-432
if ($isAdmin) {
$index = md5($client['selfURI']);
// Exposes: selfURI, yptDeviceId, users_id, user_name, browser, ip, location
$return['users_uri'][$index][$client['yptDeviceId']][$client['users_id']] = $client;
}
Additionally, the webSocketToken message type (Message.php:212-217) allows anonymous connections (users_id=0) to upgrade their identity by providing a captured token, meaning stolen tokens work from new connections indefinitely.
The 10-minute inactivity timeout (Message.php:135-143) is not a mitigation — it only closes idle connections and resets on every message (line 243).
PoC
# Step 1: Obtain a WebSocket token as any authenticated user
curl -s -b 'PHPSESSID=VALID_SESSION' \
'https://target.com/plugin/YPTSocket/getWebSocket.json.php' | jq -r '.webSocketToken'
# Save as TOKEN=<output>
# Step 2: Wait for the token to expire (>12 hours)
# In a real scenario, the attacker already has a previously captured token
# Step 3: Connect with the expired token — succeeds because verifyTokenSocket() skips timeout
wscat -c 'ws://target.com:8888/?webSocketToken=TOKEN'
# Step 4: Verify the connection is established and receiving broadcasts
# The server will send periodic getTotals data
# Step 5: If the token was from an admin, the getTotals response includes
# all connected clients' selfURI, IP, browser, device ID, user_name, and location
# Step 6: Any user can also enumerate connected users without admin:
# Send: {"msg":"getClientsList","webSocketToken":"TOKEN"}
# Response includes all users_id, isAdmin status, and usernames
Scenario: Demoted admin retains permanent admin WebSocket access
1. Admin user obtains WebSocket token (contains isAdmin: true)
2. Admin is demoted to regular user via the web interface
3. Admin's WebSocket token still works indefinitely — the isAdmin claim in the token is never re-validated
4. Demoted user continues receiving all connected users' IPs, locations, and browsing activity
Impact
- Permanent access after credential revocation: Deleted, banned, or suspended users retain WebSocket access with their original identity and privilege level, undermining account lifecycle management.
- Privilege persistence after demotion: Admin users who are demoted retain admin-level WebSocket access indefinitely. The
isAdminflag baked into the token is never re-checked against the database. - Real-time surveillance via admin tokens: Admin-level tokens expose all connected users' IP addresses, geographic locations (if User_location plugin enabled), current page URLs (selfURI), browser fingerprints, and device IDs — enabling real-time tracking of user activity.
- Extended attack window for token theft: Any vulnerability that leaks a WebSocket token (XSS, log exposure, network interception) provides permanent rather than 12-hour access, significantly increasing the impact of token compromise.
- Identity hijacking: The
webSocketTokenmessage type allows using a stolen token to assume another user's identity on new connections, enabling impersonation in chat and messaging.
Recommended Fix
Uncomment the timeout enforcement in verifyTokenSocket() at plugin/YPTSocket/functions.php:77-80:
function verifyTokenSocket($token) {
global $global;
$obj = _json_decode(decryptString($token));
if (empty($obj)) {
_error_log("verifyToken invalid token");
return false;
}
if ($obj->salt !== $global['salt']) {
_error_log("verifyToken salt fail");
return false;
}
$time = time();
if (!($time >= $obj->time && $time <= $obj->timeout)) {
_error_log("verifyToken token timeout time = $time; obj->time = $obj->time; obj->timeout = $obj->timeout");
return false; // <-- uncomment this line
}
return true;
}
Additionally, consider:
1. Adding an admin check to the getClientsList handler (Message.php:219) so only admins can enumerate connected users.
2. Re-validating the isAdmin claim against the database periodically rather than trusting the token claim for the lifetime of the connection.
{
"affected": [
{
"package": {
"ecosystem": "Packagist",
"name": "wwbn/avideo"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "26.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34362"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-30T17:35:21Z",
"nvd_published_at": "2026-03-27T17:16:30Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nThe `verifyTokenSocket()` function in `plugin/YPTSocket/functions.php` has its token timeout validation commented out, causing WebSocket tokens to never expire despite being generated with a 12-hour timeout. This allows captured or legitimately obtained tokens to provide permanent WebSocket access, even after user accounts are deleted, banned, or demoted from admin. Admin tokens grant access to real-time connection data for all online users including IP addresses, browser info, and page locations.\n\n## Details\n\nWebSocket tokens are generated via `getEncryptedInfo()` which calls `getToken(43200)` to create a token with a 12-hour expiration window. The token is encrypted and contains security-critical claims: `isAdmin`, `from_users_id`, `user_name`, IP, browser, and device ID.\n\nThe regular HTTP token verification at `objects/functions.php:3437-3439` enforces the timeout:\n\n```php\n// objects/functions.php:3437-3439\nif (!($time \u003e= $obj-\u003etime \u0026\u0026 $time \u003c= $obj-\u003etimeout)) {\n _error_log(\"verifyToken token timout...\");\n return false; // \u003c-- enforced\n}\n```\n\nBut the WebSocket-specific verification at `plugin/YPTSocket/functions.php:65-82` has the enforcement commented out:\n\n```php\n// plugin/YPTSocket/functions.php:77-80\nif (!($time \u003e= $obj-\u003etime \u0026\u0026 $time \u003c= $obj-\u003etimeout)) {\n //_error_log(\"verifyToken token timout...\");\n //return false; // \u003c-- NOT enforced, always falls through to return true\n}\nreturn true;\n```\n\n**Execution flow:**\n\n1. Client connects to WebSocket with `?webSocketToken=TOKEN` in URL query\n2. `onOpen()` (Message.php:34) calls `getDecryptedInfo($wsocketGetVars[\u0027webSocketToken\u0027])` (line 48)\n3. `getDecryptedInfo()` (functions.php:49) decrypts the token and calls `verifyTokenSocket($json-\u003etoken)` (line 54)\n4. `verifyTokenSocket()` validates the salt (passes) but the timeout check at line 77 evaluates the condition without acting on failure \u2014 `return false` is commented out\n5. Function returns `true` \u2014 connection established with all token claims (`isAdmin`, `from_users_id`) trusted\n\n**Impact amplification via isAdmin:**\n\nWhen a connection has `isAdmin=true` (from token, Message.php:58), the `getTotals()` function (Message.php:419-432) includes detailed data about every connected client in periodic broadcast messages:\n\n```php\n// Message.php:419-432\nif ($isAdmin) {\n $index = md5($client[\u0027selfURI\u0027]);\n // Exposes: selfURI, yptDeviceId, users_id, user_name, browser, ip, location\n $return[\u0027users_uri\u0027][$index][$client[\u0027yptDeviceId\u0027]][$client[\u0027users_id\u0027]] = $client;\n}\n```\n\nAdditionally, the `webSocketToken` message type (Message.php:212-217) allows anonymous connections (`users_id=0`) to upgrade their identity by providing a captured token, meaning stolen tokens work from new connections indefinitely.\n\nThe 10-minute inactivity timeout (Message.php:135-143) is not a mitigation \u2014 it only closes idle connections and resets on every message (line 243).\n\n## PoC\n\n```bash\n# Step 1: Obtain a WebSocket token as any authenticated user\ncurl -s -b \u0027PHPSESSID=VALID_SESSION\u0027 \\\n \u0027https://target.com/plugin/YPTSocket/getWebSocket.json.php\u0027 | jq -r \u0027.webSocketToken\u0027\n# Save as TOKEN=\u003coutput\u003e\n\n# Step 2: Wait for the token to expire (\u003e12 hours)\n# In a real scenario, the attacker already has a previously captured token\n\n# Step 3: Connect with the expired token \u2014 succeeds because verifyTokenSocket() skips timeout\nwscat -c \u0027ws://target.com:8888/?webSocketToken=TOKEN\u0027\n\n# Step 4: Verify the connection is established and receiving broadcasts\n# The server will send periodic getTotals data\n\n# Step 5: If the token was from an admin, the getTotals response includes\n# all connected clients\u0027 selfURI, IP, browser, device ID, user_name, and location\n\n# Step 6: Any user can also enumerate connected users without admin:\n# Send: {\"msg\":\"getClientsList\",\"webSocketToken\":\"TOKEN\"}\n# Response includes all users_id, isAdmin status, and usernames\n```\n\n**Scenario: Demoted admin retains permanent admin WebSocket access**\n1. Admin user obtains WebSocket token (contains `isAdmin: true`)\n2. Admin is demoted to regular user via the web interface\n3. Admin\u0027s WebSocket token still works indefinitely \u2014 the `isAdmin` claim in the token is never re-validated\n4. Demoted user continues receiving all connected users\u0027 IPs, locations, and browsing activity\n\n## Impact\n\n- **Permanent access after credential revocation:** Deleted, banned, or suspended users retain WebSocket access with their original identity and privilege level, undermining account lifecycle management.\n- **Privilege persistence after demotion:** Admin users who are demoted retain admin-level WebSocket access indefinitely. The `isAdmin` flag baked into the token is never re-checked against the database.\n- **Real-time surveillance via admin tokens:** Admin-level tokens expose all connected users\u0027 IP addresses, geographic locations (if User_location plugin enabled), current page URLs (selfURI), browser fingerprints, and device IDs \u2014 enabling real-time tracking of user activity.\n- **Extended attack window for token theft:** Any vulnerability that leaks a WebSocket token (XSS, log exposure, network interception) provides permanent rather than 12-hour access, significantly increasing the impact of token compromise.\n- **Identity hijacking:** The `webSocketToken` message type allows using a stolen token to assume another user\u0027s identity on new connections, enabling impersonation in chat and messaging.\n\n## Recommended Fix\n\nUncomment the timeout enforcement in `verifyTokenSocket()` at `plugin/YPTSocket/functions.php:77-80`:\n\n```php\nfunction verifyTokenSocket($token) {\n global $global;\n $obj = _json_decode(decryptString($token));\n if (empty($obj)) {\n _error_log(\"verifyToken invalid token\");\n return false;\n }\n if ($obj-\u003esalt !== $global[\u0027salt\u0027]) {\n _error_log(\"verifyToken salt fail\");\n return false;\n }\n $time = time();\n if (!($time \u003e= $obj-\u003etime \u0026\u0026 $time \u003c= $obj-\u003etimeout)) {\n _error_log(\"verifyToken token timeout time = $time; obj-\u003etime = $obj-\u003etime; obj-\u003etimeout = $obj-\u003etimeout\");\n return false; // \u003c-- uncomment this line\n }\n return true;\n}\n```\n\nAdditionally, consider:\n1. Adding an admin check to the `getClientsList` handler (Message.php:219) so only admins can enumerate connected users.\n2. Re-validating the `isAdmin` claim against the database periodically rather than trusting the token claim for the lifetime of the connection.",
"id": "GHSA-2mg4-pfgx-64cf",
"modified": "2026-03-30T17:35:21Z",
"published": "2026-03-30T17:35:21Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-2mg4-pfgx-64cf"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34362"
},
{
"type": "WEB",
"url": "https://github.com/WWBN/AVideo/commit/5d5237121bf82c24e9e0fdd5bc1699f1157783c5"
},
{
"type": "PACKAGE",
"url": "https://github.com/WWBN/AVideo"
}
],
"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:N",
"type": "CVSS_V3"
}
],
"summary": "AVideo\u0027s WebSocket Token Never Expires Due to Commented-Out Timeout Validation in verifyTokenSocket()"
}
GHSA-2P89-VR82-6VW5
Vulnerability from github – Published: 2022-05-24 19:04 – Updated: 2022-05-24 19:04An issue has been discovered in GitLab affecting all versions starting from 12.9.0 before 13.10.5, all versions starting from 13.11.0 before 13.11.5, all versions starting from 13.12.0 before 13.12.2. Insufficient expired password validation in various operations allow user to maintain limited access after their password expired
{
"affected": [],
"aliases": [
"CVE-2021-22221"
],
"database_specific": {
"cwe_ids": [
"CWE-613"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2021-06-08T19:15:00Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab affecting all versions starting from 12.9.0 before 13.10.5, all versions starting from 13.11.0 before 13.11.5, all versions starting from 13.12.0 before 13.12.2. Insufficient expired password validation in various operations allow user to maintain limited access after their password expired",
"id": "GHSA-2p89-vr82-6vw5",
"modified": "2022-05-24T19:04:18Z",
"published": "2022-05-24T19:04:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2021-22221"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2021/CVE-2021-22221.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/292006"
}
],
"schema_version": "1.4.0",
"severity": []
}
Mitigation
Set sessions/credentials expiration date.
No CAPEC attack patterns related to this CWE.