Common Weakness Enumeration

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

876 vulnerabilities reference this CWE, most recent first.

GHSA-297V-QP46-84H5

Vulnerability from github – Published: 2022-08-02 00:00 – Updated: 2022-08-09 00:00
VLAI
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'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.

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

{
  "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:33
VLAI
Details

An issue was discovered in dnaTools dnaLIMS 4-2015s13. dnaLIMS is vulnerable to session hijacking by guessing the UID parameter.

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

{
  "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:00
VLAI
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)

Show details on source website
To clipboard 

{
  "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-2MG4-PFGX-64CF

Vulnerability from github – Published: 2026-03-30 17:35 – Updated: 2026-03-30 17:35
VLAI
Summary
AVideo's WebSocket Token Never Expires Due to Commented-Out Timeout Validation in verifyTokenSocket()
Details

Summary

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:

  1. Client connects to WebSocket with ?webSocketToken=TOKEN in URL query
  2. onOpen() (Message.php:34) calls getDecryptedInfo($wsocketGetVars['webSocketToken']) (line 48)
  3. getDecryptedInfo() (functions.php:49) decrypts the token and calls verifyTokenSocket($json->token) (line 54)
  4. verifyTokenSocket() validates the salt (passes) but the timeout check at line 77 evaluates the condition without acting on failure — return false is commented out
  5. 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 isAdmin flag 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 webSocketToken message 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.

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

{
  "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:04
VLAI
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

Show details on source website
To clipboard 

{
  "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": []
}

GHSA-2P9P-P295-FC76

Vulnerability from github – Published: 2024-06-14 09:31 – Updated: 2024-06-14 09:31
VLAI
Details

The notification emails sent by Soar Cloud HR Portal contain a link with a embedded session. The expiration of the session is not properly configured, remaining valid for more than 7 days and can be reused.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-5995"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-14T08:15:43Z",
    "severity": "HIGH"
  },
  "details": "The notification emails sent by Soar Cloud HR Portal contain a link with a embedded session. The expiration of the session is not properly configured, remaining valid for more than 7 days and can be reused.",
  "id": "GHSA-2p9p-p295-fc76",
  "modified": "2024-06-14T09:31:17Z",
  "published": "2024-06-14T09:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-5995"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-7872-1c8b4-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-7871-fecf1-1.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"
    }
  ]
}

GHSA-2PR2-HCV6-7GWV

Vulnerability from github – Published: 2026-03-31 23:52 – Updated: 2026-04-06 17:33
VLAI
Summary
OpenClaw's device removal and token revocation do not terminate active WebSocket sessions
Details

Summary

Removing a device or revoking its token updated stored credentials but did not disconnect already-authenticated WebSocket sessions.

Impact

A revoked device could continue using its existing live session until reconnect, extending access beyond credential removal.

Affected Component

src/gateway/server-methods/devices.ts, src/gateway/server.impl.ts

Fixed Versions

  • Affected: <= 2026.3.24
  • Patched: >= 2026.3.28
  • Latest stable 2026.3.28 contains the fix.

Fix

Fixed by commit 7a801cc451 (Gateway: disconnect revoked device sessions).

OpenClaw thanks @AntAISecurityLab for reporting.

Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
8.6 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.24"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.28"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-34503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-31T23:52:03Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\nRemoving a device or revoking its token updated stored credentials but did not disconnect already-authenticated WebSocket sessions.\n\n## Impact\n\nA revoked device could continue using its existing live session until reconnect, extending access beyond credential removal.\n\n## Affected Component\n\n`src/gateway/server-methods/devices.ts, src/gateway/server.impl.ts`\n\n## Fixed Versions\n\n- Affected: `\u003c= 2026.3.24`\n- Patched: `\u003e= 2026.3.28`\n- Latest stable `2026.3.28` contains the fix.\n\n## Fix\n\nFixed by commit `7a801cc451` (`Gateway: disconnect revoked device sessions`).\n\nOpenClaw thanks @AntAISecurityLab for reporting.",
  "id": "GHSA-2pr2-hcv6-7gwv",
  "modified": "2026-04-06T17:33:55Z",
  "published": "2026-03-31T23:52:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-2pr2-hcv6-7gwv"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34503"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/7a801cc451e9e667b705eeccff651923a1b8c863"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-incomplete-websocket-session-termination-on-device-removal-and-token-revocation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw\u0027s device removal and token revocation do not terminate active WebSocket sessions"
}

