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

CWE-613

Allowed-with-Review

Insufficient Session Expiration

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

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

962 vulnerabilities reference this CWE, most recent first.

GHSA-7XFQ-9M67-9J5J

Vulnerability from github – Published: 2024-07-05 03:30 – Updated: 2025-11-05 00:31
VLAI
Details

KSmserver in KDE Plasma Workspace (aka plasma-workspace) before 5.27.11.1 and 6.x before 6.0.5.1 allows connections via ICE based purely on the host, i.e., all local connections are accepted. This allows another user on the same machine to gain access to the session manager, e.g., use the session-restore feature to execute arbitrary code as the victim (on the next boot) via earlier use of the /tmp directory.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-36041"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-07-05T02:15:10Z",
    "severity": "HIGH"
  },
  "details": "KSmserver in KDE Plasma Workspace (aka plasma-workspace) before 5.27.11.1 and 6.x before 6.0.5.1 allows connections via ICE based purely on the host, i.e., all local connections are accepted. This allows another user on the same machine to gain access to the session manager, e.g., use the session-restore feature to execute arbitrary code as the victim (on the next boot) via earlier use of the /tmp directory.",
  "id": "GHSA-7xfq-9m67-9j5j",
  "modified": "2025-11-05T00:31:17Z",
  "published": "2024-07-05T03:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-36041"
    },
    {
      "type": "WEB",
      "url": "https://github.com/KDE/plasma-workspace/tags"
    },
    {
      "type": "WEB",
      "url": "https://invent.kde.org/plasma/plasma-workspace"
    },
    {
      "type": "WEB",
      "url": "https://kde.org/info/security/advisory-20240531-1.txt"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2024/06/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/43YGQJGB5I33UBRY2OHXTPXIEESZLZ6N"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DNOZWSWXAR6EM3VIUJRSAI3L4QPURQPC"
    },
    {
      "type": "WEB",
      "url": "https://www.x.org/releases/X11R7.7/doc/libSM/xsmp.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-7XWP-2CPP-P8R7

Vulnerability from github – Published: 2025-07-16 14:09 – Updated: 2025-07-29 23:17
VLAI
Summary
File Browser’s insecure JWT handling can lead to session replay attacks after logout
Details

Summary

File Browser’s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE's listed in this report for further reference and system standards. In summary, the main issue is:

  • Tokens remain valid after logout (session replay attacks)

In this report, I used docker as the documentation instruct:

docker run \
    -v filebrowser_data:/srv \
    -v filebrowser_database:/database \
    -v filebrowser_config:/config \
    -p 8080:80 \
    filebrowser/filebrowser

Details

Issue: Tokens remain valid after logout (session replay attacks)

After logging in and receiving a JWT token, the user can explicitly "log out." However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request:

POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69

{"username":"admin","password":"password-here","recaptcha":""}

The check found in the code https://github.com/filebrowser/filebrowser/blob/master/http/auth.go is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps:

expired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true)
updated := tk.IssuedAt != nil && tk.IssuedAt.Unix() < d.store.Users.LastUpdate(tk.User.ID)

PoC

Issue: Tokens remain valid after logout (session replay attacks)

  • Login and capture the generate JWT. Eg. the http request:
POST /api/login HTTP/1.1
Host: machine.local:8090
Content-Length: 69

{"username":"admin","password":"password-here","recaptcha":""}
  • Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg:
