CVE-2026-59216

criticalpriority · track · 36OT risk · elevatedEPSS 0.005 · 39 %ileEUUS
grimoire priorityP2 · Scheduled
Exploitable?
—
no known exploitation
Likely / severe?
0.45% (39th) EPSS
CVSS 9 · critical
Is it mine?
3 products
Check your exposure
Who says so?
4 sources
cnnvd · enisa_euvd · osv · nvd

EPSS · scored 2026-10-27

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, get_event_call delivered execute:python and execute:tool Socket.IO events to a client-supplied session_id after checking only that the session was connected, allowing authenticated users who learned another socket ID through ydoc:document:join to run code interpreter Python or tools in that user session. This issue is fixed in version 0.10.0.

01

cvss

Technical severity, 0–10. One row per scoring source.

9.0
010

base score 0–10 · higher = more severe · hover a vector to decode⚠ sources disagree · high–critical · 7.7–9

v3.19criticalCVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:Hprimary · NVD / NIST USexploitability 2.3 · impact 6
v3.17.7highCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:Nsecondary · ENISA EU
v3.17.7highCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:Nsecondary · security-advisories@github.comexploitability 1.3 · impact 5.8
v3.17.7highCVSS:3.1/AV:N/AC:H/PR:L/UI:R/S:C/C:H/I:H/A:Nsecondary · OSV
v3.18.2highCVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:H/E:Usecondary · CVSS-BT (t0sche)
02

ssvc

A stakeholder decision — act, attend, or track — from exploitation and impact.

Exploitation: poc · Automatable: no · Technical Impact: totalcoordinatorcisa_ssvcUS
03

weaknesses

The CWE weakness classes this flaw belongs to.

04

affected products (3)

Products and version ranges known to be affected.

05

advisories (2)

