CVE-2026-45349: open-webui: auth bypass exposes all user chat histories
GHSA-gfm2-xm6c-37qc HIGH PoC AVAILABLE CISA: TRACK*Open WebUI versions up to 0.8.12 contain a broken object-level authorization flaw in the `/api/chat/completions` API endpoint: any authenticated user holding a valid API key can read and continue another user's conversation simply by supplying that user's Chat ID, which is openly visible in browser URLs. In shared or enterprise deployments — the dominant use case for self-hosted LLM frontends — this means all conversation history, including proprietary prompts, uploaded documents, and model outputs, is accessible to any internal user without elevated privileges. With 91 prior CVEs in the same package and a trivial exploit path requiring no special tooling, the risk of opportunistic insider exploitation is high. Remediation is straightforward: upgrade to open-webui >= 0.9.0, which enforces chat ownership via `Chats.is_chat_owner()` before processing any request targeting an existing chat.
What is the risk?
CVSS 7.1 (High) with AV:N/AC:L/PR:L/UI:N reflects a low-complexity, network-accessible exploit requiring only a valid user account and API key — both easy to obtain in any multi-user deployment. The confidentiality impact is HIGH because the entire conversation history of any targeted user is exposed. Chat IDs are UUIDs embedded in browser URLs, making them observable via shoulder-surfing, browser history, logs, or URL leakage in shared environments. No public exploit is listed, but the PoC is trivially reproducible from the advisory. The absence of CISA KEV listing and no EPSS data slightly temper urgency, but the exploitability profile and breadth of affected deployments make this a priority patch for any organization running a shared Open WebUI instance.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Open WebUI | pip | <= 0.8.12 | 0.9.0 |
Do you use Open WebUI? You're affected.
How severe is it?
What is the attack surface?
What should I do?
5 steps-
Upgrade to open-webui >= 0.9.0 immediately — this is the only complete fix.
-
Prior to patching: disable API key generation in settings to prevent programmatic exploitation, or restrict API access to trusted IPs via reverse proxy rules.
-
Audit your web/proxy access logs for requests to
/api/chat/completionsthat include achat_idparameter not matching the authenticated user's session — anomalous cross-user access will appear as API key auth + foreign chat_id. -
Notify users of the disclosure and advise them to consider any conversation conducted on the platform prior to patching as potentially accessible to other users.
-
If operating in a compliance context (ISO 42001, GDPR), assess whether a personal data breach notification is required based on the sensitivity of conversations stored.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-45349?
Open WebUI versions up to 0.8.12 contain a broken object-level authorization flaw in the `/api/chat/completions` API endpoint: any authenticated user holding a valid API key can read and continue another user's conversation simply by supplying that user's Chat ID, which is openly visible in browser URLs. In shared or enterprise deployments — the dominant use case for self-hosted LLM frontends — this means all conversation history, including proprietary prompts, uploaded documents, and model outputs, is accessible to any internal user without elevated privileges. With 91 prior CVEs in the same package and a trivial exploit path requiring no special tooling, the risk of opportunistic insider exploitation is high. Remediation is straightforward: upgrade to open-webui >= 0.9.0, which enforces chat ownership via `Chats.is_chat_owner()` before processing any request targeting an existing chat.
Is CVE-2026-45349 actively exploited?
Proof-of-concept exploit code is publicly available for CVE-2026-45349, increasing the risk of exploitation.
How to fix CVE-2026-45349?
1. Upgrade to open-webui >= 0.9.0 immediately — this is the only complete fix. 2. Prior to patching: disable API key generation in settings to prevent programmatic exploitation, or restrict API access to trusted IPs via reverse proxy rules. 3. Audit your web/proxy access logs for requests to `/api/chat/completions` that include a `chat_id` parameter not matching the authenticated user's session — anomalous cross-user access will appear as API key auth + foreign chat_id. 4. Notify users of the disclosure and advise them to consider any conversation conducted on the platform prior to patching as potentially accessible to other users. 5. If operating in a compliance context (ISO 42001, GDPR), assess whether a personal data breach notification is required based on the sensitivity of conversations stored.
What systems are affected by CVE-2026-45349?
This vulnerability affects the following AI/ML architecture patterns: Self-hosted LLM chat frontends, Multi-user enterprise AI deployments, LLM inference gateway setups, Shared pipeline model environments, On-premise AI assistant platforms.
What is the CVSS score for CVE-2026-45349?
CVE-2026-45349 has a CVSS v3.1 base score of 7.1 (HIGH). The EPSS exploitation probability is 0.23%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0040 AI Model Inference API Access AML.T0049 Exploit Public-Facing Application AML.T0057 LLM Data Leakage AML.T0085 Data from AI Services AML.T0091.000 Application Access Token Compliance Controls Affected
What are the technical details?
Original Advisory
### Summary Any user `X` can continue the conversation of any other user `Y`, as long as the Chat ID of `Y` is known. User `X` does not even need to be an admin to do so. ### Details A user just needs to use the API endpoint: `/api/chat/completions` with their own API key (generated in OWUI) and the Chat ID of another user. **OWUI does not check to match the Chat ID with the user that created that Chat ID**. Note that both users will need access to the same model. This is especially relevant if there is a shared pipeline model between users. ### PoC 1. Using OWUI v0.6.18 2. Sign in with any user `X` 3. Generate an API Key for user `X` using the settings 4. Create another user `Y`, and have a conversation in OWUI. Copy the Chat ID from the URL. 5. User `X` can now use the API `/api/chat/completions` and the Chat ID from step 4 to continue the conversation of user `Y` ### Impact Large impact to any user in OWUI. People can read your conversations, and access private information if they know your Chat ID (which is in the URL of the chat). ## Resolution Fixed in commit [cf4218e68](https://github.com/open-webui/open-webui/commit/cf4218e688def6f11d195aeda6665ae5b5376b67), first released in **v0.9.0** (Apr 2026). The `chat_completion` handler at `backend/open_webui/main.py:1868` now explicitly verifies chat ownership via `Chats.is_chat_owner(chat_id, user.id)` for any request that targets an existing chat, and raises 404 for non-owners (admin bypass preserved per the documented threat model). New chats (no `chat_id` supplied, or freshly inserted via the `is_new_chat` branch) are unaffected. Users on `>= 0.9.0` are not affected.
Exploitation Scenario
An insider adversary (e.g., a developer or analyst with a standard Open WebUI account) generates their personal API key via the Settings panel. They observe a colleague's Chat ID from a shared screen, meeting recording, or URL visible in a Slack screenshot. The attacker then issues a POST request to `/api/chat/completions` with their own Authorization header and the victim's `chat_id` in the payload. Open WebUI processes the request without verifying ownership, returning the full conversation context and allowing the attacker to inject additional messages into the victim's session. The attacker can harvest proprietary LLM prompt templates, internal project data, or PII from hundreds of conversations with a simple enumeration loop — all appearing in logs as normal API traffic from a legitimate user.
Weaknesses (CWE)
CWE-639 — Authorization Bypass Through User-Controlled Key: The system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data.
- [Architecture and Design] For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
- [Architecture and Design, Implementation] Make sure that the key that is used in the lookup of a specific user's record is not controllable externally by the user or that any tampering can be detected.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N References
Timeline
Related Vulnerabilities
CVE-2026-44551 9.1 open-webui: LDAP auth bypass — full account takeover
Same package: open-webui CVE-2026-45672 8.8 open-webui: code exec gate bypass via API endpoint
Same package: open-webui CVE-2026-44552 8.7 open-webui: Redis cache poisoning enables cross-instance tool hijack
Same package: open-webui CVE-2025-64495 8.7 Open WebUI: XSS-to-RCE via malicious prompt injection
Same package: open-webui CVE-2026-45315 8.7 open-webui: stored XSS → JWT theft and admin takeover
Same package: open-webui