GET /api/resources HTTP/1.1
Host: machine.local:8090
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36
X-Auth: Old-JWT-token-here
Content-Length: 173
Accept: */*
Referer: http://machine.local:8090/files/
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Content-Length: 26

Connection: keep-alive

Impact

  • A valid JWT remains active after user logout.
  • If stolen, tokens persist access indefinitely until expiry.
  • Violates OWASP Top 10 A2:2021 - Broken Authentication.

Recommendations

  • Read all CWE's attached in this report
  • Invalidate JWTs on logout via session store / token blacklist.
  • Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.
Severity
7.7 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.39.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/filebrowser/filebrowser/v2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.39.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-53826"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-305",
      "CWE-384",
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-07-16T14:09:28Z",
    "nvd_published_at": "2025-07-15T18:15:24Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nFile Browser\u2019s authentication system issues long-lived JWT tokens that remain valid even after the user logs out. Please refer to the CWE\u0027s listed in this report for further reference and system standards. In summary, the main issue is:\n\n- Tokens remain valid after logout (session replay attacks)\n\nIn this report, I used docker as the documentation instruct:\n\n```\ndocker run \\\n    -v filebrowser_data:/srv \\\n    -v filebrowser_database:/database \\\n    -v filebrowser_config:/config \\\n    -p 8080:80 \\\n    filebrowser/filebrowser\n```\n\n### Details\n\n**Issue: Tokens remain valid after logout (session replay attacks)**\n\nAfter logging in and receiving a JWT token, the user can explicitly \"log out.\" However, this action does not invalidate the issued JWT. Any captured token can be replayed post-logout until it expires naturally. The backend does not track active sessions or invalidate existing tokens on logout. Login request:\n\n```\nPOST /api/login HTTP/1.1\nHost: machine.local:8090\nContent-Length: 69\n\n{\"username\":\"admin\",\"password\":\"password-here\",\"recaptcha\":\"\"}\n```\n\nThe check found in the code `https://github.com/filebrowser/filebrowser/blob/master/http/auth.go` is not enough. There is no server-side blacklist or token invalidation on logout. Token renewal and validity only depends on expiry and user store timestamps:\n\n```\nexpired := !tk.VerifyExpiresAt(time.Now().Add(time.Hour), true)\nupdated := tk.IssuedAt != nil \u0026\u0026 tk.IssuedAt.Unix() \u003c d.store.Users.LastUpdate(tk.User.ID)\n```\n\n### PoC\n\n**Issue: Tokens remain valid after logout (session replay attacks)**\n\n- Login and capture the generate JWT. Eg. the http request:\n\n```\nPOST /api/login HTTP/1.1\nHost: machine.local:8090\nContent-Length: 69\n\n{\"username\":\"admin\",\"password\":\"password-here\",\"recaptcha\":\"\"}\n```\n\n- Logout in the dashboard. And then try to use the old generated JWT to access any authenticated endpoint eg:\n\n```\nGET /api/resources HTTP/1.1\nHost: machine.local:8090\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/138.0.0.0 Safari/537.36\nX-Auth: Old-JWT-token-here\nContent-Length: 173\nAccept: */*\nReferer: http://machine.local:8090/files/\nAccept-Encoding: gzip, deflate, br\nAccept-Language: en-US,en;q=0.9\nContent-Length: 26\n\nConnection: keep-alive\n```\n\n### Impact\n\n- A valid JWT remains active after user logout.\n- If stolen, tokens persist access indefinitely until expiry.\n- Violates OWASP Top 10 A2:2021 - Broken Authentication.\n\n### Recommendations\n\n- Read all CWE\u0027s attached in this report\n- Invalidate JWTs on logout via session store / token blacklist.\n- Reduce JWT ExpiresAt where possible or use short-lived + refresh tokens.",
  "id": "GHSA-7xwp-2cpp-p8r7",
  "modified": "2025-07-29T23:17:56Z",
  "published": "2025-07-16T14:09:28Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/security/advisories/GHSA-7xwp-2cpp-p8r7"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-53826"
    },
    {
      "type": "WEB",
      "url": "https://github.com/filebrowser/filebrowser/issues/5216"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/filebrowser/filebrowser"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:P",
      "type": "CVSS_V4"
    }
  ],
  "summary": "File Browser\u2019s insecure JWT handling can lead to session replay attacks after logout"
}

GHSA-83MW-HRR9-5QQ8

Vulnerability from github – Published: 2025-04-02 15:31 – Updated: 2025-04-02 15:31
VLAI
Details

IBM Jazz Reporting Service 7.0.2 and 7.0.3 does not invalidate session after logout which could allow an authenticated privileged user to impersonate another user on the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-25051"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-02T15:15:56Z",
    "severity": "MODERATE"
  },
  "details": "IBM Jazz Reporting Service 7.0.2 and 7.0.3 does not invalidate session after logout which could allow an authenticated privileged user to impersonate another user on the system.",
  "id": "GHSA-83mw-hrr9-5qq8",
  "modified": "2025-04-02T15:31:37Z",
  "published": "2025-04-02T15:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-25051"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7229760"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-84XH-PWC6-7G4G

