Open WebUI EUVD-2026-97594

Exploitation requires that an Open WebUI instance be configured with a non-direct, non-Ollama connection - specifically an OAuth-mode OpenAI-compatible connection, an OpenAPI tool server, or a terminal server - pointing to a server the attacker operates or can observe. In affected versions (0.6.27 before 0.11.4) the backend 'get_headers_and_cookies' function in routers/openai.py forwarded 'request.cookies' (the full browser cookie jar, including session cookies) unconditionally on such connections; the fix adds a 'forward_cookies' flag that defaults to false. Limiting factors: the attacker must control or monitor a destination server that an administrator has deliberately connected to, and cookies only leak when users actually route requests through that connection (passive user interaction). Instances that connect only to fully trusted, operator-controlled endpoints are not realistically exploitable; direct and Ollama connections are unaffected by the forwarding path.

This is a credible, above-average-priority issue but not a drop-everything emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H) scores 7.6 and captures the key nuance well: network reachable and low complexity, but gated by an attack requirement (AT:P) - a connection to the attacker-controlled destination server must already be configured - and by passive user interaction (UI:P), since cookies leak on routine user requests rather than attacker-forced actions. The high confidentiality AND integrity impact (VC:H/VI:H) is justified because leaked session cookies enable full account takeover, explicitly including administrators. No EPSS score was provided, so exploitation probability cannot be quantified. The vulnerability is NOT in CISA KEV and no public exploit code is referenced, so this is no public exploit identified at time of analysis - there is no evidence of active exploitation. The most important caveat: the 'attacker' here is effectively the operator of the destination server (an OpenAI-compatible endpoint, OpenAPI tool server, or terminal server) that an Open WebUI admin chose to connect to. Risk is therefore highest where instances connect to untrusted, third-party, or shared-hosting endpoints, and much lower where all connected servers are fully trusted and operator-controlled. Because exploitation is trivial once such a connection exists and yields admin takeover, it should be patched promptly despite the absence of KEV/EPSS/POC signals.

An Open WebUI administrator configures an OAuth-mode connection to a third-party OpenAI-compatible API, OpenAPI tool server, or terminal server. As users (including admins) make routine requests through that connection, Open WebUI forwards their entire browser cookie jar - including session cookies - to the destination server. The server operator logs these forwarded cookies and replays them to hijack the users' Open WebUI sessions, including administrator accounts. No public exploit code is referenced; exploitation requires only that the operator observe traffic they already receive.