CVE-2026-59224

CVE-2026-59224 is a high-severity improper authentication vulnerability in open-webui (pip), affecting versions < 0.10.0. It is fixed in 0.10.0.

Does this CVE actually affect you?

Kodem shows which CVEs are reachable and running in your applications, so you fix what's exploitable, not just what's listed.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Runtime intelligence, not another scanner.

Summary

Open WebUI: Terminal proxy forwards a spoofable, integrity-unbound user identity to the upstream (X-User-Id header and wsterminal sessionid query injection)

The terminal proxy in backend/open_webui/routers/terminals.py forwards the Open WebUI user's identity to the upstream terminal server / backend coordinator as an authorization claim, with no cryptographic binding to the session that produced it. The forwarded identity is attacker-influenceable on both proxy paths:

  1. HTTP path (proxy_terminal) sets headers['X-User-Id'] = user.id. Upstreams that trust X-User-Id as identity receive it unsigned, so an attacker who can reach the upstream by other means (directly, a compromised peer, SSRF) can spoof it.

  2. WebSocket path (ws_terminal) is exploitable through Open WebUI itself, with no "other means" required. It interpolates the path parameter session_id directly into the upstream URL and then appends ?user_id=<caller>:

    upstream_url = f'{ws_base}/p/{policy_id}/api/terminals/{session_id}'
    upstream_url += f'?{urllib.parse.urlencode({"user_id": user.id})}'
    

session_id is neither validated nor URL-encoded (the HTTP sibling runs _sanitize_proxy_path; this path runs nothing). An encoded ?/& smuggled through session_id survives Open WebUI's single decode and is re-decoded by the upstream, injecting an attacker-chosen user_id ahead of the appended one. Query parsing binds the first occurrence, so the backend coordinator resolves the spoofed user's terminal scope.

Technical Details

The forwarded terminal identity is a bearer-style authorization claim with no integrity binding, and on the WebSocket path it is additionally injectable because session_id is concatenated into the URL without encoding or delimiter validation.

Appendix: Affected code

  • backend/open_webui/routers/terminals.py, proxy_terminal sets headers['X-User-Id'] = user.id with no signature.
  • backend/open_webui/routers/terminals.py, ws_terminal builds the upstream URL from an unvalidated, unencoded session_id and appends user_id as a query parameter, allowing query injection.

Appendix: Consolidation

Per the Report Handling policy, this consolidates independent reports of the same root cause (the forwarded terminal identity is spoofable / not integrity-bound) into the earliest filing:

  • @smoke-wolf (earliest filing), the X-User-Id HTTP-path identity is forwarded without integrity binding, spoofable where the upstream trusts the header.
  • @rexpository, the ws_terminal session_id query-injection vector, proving the forwarded user_id is spoofable through the Open WebUI proxy itself, with no "reach the upstream by other means" precondition.

Appendix: Recommended fix

  • Validate and URL-encode session_id before building the upstream URL (urllib.parse.quote(session_id, safe=""); reject ?, #, &, /, %, backslash, control characters). Build the query string with a URL builder so attacker-controlled path content cannot precede it.
  • Bind the forwarded identity instead of passing a raw user_id / X-User-Id: emit a short-lived signed claim (for example HS256 over {uid, iat, aud:server_id} with a key shared only with the specific upstream) and verify it upstream.

Impact

A normal authenticated user can make the terminal proxy present another user's identity to the upstream backend coordinator. On backend coordinator-backed (policy_id) servers that scope terminal containers by user_id, this reaches another user's terminal scope; combined with a known active session ID (for example a chat-scoped session ID surfaced through a shared chat), it allows attaching to that user's live PTY. The HTTP-path variant additionally allows identity spoofing at the upstream tier for any deployment whose upstream trusts X-User-Id.

The application does not adequately verify the identity of a user, device, or process before granting access. Typical impact: unauthorized access to functions or data reserved for authenticated parties.

CVE-2026-59224 has a CVSS score of 8.0 (High). The vector is network-reachable, low privileges required, and user interaction required. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.10.0); upgrading removes the vulnerable code path.

Affected versions

open-webui (< 0.10.0)

Security releases

open-webui → 0.10.0 (pip)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environmentNew to Kodem? Get a demo →

Remediation advice

Upgrade open-webui to 0.10.0 or later to resolve this vulnerability.

Kodem Kai can prioritize this vulnerability in your dependency tree and generate a fix recommendation.

Frequently Asked Questions

  1. What is CVE-2026-59224? CVE-2026-59224 is a high-severity improper authentication vulnerability in open-webui (pip), affecting versions < 0.10.0. It is fixed in 0.10.0. The application does not adequately verify the identity of a user, device, or process before granting access.
  2. How severe is CVE-2026-59224? CVE-2026-59224 has a CVSS score of 8.0 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
  3. Which versions of open-webui are affected by CVE-2026-59224? open-webui (pip) versions < 0.10.0 is affected.
  4. Is there a fix for CVE-2026-59224? Yes. CVE-2026-59224 is fixed in 0.10.0. Upgrade to this version or later.
  5. Is CVE-2026-59224 exploitable, and should I be worried? Whether CVE-2026-59224 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
  6. What actually determines whether CVE-2026-59224 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
  7. How do I fix CVE-2026-59224? Upgrade open-webui to 0.10.0 or later.

Other vulnerabilities in open-webui

Stop the waste.
Protect your environment with Kodem.