Vulnerability from github – Published: 2025-02-05 18:34 – Updated: 2026-01-27 15:30
VLAI
Details

When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key are used and/or the SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache are used in the default server and the default server is performing client certificate authentication.  

Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-23419"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-613",
      "CWE-863"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-05T18:15:33Z",
    "severity": "MODERATE"
  },
  "details": "When multiple server blocks are configured to share the same IP address and port, an attacker can use session resumption to bypass client certificate authentication requirements on these servers. This vulnerability arises when  TLS Session Tickets https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_ticket_key  are used and/or the  SSL session cache https://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache  are used in the default server and the default server is performing client certificate authentication.\u00a0\u00a0\n\nNote: Software versions which have reached End of Technical Support (EoTS) are not evaluated.",
  "id": "GHSA-84xh-pwc6-7g4g",
  "modified": "2026-01-27T15:30:26Z",
  "published": "2025-02-05T18:34:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23419"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00017.html"
    },
    {
      "type": "WEB",
      "url": "https://my.f5.com/manage/s/article/K000149173"
    },
    {
      "type": "WEB",
      "url": "http://www.openwall.com/lists/oss-security/2025/02/05/8"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/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-855V-HQ7W-JMJW

Vulnerability from github – Published: 2026-07-24 17:00 – Updated: 2026-07-24 17:00
VLAI
Summary
Open WebUI: Realtime endpoints accept Redis-revoked JWTs after signout/backchannel logout
Details

Summary

With Redis configured, Open WebUI supports JWT revocation: POST /api/v1/auths/signout (per-token jti) and OIDC back-channel logout (per-user revoked_at) record revocations in Redis, and HTTP auth (get_current_user) rejects revoked tokens with 401. The realtime authentication surfaces do not perform this check: Socket.IO connect / user-join / join-channels / join-note and the terminal websocket first-message auth validate tokens with decode_token() only (signature + expiry). A JWT revoked by sign-out or back-channel logout therefore continues to authenticate new realtime connections, even though the same token is rejected on HTTP.

Affected component

  • backend/open_webui/socket/main.py — Socket.IO connect, user-join, join-channels, join-note
  • backend/open_webui/routers/terminals.py — terminal websocket first-message auth
  • backend/open_webui/utils/auth.py — the revocation check was applied to HTTP only

Root cause

HTTP auth enforces revocation:

# utils/auth.py — get_current_user
if data.get('jti') and not await is_valid_token(request, data):
    raise HTTPException(status_code=401, detail='Invalid token')

Realtime auth calls decode_token() only, which verifies signature + expiry but never consults the Redis revocation keys ({prefix}:auth:token:{jti}:revoked, {prefix}:auth:user:{id}:revoked_at):

# socket/main.py — connect / user-join / join-channels / join-note
data = decode_token(auth['token'])
# routers/terminals.py — _resolve_authenticated_connection
data = decode_token(token)

Impact

A JWT revoked by user sign-out or OIDC back-channel logout still authenticates new realtime connections. A stolen token therefore retains realtime access after the victim signs out or the IdP performs back-channel logout — the very remediation for a compromised token. The token can populate SESSION_POOL as the victim, join their user/channel/note rooms (receiving realtime channel messages, collaborative-note updates and presence), drive socket-level collaboration as the victim, and pass terminal websocket authentication when terminal servers are configured. HTTP remains correctly protected (401), so REST data and state-changing REST endpoints are not reachable with the revoked token.

Proof of Concept

Reporter PoC on a Redis-backed deployment (v0.9.6 and main): after POST /api/v1/auths/signout, HTTP returns 401 for the token while a Socket.IO user-join with the same token still authenticates, and the terminal WS reaches terminal-server lookup rather than rejecting it as Invalid token.

Fix

Apply the revocation check on the realtime paths. The logic is factored into is_token_revoked(redis, decoded) (covering per-token jti and per-user revoked_at); the Socket.IO handlers and the terminal WS reject tokens that fail it, using the main app Redis where revocations are stored. HTTP is_valid_token delegates to the same helper, so HTTP behaviour is unchanged.

Affected / Patched

  • Affected: >= 0.9.0, < 0.10.0, and only when Redis is configured (without Redis, per-token revocation is not supported and sign-out does not invalidate JWTs by design).
  • Patched: v0.10.0. The revocation check (is_valid_token, covering per-token jti and per-user revoked_at) is applied on Socket.IO connect / user-join / join-channels / join-note and the terminal websocket first-message auth, using the main app Redis where revocations are stored. HTTP is_valid_token delegates to the same logic, so HTTP behaviour is unchanged.
Severity
7.1 (High)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "open-webui"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.9.0"
            },
            {
              "fixed": "0.10.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-59219"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T17:00:11Z",
    "nvd_published_at": "2026-07-09T17:17:02Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWith Redis configured, Open WebUI supports JWT revocation: `POST /api/v1/auths/signout` (per-token `jti`) and OIDC back-channel logout (per-user `revoked_at`) record revocations in Redis, and HTTP auth (`get_current_user`) rejects revoked tokens with 401. The realtime authentication surfaces do not perform this check: Socket.IO connect / user-join / join-channels / join-note and the terminal websocket first-message auth validate tokens with `decode_token()` only (signature + expiry). A JWT revoked by sign-out or back-channel logout therefore continues to authenticate new realtime connections, even though the same token is rejected on HTTP.\n\n## Affected component\n\n- `backend/open_webui/socket/main.py` \u2014 Socket.IO `connect`, `user-join`, `join-channels`, `join-note`\n- `backend/open_webui/routers/terminals.py` \u2014 terminal websocket first-message auth\n- `backend/open_webui/utils/auth.py` \u2014 the revocation check was applied to HTTP only\n\n## Root cause\n\nHTTP auth enforces revocation:\n\n```python\n# utils/auth.py \u2014 get_current_user\nif data.get(\u0027jti\u0027) and not await is_valid_token(request, data):\n    raise HTTPException(status_code=401, detail=\u0027Invalid token\u0027)\n```\n\nRealtime auth calls `decode_token()` only, which verifies signature + expiry but never consults the Redis revocation keys (`{prefix}:auth:token:{jti}:revoked`, `{prefix}:auth:user:{id}:revoked_at`):\n\n```python\n# socket/main.py \u2014 connect / user-join / join-channels / join-note\ndata = decode_token(auth[\u0027token\u0027])\n# routers/terminals.py \u2014 _resolve_authenticated_connection\ndata = decode_token(token)\n```\n\n## Impact\n\nA JWT revoked by user sign-out or OIDC back-channel logout still authenticates new realtime connections. A stolen token therefore retains realtime access after the victim signs out or the IdP performs back-channel logout \u2014 the very remediation for a compromised token. The token can populate `SESSION_POOL` as the victim, join their user/channel/note rooms (receiving realtime channel messages, collaborative-note updates and presence), drive socket-level collaboration as the victim, and pass terminal websocket authentication when terminal servers are configured. HTTP remains correctly protected (401), so REST data and state-changing REST endpoints are not reachable with the revoked token.\n\n## Proof of Concept\n\nReporter PoC on a Redis-backed deployment (v0.9.6 and main): after `POST /api/v1/auths/signout`, HTTP returns 401 for the token while a Socket.IO user-join with the same token still authenticates, and the terminal WS reaches terminal-server lookup rather than rejecting it as `Invalid token`.\n\n## Fix\n\nApply the revocation check on the realtime paths. The logic is factored into `is_token_revoked(redis, decoded)` (covering per-token `jti` and per-user `revoked_at`); the Socket.IO handlers and the terminal WS reject tokens that fail it, using the main app Redis where revocations are stored. HTTP `is_valid_token` delegates to the same helper, so HTTP behaviour is unchanged.\n\n## Affected / Patched\n\n- Affected: `\u003e= 0.9.0, \u003c 0.10.0`, and only when Redis is configured (without Redis, per-token revocation is not supported and sign-out does not invalidate JWTs by design).\n- Patched: v0.10.0. The revocation check (`is_valid_token`, covering per-token `jti` and per-user `revoked_at`) is applied on Socket.IO connect / user-join / join-channels / join-note and the terminal websocket first-message auth, using the main app Redis where revocations are stored. HTTP `is_valid_token` delegates to the same logic, so HTTP behaviour is unchanged.",
  "id": "GHSA-855v-hq7w-jmjw",
  "modified": "2026-07-24T17:00:11Z",
  "published": "2026-07-24T17:00:11Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-855v-hq7w-jmjw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59219"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/commit/33b91bd8ae8a100a5a306c91441a7d0b422c4cde"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/open-webui/open-webui"
    },
    {
      "type": "WEB",
      "url": "https://github.com/open-webui/open-webui/releases/tag/v0.10.0"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Open WebUI: Realtime endpoints accept Redis-revoked JWTs after signout/backchannel logout"
}

