GHSA-74h3-cxq7-vc5q is a high-severity (CVSS 7.7) Code Injection vulnerability in open-webui. O3 Security confirms whether GHSA-74h3-cxq7-vc5q is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Open WebUI: Cross-user code-interpreter and tool execution via unvalidated Socket.IO event-caller session_id
Real-World Exposure
open-webuiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
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_idtaken from the request body)
Root cause
The event-caller routes to a caller-controlled session id with no ownership check:
# 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:
# 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:toolare emitted from the code-interpreter and tool-call paths (utils/middleware.py,tools/builtin.py), all routed throughget_event_call.- The victim's live
session_idis disclosed to any read-access participant of a shared note viaydoc:document:join. POST /api/v1/chat/completionsrequires onlyget_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 isexec()'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:
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_callnow 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-deriveduser_idfrom the request metadata. The recommendedydoc:document:joinsid-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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | open-webui | all versions | 0.10.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for open-webui. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update open-webui to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-74h3-cxq7-vc5q is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-74h3-cxq7-vc5q is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-74h3-cxq7-vc5q. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-74h3-cxq7-vc5q in your dependencies?
O3 detects GHSA-74h3-cxq7-vc5q across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.