GHSA-2Q2F-H83X-CX3X

Vulnerability from github – Published: 2024-05-14 21:34 – Updated: 2024-05-14 22:32
VLAI
Summary
Reportico Web fails to invalidate cookies upon logout
Details

An issue in Reportico Web before v.8.1.0. This vulnerability arises from the failure of the web application to properly invalidate session cookies upon logout. When a user logs out of the application, the session cookie should be invalidated to prevent unauthorized access. However, due to the oversight in the application's implementation, the session cookie remains active even after logout. Consequently, if an attacker obtains the session cookie, they can exploit it to access the user's session and perform unauthorized actions.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "reportico-web/reportico"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "8.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-31556"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-05-14T22:32:09Z",
    "nvd_published_at": "2024-05-14T21:15:12Z",
    "severity": "MODERATE"
  },
  "details": "An issue in Reportico Web before v.8.1.0. This vulnerability arises from the failure of the web application to properly invalidate session cookies upon logout. When a user logs out of the application, the session cookie should be invalidated to prevent unauthorized access. However, due to the oversight in the application\u0027s implementation, the session cookie remains active even after logout. Consequently, if an attacker obtains the session cookie, they can exploit it to access the user\u0027s session and perform unauthorized actions.",
  "id": "GHSA-2q2f-h83x-cx3x",
  "modified": "2024-05-14T22:32:09Z",
  "published": "2024-05-14T21:34:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-31556"
    },
    {
      "type": "WEB",
      "url": "https://github.com/reportico-web/reportico/issues/53"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/reportico-web/reportico"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Reportico Web fails to invalidate cookies upon logout"
}

GHSA-2QQV-XP5X-F5WF

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