GHSA-857Q-PWW2-XGV7

Vulnerability from github – Published: 2026-01-23 00:31 – Updated: 2026-01-23 00:31
VLAI
Details

This vulnerability occurs when the system permits multiple simultaneous connections to the backend using the same charging station ID. This can result in unauthorized access, data inconsistency, or potential manipulation of charging sessions. The lack of proper session management and expiration control allows attackers to exploit this weakness by reusing valid charging station IDs to establish multiple sessions concurrently.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-55705"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-01-22T23:15:50Z",
    "severity": "HIGH"
  },
  "details": "This vulnerability occurs when the system permits multiple simultaneous \nconnections to the backend using the same charging station ID. This can \nresult in unauthorized access, data inconsistency, or potential \nmanipulation of charging sessions. The lack of proper session management\n and expiration control allows attackers to exploit this weakness by \nreusing valid charging station IDs to establish multiple sessions \nconcurrently.",
  "id": "GHSA-857q-pww2-xgv7",
  "modified": "2026-01-23T00:31:17Z",
  "published": "2026-01-23T00:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-55705"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cisagov/CSAF/blob/develop/csaf_files/OT/white/2026/icsa-26-022-08.json"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/news-events/ics-advisories/icsa-26-022-08"
    }
  ],
  "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"
    }
  ]
}

