--- id: "CVE-2026-109292" page: "https://infrastack.ai/live/CVE-2026-109292" kind: "vulnerability" aliases: ["CVE-2026-109292", "GHSA-gqfh-jxvw-74rp"] title: "Other users' session tokens disclosed via OAuth-mode connections, tool servers and terminals" severity: "high" cvss: 7.6 epss: null exploited: false status: "open" category: "ai-tooling" products: [{"name": "open-webui", "fixed": ["0.11.4"], "affected": ">= 0.6.27, < 0.11.4", "ecosystem": "pypi"}] ecosystems: ["pypi"] tags: ["ai-tooling", "cwe-200", "open-webui", "openai-compatible", "self-hosted", "terminal-server", "tool-servers"] not_affected_if: ["default-config", "mcp-only", "no-oauth-mode-connections", "session-auth-mode"] published_at: "2026-09-27T19:55:15+00:00" first_seen_at: "2026-11-09T22:53:28+00:00" updated_at: "2026-11-09T23:10:12+00:00" sources: [{"source": "ghsa-repo", "url": "https://github.com/open-webui/open-webui/security/advisories/GHSA-gqfh-jxvw-74rp", "first_seen_at": "2026-11-09T22:53:28+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-109292", "first_seen_at": "2026-11-09T23:10:12+00:00"}] exploit_sources: [] --- # Other users' session tokens disclosed via OAuth-mode connections, tool servers and terminals Link for people: https://infrastack.ai/live/CVE-2026-109292 (this .md is for agents) Open WebUI sent the full browser cookie jar, including its own session cookie, to OpenAI-compatible connections, OpenAPI tool servers and terminal servers set to the OAuth authentication mode. The receiving server can replay that cookie to log in as the user, with admin access if the user is an administrator. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - pypi:open-webui affected >= 0.6.27, < 0.11.4 fixed 0.11.4 ## How to check - Open Admin Settings and review each OpenAI-compatible connection, tool server and terminal server for one set to the "OAuth" authentication mode. - Check the running Open WebUI version, for example with `pip show open-webui`; versions from `0.6.27` up to but not including `0.11.4` are affected. ## Fix - `open-webui` `0.11.4` (fixed version; the advisory says upgrading needs no configuration change). ## Timeline - 2026-11-09T22:53:28+00:00 ghsa-repo https://github.com/open-webui/open-webui/security/advisories/GHSA-gqfh-jxvw-74rp - 2026-11-09T23:10:12+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-109292 ## Documents - [advisory] Maintainer's advisory: github.com https://github.com/open-webui/open-webui/security/advisories/GHSA-gqfh-jxvw-74rp - [advisory] Third-party advisory: www.vulncheck.com https://www.vulncheck.com/advisories/open-webui-0.6.27-before-0.11.4-session-token-disclosure-via-oauth-mode-connections - [fix] Patch: github.com https://github.com/open-webui/open-webui/commit/3cda47cdb449aac970426f0929c9e5f8bb8bd807 - [fix] Patch: github.com https://github.com/open-webui/open-webui/commit/b71744b17823f7a3a9a64cb363e79a7164ed5b23 - [fix] Patch: github.com https://github.com/open-webui/open-webui/commit/f9f815c86220f809fad5ee1300c44f55dea74c79 ## From the sources # Other users' session tokens disclosed via OAuth-mode connections, tool servers and terminals ## Summary An OpenAI-compatible connection, OpenAPI tool server or terminal server configured with the "OAuth" authentication mode sent the full browser cookie jar of the requesting user to its destination, including Open WebUI's own session cookie. The mode is documented to the administrator as forwarding only the user's OAuth access token. Every user whose request reached such a connection disclosed a live session credential to the destination, whether or not they were the administrator who configured it and whether or not an OAuth token was present. ## Preconditions An administrator has configured at least one OpenAI-compatible connection, OpenAPI tool server or terminal server with the "OAuth" authentication mode. Connections default to bearer authentication, so this mode is never active out of the box. No OAuth provider needs to be configured or return a token; the cookies were sent regardless. The destination only needs to observe the incoming Cookie header, which ordinary request logging does. Not affected: connections using the "Session" authentication mode, whose forwarding of session credentials is documented, and MCP tool servers, which never received cookies. ## Impact The operator of the destination receives the Open WebUI session cookie of every verified user whose request reaches it, including through routine calls such as the model list fetched on page load, with no action from the user beyond ordinary use. Replaying that cookie against the instance authenticates as that user for the lifetime of the token, which gives the destination full access to the account and administrative access where the user is an administrator. The destination is a server an administrator registered for OAuth authentication, a configuration that implied sending it only the OAuth access token. ## Fix Fixed in 0.11.4 by https://github.com/open-webui/open-webui/commit/f9f815c86220f809fad5ee1300c44f55dea74c79 (OpenAI-compatible connections), https://github.com/open-webui/open-webui/commit/b71744b17823f7a3a9a64cb363e79a7164ed5b23 (terminal servers) and https://github.com/open-webui/open-webui/commit/3cda47cdb449aac970426f0929c9e5f8bb8bd807 (tool servers and terminal tools). Forwarding the cookie jar is now a separate per-connection setting that is off by default, so the OAuth mode sends only the OAuth access token in the Authorization header. Upgrading resolves the issue with no configuration change. ## Root cause Affected component: the outbound header and cookie builder for OpenAI-compatible connections, the builder for OpenAPI tool servers and terminal tools, and the terminal server proxy. Affected setup: any deployment with a connection, tool server or terminal server set to the "OAuth" authentication mode. When the OAuth mode was added, its branch copied the cookie line from the neighbouring "Session" branch unchanged, so the whole inbound cookie jar was attached to the outbound request before, and independently of, the OAuth token lookup. The forwarded cookies were never narrowed to what the mode is documented to send. Because each outbound call carries the requesting user's own cookies, the disclosed session belongs to whichever user triggered the call. ## Proof of concept Reproduced by the reporter against a running 0.11.2 instance. An OpenAI-compatible connection was registered with a request-capturing destination and the "OAuth" authentication mode. A model list request authenticated only by the session cookie triggered the outbound call. The destination received the full cookie jar, including the session cookie, and no OAuth token. Replaying the captured cookie against the instance returned an authenticated response as the affected account. Confirmed during triage by running the connection header builder from 0.11.3 and 0.11.4 with the same session cookies and no OAuth token: 0.11.3 attaches the session cookie to the outbound request, and 0.11.4 attaches no cookies. ## Credits @gigioneggiando @brodmart --- _Free to read, with fair use of about 60 pages a minute. For higher limits or API access: sales@infrastack.ai_