An issue was discovered in Joomla! 2.5.0 through 3.9.27. CMS functions did not properly termine existing user sessions when a user's password was changed or the user was blocked.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-26037"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-07-07T11:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An issue was discovered in Joomla! 2.5.0 through 3.9.27. CMS functions did not properly termine existing user sessions when a user\u0027s password was changed or the user was blocked.",
  "id": "GHSA-2qqv-xp5x-f5wf",
  "modified": "2022-05-24T19:07:08Z",
  "published": "2022-05-24T19:07:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-26037"
    },
    {
      "type": "WEB",
      "url": "https://developer.joomla.org/security-centre/858-20210703-core-lack-of-enforced-session-termination.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-2VG6-77G8-24MP

Vulnerability from github – Published: 2026-07-07 20:56 – Updated: 2026-07-07 20:56
VLAI
Summary
Better Auth: Stale sessions persist after user deletion across admin, anonymous, and SCIM flows
Details

Am I affected?

Users are affected if all of the following are true:

  • They configure secondaryStorage on betterAuth(...) (Redis, KV, or any external session cache).
  • session.storeSessionInDatabase is left unset or set to false (the default).
  • Their application's deployment uses one or more of:
  • The admin plugin and calls auth.api.removeUser(...) or authClient.admin.removeUser(...).
  • The anonymous plugin and exposes /delete-anonymous-user or relies on the after-link hook to clean up the anonymous user.
  • The @better-auth/scim plugin and exposes DELETE /scim/v2/Users/:userId.

If storeSessionInDatabase is true, sessions are also written to the database, and the database delete cascades; users are not affected.

Fix:

  1. Upgrade to better-auth@<patched-version> or later (and @better-auth/scim@<patched-version> if they use SCIM).
  2. If they cannot upgrade, see workarounds below.

Summary

When secondaryStorage is configured and storeSessionInDatabase is false, three user-deletion endpoints in better-auth plus one in @better-auth/scim call internalAdapter.deleteUser(userId) without first calling internalAdapter.deleteSessions(userId). The deleted user's session payload (which carries a cached user object) remains in secondary storage, and internalAdapter.findSession(token) keeps returning it as a valid session until the session TTL elapses (default 7 days).

Details

The vulnerable call sites are:

  • admin plugin's removeUser (packages/better-auth/src/plugins/admin/routes.ts:1463).
  • anonymous plugin's self-delete endpoint (packages/better-auth/src/plugins/anonymous/index.ts:222).
  • anonymous plugin's after-link hook (packages/better-auth/src/plugins/anonymous/index.ts:325).
  • @better-auth/scim's DELETE /scim/v2/Users/:userId (packages/scim/src/routes.ts:1019).

Working callers that already do the right thing: the core /delete-user self-delete and /delete-user/callback (packages/better-auth/src/api/routes/update-user.ts:551).

The fix shape extends each vulnerable caller to invoke deleteSessions(userId) before deleteUser(userId). The architectural follow-up centralizes the cleanup inside deleteUser itself or introduces a single deleteUserAndSessions orchestrator so future callers cannot regress this contract.

Patches

Fixed in better-auth@<patched-version> and @better-auth/scim@<patched-version>. All four user-deletion call sites now invoke deleteSessions(userId) before deleteUser(userId) so sessions are evicted from secondary storage at the same time the user row is removed.

Workarounds

If users cannot upgrade immediately:

  • Configuration-level: set session.storeSessionInDatabase: true. Subsequent user-delete writes reach the session table and the database cascade removes rows. Increases write volume for high-throughput sessions but eliminates the gap.
  • Code-level (admin path): when calling auth.api.removeUser, also call auth.api.revokeUserSessions({ body: { userId } }), which uses deleteSessions internally.
  • Code-level (SCIM path): wrap their SCIM provider's deprovisioning hook to call auth.api.revokeUserSessions(...) after the SCIM DELETE.
  • Code-level (anonymous path): in onLinkAccount, explicitly call internalAdapter.deleteSessions(anonymousUser.user.id) before allowing the new session to be issued.

Impact

  • Stale session validity: a deleted user's existing session cookie continues to authenticate against getSessionFromCtx until the session TTL elapses (default 7 days). Within that window, the deleted user retains their pre-existing read and write surface.
  • SCIM-driven deprovisioning gap: organizations using SCIM to revoke offboarded employees' access do not, in fact, revoke active sessions. The deleted account remains usable for up to 7 days after deprovisioning.

Credit

Reported by @iruizsalinas.

Resources

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "better-auth"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.3.4"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@better-auth/scim"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.6.0"
            },
            {
              "fixed": "1.6.11"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-459",
      "CWE-613",
      "CWE-672"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-07T20:56:45Z",
    "nvd_published_at": null,
    "severity": "LOW"
  },
  "details": "### Am I affected?\n\nUsers are affected if all of the following are true:\n\n- They configure `secondaryStorage` on `betterAuth(...)` (Redis, KV, or any external session cache).\n- `session.storeSessionInDatabase` is left unset or set to `false` (the default).\n- Their application\u0027s deployment uses one or more of:\n  - The `admin` plugin and calls `auth.api.removeUser(...)` or `authClient.admin.removeUser(...)`.\n  - The `anonymous` plugin and exposes `/delete-anonymous-user` or relies on the after-link hook to clean up the anonymous user.\n  - The `@better-auth/scim` plugin and exposes `DELETE /scim/v2/Users/:userId`.\n\nIf `storeSessionInDatabase` is `true`, sessions are also written to the database, and the database delete cascades; users are not affected.\n\nFix:\n\n1. Upgrade to `better-auth@\u003cpatched-version\u003e` or later (and `@better-auth/scim@\u003cpatched-version\u003e` if they use SCIM).\n2. If they cannot upgrade, see workarounds below.\n\n### Summary\n\nWhen `secondaryStorage` is configured and `storeSessionInDatabase` is `false`, three user-deletion endpoints in `better-auth` plus one in `@better-auth/scim` call `internalAdapter.deleteUser(userId)` without first calling `internalAdapter.deleteSessions(userId)`. The deleted user\u0027s session payload (which carries a cached user object) remains in secondary storage, and `internalAdapter.findSession(token)` keeps returning it as a valid session until the session TTL elapses (default 7 days).\n\n### Details\n\nThe vulnerable call sites are:\n\n- `admin` plugin\u0027s `removeUser` (`packages/better-auth/src/plugins/admin/routes.ts:1463`).\n- `anonymous` plugin\u0027s self-delete endpoint (`packages/better-auth/src/plugins/anonymous/index.ts:222`).\n- `anonymous` plugin\u0027s after-link hook (`packages/better-auth/src/plugins/anonymous/index.ts:325`).\n- `@better-auth/scim`\u0027s `DELETE /scim/v2/Users/:userId` (`packages/scim/src/routes.ts:1019`).\n\nWorking callers that already do the right thing: the core `/delete-user` self-delete and `/delete-user/callback` (`packages/better-auth/src/api/routes/update-user.ts:551`).\n\nThe fix shape extends each vulnerable caller to invoke `deleteSessions(userId)` before `deleteUser(userId)`. The architectural follow-up centralizes the cleanup inside `deleteUser` itself or introduces a single `deleteUserAndSessions` orchestrator so future callers cannot regress this contract.\n\n### Patches\n\nFixed in `better-auth@\u003cpatched-version\u003e` and `@better-auth/scim@\u003cpatched-version\u003e`. All four user-deletion call sites now invoke `deleteSessions(userId)` before `deleteUser(userId)` so sessions are evicted from secondary storage at the same time the user row is removed.\n\n### Workarounds\n\nIf users cannot upgrade immediately:\n\n- **Configuration-level**: set `session.storeSessionInDatabase: true`. Subsequent user-delete writes reach the session table and the database cascade removes rows. Increases write volume for high-throughput sessions but eliminates the gap.\n- **Code-level (admin path)**: when calling `auth.api.removeUser`, also call `auth.api.revokeUserSessions({ body: { userId } })`, which uses `deleteSessions` internally.\n- **Code-level (SCIM path)**: wrap their SCIM provider\u0027s deprovisioning hook to call `auth.api.revokeUserSessions(...)` after the SCIM DELETE.\n- **Code-level (anonymous path)**: in `onLinkAccount`, explicitly call `internalAdapter.deleteSessions(anonymousUser.user.id)` before allowing the new session to be issued.\n\n### Impact\n\n- **Stale session validity**: a deleted user\u0027s existing session cookie continues to authenticate against `getSessionFromCtx` until the session TTL elapses (default 7 days). Within that window, the deleted user retains their pre-existing read and write surface.\n- **SCIM-driven deprovisioning gap**: organizations using SCIM to revoke offboarded employees\u0027 access do not, in fact, revoke active sessions. The deleted account remains usable for up to 7 days after deprovisioning.\n\n### Credit\n\nReported by @iruizsalinas.\n\n### Resources\n\n- [CWE-613: Insufficient Session Expiration](https://cwe.mitre.org/data/definitions/613.html)\n- [CWE-672: Operation on a Resource after Expiration or Release](https://cwe.mitre.org/data/definitions/672.html)\n- [CWE-459: Incomplete Cleanup](https://cwe.mitre.org/data/definitions/459.html)",
  "id": "GHSA-2vg6-77g8-24mp",
  "modified": "2026-07-07T20:56:45Z",
  "published": "2026-07-07T20:56:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/security/advisories/GHSA-2vg6-77g8-24mp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/better-auth/better-auth"
    },
    {
      "type": "WEB",
      "url": "https://github.com/better-auth/better-auth/releases/tag/v1.6.11"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Better Auth: Stale sessions persist after user deletion across admin, anonymous, and SCIM flows"
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list