GHSA-85R2-J732-H557

Vulnerability from github – Published: 2026-06-30 21:31 – Updated: 2026-06-30 21:31
VLAI
Details

IBM DevOps Automation 1.0.1 and IBM DevOps Loop 1.0.2 does not invalidate session IDs after expiration which could allow an authenticated user to impersonate another user on the system.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-36359"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-30T21:16:30Z",
    "severity": "HIGH"
  },
  "details": "IBM DevOps Automation 1.0.1 and IBM DevOps Loop 1.0.2 does not invalidate session IDs after expiration which could allow an authenticated user to impersonate another user on the system.",
  "id": "GHSA-85r2-j732-h557",
  "modified": "2026-06-30T21:31:45Z",
  "published": "2026-06-30T21:31:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36359"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7277970"
    }
  ],
  "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-8863-4QMG-FR45

Vulnerability from github – Published: 2025-01-08 09:30 – Updated: 2025-01-08 16:14
VLAI
Summary
Apache Airflow Fab Provider Insufficient Session Expiration vulnerability
Details

Insufficient Session Expiration vulnerability in Apache Airflow Fab Provider.

This issue affects Apache Airflow Fab Provider: before 1.5.2.

When user password has been changed with admin CLI, the sessions for that user have not been cleared, leading to insufficient session expiration, thus logged users could continue to be logged in even after the password was changed. This only happened when the password was changed with CLI. The problem does not happen in case change was done with webserver thus this is different from CVE-2023-40273 which was addressed in Apache-Airflow 2.7.0

