CVE-2026-45349: open-webui: auth bypass exposes all user chat histories

GHSA-gfm2-xm6c-37qc HIGH PoC AVAILABLE CISA: TRACK*
Published May 14, 2026
CISO Take

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.

Sources: NVD GitHub Advisory ATLAS

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?

Initial Access
Attacker authenticates as a legitimate Open WebUI user and generates a personal API key via the settings panel — no elevated privileges required.
AML.T0012
Target Identification
Attacker obtains a victim's Chat ID by observing their browser URL (e.g., via screen sharing, logs, or URL leakage in collaboration tools) — UUIDs are not secret in practice.
AML.T0095
Authorization Bypass
Attacker sends a POST to `/api/chat/completions` with their own API key and the victim's `chat_id`; the server processes the request without verifying ownership.
AML.T0049
Data Exfiltration
Attacker retrieves the full conversation history of the victim user and can inject new messages into the session, accessing sensitive prompts, documents, and proprietary LLM interactions.
AML.T0057

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Open WebUI pip <= 0.8.12 0.9.0
143.3K Pushed 8d ago 77% patched ~5d to patch Full package profile →

Do you use Open WebUI? You're affected.

How severe is it?

CVSS 3.1
7.1 / 10
EPSS
0.2%
chance of exploitation in 30 days
Higher than 14% of all CVEs
Exploitation Status
Exploit Available
Exploitation: MEDIUM
Sophistication
Trivial
Exploitation Confidence
medium
CISA SSVC: Public PoC
Public PoC indexed (trickest/cve)
Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV AC PR UI S C I A
AV Network
AC Low
PR Low
UI None
S Unchanged
C High
I Low
A None

What should I do?

5 steps
  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 does CISA's SSVC say?

Decision Track*
Exploitation poc
Automatable No
Technical Impact partial

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:

EU AI Act
Art. 10 - Data and Data Governance
ISO 42001
A.6.1.2 - Access Control for AI Systems A.9.4 - System and Application Access Control
NIST AI RMF
GOVERN 1.1 - Policies and Processes for AI Risk Management
OWASP LLM Top 10
LLM02 - Sensitive Information Disclosure

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

Self-hosted LLM chat frontendsMulti-user enterprise AI deploymentsLLM inference gateway setupsShared pipeline model environmentsOn-premise AI assistant platforms

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

EU AI Act: Art. 10
ISO 42001: A.6.1.2, A.9.4
NIST AI RMF: GOVERN 1.1
OWASP LLM Top 10: LLM02

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

Timeline

Published
May 14, 2026
Last Modified
May 14, 2026
First Seen
May 15, 2026

Related Vulnerabilities