Vendor and ecosystem advisories describing this.

  • GHSA-74h3-cxq7-vc5qOpen WebUI: Cross-user code-interpreter and tool execution via unvalidated Socket.IO event-caller session_id2026-07-24ghsa · osvUS

    ## Summary An authenticated low-privilege user can execute arbitrary code-interpreter Python and tools inside **another** user's authenticated session. The Socket.IO event-caller (`get_event_call`) delivers `execute:python` / `execute:tool` events to a **client-supplied** `session_id` after only checking that the session is connected, never that it belongs to the requester. Combined with `ydoc:document:join`, which exposes the live socket ids of everyone in a shared note's collaboration room to any read-access participant, an attacker can target a victim's session and run attacker-chosen code/tools in the victim's browser context. When the victim is an administrator, that hijacked context reaches the admin-only Functions API, whose source is executed server-side, yielding remote code execution as the server process (root in the default container). ## Affected component - `backend/open_webui/socket/main.py` — `get_event_call()` / `__event_caller__` - `backend/open_webui/main.py` — chat-completion metadata (`session_id` taken from the request body) ## Root cause The event-caller routes to a caller-controlled session id with no ownership check: ```python # backend/open_webui/socket/main.py — get_event_call() async def __event_caller__(event_data): session_id = request_info['session_id'] if session_id not in SESSION_POOL: # only checks the session is connected return {'error': 'Client session disconnected.'} return await sio.call('events', {...}, to=session_id, ...) # delivered to that sid ``` `session_id` originates from the request body and is never validated against the authenticated user: ```python # backend/open_webui/main.py metadata = { 'user_id': user.id, # server-derived (trustworthy) 'session_id': form_data.pop('session_id', None), # client-controlled ... } ``` `SESSION_POOL[session_id]` is the user record of whoever owns that socket. Because the caller checks only membership (`in SESSION_POOL`), a request carrying another user's `session_id` causes `execute:python` / `execute:tool` to be delivered to that other user's browser. ## Reachability - `execute:python` / `execute:tool` are emitted from the code-interpreter and tool-call paths (`utils/middleware.py`, `tools/builtin.py`), all routed through `get_event_call`. - The victim's live `session_id` is disclosed to any read-access participant of a shared note via `ydoc:document:join`. - `POST /api/v1/chat/completions` requires only `get_verified_user` (the default user role). The attacker uses their own account and a model / Direct Connection they control to choose the payload. ## Impact - **Any victim:** arbitrary code-interpreter Python and tool execution in the victim's authenticated session — the attacker acts with the victim's identity and origin (full session/account compromise). - **Admin victim:** the hijacked admin context reaches `POST /api/v1/functions/create`, whose source is `exec()`'d server-side → remote code execution as the server process (root in the default container). The Functions API is intended administrator code-execution; the vulnerability here is the cross-user delivery that lets an attacker drive another user's session — including an admin's — into it. The primitive is a full session compromise even against non-admin victims. ## Proof of Concept The reporter's `exploit.py` reproduced on `ghcr.io/open-webui/open-webui:0.9.6` and a build of the `v0.9.6` tag, confirming blind server-side RCE out-of-band (callback returns `uid=0(root)`), using only a low-privilege `user` account that shared a note with an admin victim. Preconditions: code interpreter enabled; attacker shares a note with the victim; victim opens it while online; admin victim required for server RCE. ## Fix `get_event_call` must verify the target session belongs to the requesting user before delivering, not merely that it is connected: ```python session = SESSION_POOL.get(session_id) if session is None or session.get('id') != request_info.get('user_id'): return {'error': 'Client session disconnected.'} ``` `user_id` in the request metadata is server-derived from the authenticated user, so it is trustworthy. Restricting `ydoc:document:join` so it does not disclose other participants' socket ids is recommended as defence-in-depth. ## Affected / Patched - Affected: `< 0.10.0` (last affected release 0.9.6) - Patched: v0.10.0. `get_event_call` now verifies the target session belongs to the requesting user before delivering (`session is None or session.get('id') != request_info.get('user_id')`), using the server-derived `user_id` from the request metadata. The recommended `ydoc:document:join` sid-disclosure restriction is defence-in-depth and independent of this fix; the ownership check closes the cross-user delivery regardless of whether the victim's sid is known.

  • PYSEC-2026-3592Open WebUI: Cross-user code-interpreter and tool execution via unvalidated Socket.IO event-caller session_id2026-08-04vendor · osvUS

    ## Summary An authenticated low-privilege user can execute arbitrary code-interpreter Python and tools inside **another** user's authenticated session. The Socket.IO event-caller (`get_event_call`) delivers `execute:python` / `execute:tool` events to a **client-supplied** `session_id` after only checking that the session is connected, never that it belongs to the requester. Combined with `ydoc:document:join`, which exposes the live socket ids of everyone in a shared note's collaboration room to any read-access participant, an attacker can target a victim's session and run attacker-chosen code/tools in the victim's browser context. When the victim is an administrator, that hijacked context reaches the admin-only Functions API, whose source is executed server-side, yielding remote code execution as the server process (root in the default container). ## Affected component - `backend/open_webui/socket/main.py` — `get_event_call()` / `__event_caller__` - `backend/open_webui/main.py` — chat-completion metadata (`session_id` taken from the request body) ## Root cause The event-caller routes to a caller-controlled session id with no ownership check: ```python # backend/open_webui/socket/main.py — get_event_call() async def __event_caller__(event_data): session_id = request_info['session_id'] if session_id not in SESSION_POOL: # only checks the session is connected return {'error': 'Client session disconnected.'} return await sio.call('events', {...}, to=session_id, ...) # delivered to that sid ``` `session_id` originates from the request body and is never validated against the authenticated user: ```python # backend/open_webui/main.py metadata = { 'user_id': user.id, # server-derived (trustworthy) 'session_id': form_data.pop('session_id', None), # client-controlled ... } ``` `SESSION_POOL[session_id]` is the user record of whoever owns that socket. Because the caller checks only membership (`in SESSION_POOL`), a request carrying another user's `session_id` causes `execute:python` / `execute:tool` to be delivered to that other user's browser. ## Reachability - `execute:python` / `execute:tool` are emitted from the code-interpreter and tool-call paths (`utils/middleware.py`, `tools/builtin.py`), all routed through `get_event_call`. - The victim's live `session_id` is disclosed to any read-access participant of a shared note via `ydoc:document:join`. - `POST /api/v1/chat/completions` requires only `get_verified_user` (the default user role). The attacker uses their own account and a model / Direct Connection they control to choose the payload. ## Impact - **Any victim:** arbitrary code-interpreter Python and tool execution in the victim's authenticated session — the attacker acts with the victim's identity and origin (full session/account compromise). - **Admin victim:** the hijacked admin context reaches `POST /api/v1/functions/create`, whose source is `exec()`'d server-side → remote code execution as the server process (root in the default container). The Functions API is intended administrator code-execution; the vulnerability here is the cross-user delivery that lets an attacker drive another user's session — including an admin's — into it. The primitive is a full session compromise even against non-admin victims. ## Proof of Concept The reporter's `exploit.py` reproduced on `ghcr.io/open-webui/open-webui:0.9.6` and a build of the `v0.9.6` tag, confirming blind server-side RCE out-of-band (callback returns `uid=0(root)`), using only a low-privilege `user` account that shared a note with an admin victim. Preconditions: code interpreter enabled; attacker shares a note with the victim; victim opens it while online; admin victim required for server RCE. ## Fix `get_event_call` must verify the target session belongs to the requesting user before delivering, not merely that it is connected: ```python session = SESSION_POOL.get(session_id) if session is None or session.get('id') != request_info.get('user_id'): return {'error': 'Client session disconnected.'} ``` `user_id` in the request metadata is server-derived from the authenticated user, so it is trustworthy. Restricting `ydoc:document:join` so it does not disclose other participants' socket ids is recommended as defence-in-depth. ## Affected / Patched - Affected: `< 0.10.0` (last affected release 0.9.6) - Patched: v0.10.0. `get_event_call` now verifies the target session belongs to the requesting user before delivering (`session is None or session.get('id') != request_info.get('user_id')`), using the server-derived `user_id` from the request metadata. The recommended `ydoc:document:join` sid-disclosure restriction is defence-in-depth and independent of this fix; the ownership check closes the cross-user delivery regardless of whether the victim's sid is known.

06

also known as (6)

Other names and identifiers for this entity.

07

sources

Which sources assert this record, and when.

published 2026-07-09modified 2026-07-13
08

references (12)

External citations — patches, advisories, analysis.

scry

Attackers weaponise vulnerabilities like this against internet-exposed services. See what is exposed on your perimeter with a free passive scan.

Free scan