Users are recommended to upgrade to version 1.5.2, which fixes the issue.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "apache-airflow-providers-fab"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-45033"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-01-08T16:14:43Z",
    "nvd_published_at": "2025-01-08T09:15:07Z",
    "severity": "LOW"
  },
  "details": "Insufficient Session Expiration vulnerability in Apache Airflow Fab Provider.\n\nThis issue affects Apache Airflow Fab Provider: before 1.5.2.\n\nWhen user password has been changed with admin CLI, the sessions for that user have not been cleared, leading to insufficient session expiration, thus logged users could continue to be logged in even after the password was changed. This only happened when the password was changed with CLI. The problem does not happen in case change was done with webserver thus this is different from\u00a0[CVE-2023-40273](https://github.com/advisories/GHSA-pm87-24wq-r8w9)\u00a0which was addressed in Apache-Airflow 2.7.0\n\n\nUsers are recommended to upgrade to version 1.5.2, which fixes the issue.",
  "id": "GHSA-8863-4qmg-fr45",
  "modified": "2025-01-08T16:14:43Z",
  "published": "2025-01-08T09:30:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-45033"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apache/airflow/pull/45139"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apache/airflow"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread/yw535346rk766ybzpqtvrl36sjj789st"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Apache Airflow Fab Provider Insufficient Session Expiration vulnerability"
}

GHSA-88RM-6CPC-9J4W

Vulnerability from github – Published: 2026-07-22 21:32 – Updated: 2026-08-07 06:30
VLAI
Details

Question2Answer through 1.8.8 contains a session invalidation vulnerability that allows attackers with a previously obtained remember-me cookie to retain authenticated access by exploiting the forgot-password reset flow's failure to clear the sessioncode field in qa-include/app/users-edit.php. While the normal password-change flow in qa-include/pages/account.php explicitly clears the sessioncode to invalidate persistent qa_session cookies, the forgot-password handler qa_finish_reset_user() omits this step, allowing any valid persistent cookie issued before the reset to continue authenticating the account after the password reset completes.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-64829"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-22T20:17:08Z",
    "severity": "CRITICAL"
  },
  "details": "Question2Answer through 1.8.8 contains a session invalidation vulnerability that allows attackers with a previously obtained remember-me cookie to retain authenticated access by exploiting the forgot-password reset flow\u0027s failure to clear the sessioncode field in qa-include/app/users-edit.php. While the normal password-change flow in qa-include/pages/account.php explicitly clears the sessioncode to invalidate persistent qa_session cookies, the forgot-password handler qa_finish_reset_user() omits this step, allowing any valid persistent cookie issued before the reset to continue authenticating the account after the password reset completes.",
  "id": "GHSA-88rm-6cpc-9j4w",
  "modified": "2026-08-07T06:30:22Z",
  "published": "2026-07-22T21:32:08Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-64829"
    },
    {
      "type": "WEB",
      "url": "https://github.com/q2a/question2answer/pull/1017"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/question2answer-session-fixation-via-forgot-password-flow"
    },
    {
      "type": "WEB",
      "url": "http://seclists.org/fulldisclosure/2026/Aug/32"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/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-895X-RFQP-JH5C

Vulnerability from github – Published: 2025-10-23 15:30 – Updated: 2026-02-17 17:21
VLAI
Summary
Keycloak does not invalidate offline sessions when the offline_access scope is removed
Details

A flaw was found in Keycloak. An offline session continues to be valid when the offline_access scope is removed from the client. The refresh token is accepted and you can continue to request new tokens for the session. As it can lead to a situation where an administrator removes the scope, and assumes that offline sessions are no longer available, but they are.

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": "Maven",
        "name": "org.keycloak:keycloak-services"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.2.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-12110"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-613"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-10-23T19:24:54Z",
    "nvd_published_at": "2025-10-23T15:15:32Z",
    "severity": "MODERATE"
  },
  "details": "A flaw was found in Keycloak. An offline session continues to be valid when the offline_access scope is removed from the client. The refresh token is accepted and you can continue to request new tokens for the session. As it can lead to a situation where an administrator removes the scope, and assumes that offline sessions are no longer available, but they are.",
  "id": "GHSA-895x-rfqp-jh5c",
  "modified": "2026-02-17T17:21:35Z",
  "published": "2025-10-23T15:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-12110"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/pull/43790"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/54e1c8af1e089ad33d32e0f2792610e4b8df421b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/keycloak/keycloak/commit/c830a27928cac4294619af7d147bdff34d4a85e7"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21370"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:21371"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:22088"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:22089"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2025-12110"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2406033"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/keycloak/keycloak"
    }
  ],
  "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": "Keycloak does not invalidate offline sessions when the offline_access scope is removed"
}
Mitigation
Implementation

Set sessions/credentials expiration date.

No CAPEC attack patterns related to this CWE.

← Back to the CWE list