CVE-2026-87997: Open WebUI Any Authenticated User Can Inject Vulnerability

MODERATE
Advisory Identifier: GHSA-3pf7-q2g3-wj28
CVSS 4.3
CWE-639 CWE-862
Published
Advisory Summary

CVE-2026-87997 is a MODERATE (CVSS 4.3) any authenticated user can inject vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Open WebUI libraries in the PyPI ecosystem. The issue involves any authenticated user can inject chats into another user's folder via chat completions. Remediation is available by upgrading affected packages to version 0.11.1.

CVE-2026-87997 at a Glance

CVE Identifier CVE-2026-87997
GHSA Identifier GHSA-3pf7-q2g3-wj28
Severity MODERATE
CVSS v3.1 Base Score 4.3
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product Open WebUI
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 4.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-87997

To remediate this vulnerability, upgrade all affected Open WebUI dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

open-webui fixed: 0.11.1
pip install open-webui>=0.11.1
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

pip show open-webui

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-87997, inspect your installed packages using pip:

pip show open-webui

Analyze the terminal output to locate any version of Open WebUI in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.11.1), your application is affected.

Note: The pip show open-webui command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where 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. In Open WebUI, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## Summary The chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder's id can put a chat of their own into another user's folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not. ## Preconditions - An authenticated account of any role. No elevated permission, no admin involvement. - Folders enabled, which is the default (`ENABLE_FOLDERS=true`, `USER_PERMISSIONS_FEATURES_FOLDERS=true`). - The attacker needs the target folder's id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to ordinary users by default; only wildcard public sharing is gated. A folder that was never shared has an id the attacker cannot obtain through any endpoint available to them, so those folders are not practically reachable. - Releases before 0.10.0 contain the same missing check but have no read path that lists a folder's chats across owners, so the injected row was never visible to anyone. ## Impact The integrity of folder contents. An attacker who cannot write to a folder can place chats into it, and every member with read access, the owner included, sees the entry with the attacker's display name and a title the attacker can change to arbitrary text at any time. Members can also open the injected chat and read its messages. In a workspace where a shared folder is treated as trusted, that is a usable surface for planting misleading or phishing content under another team's nose. Nothing is disclosed to the attacker and nothing existing is altered. Writing into a folder grants no read access to it, so the attacker still cannot list or open the folder's other chats, and no data belonging to other users can be modified or deleted through this path. Availability is unaffected. ## Fix Fixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28366. Chat creation, chat moves and the chat-completions creation path now share a single folder write-access check, so a folder id the caller cannot write to is rejected everywhere a chat's folder can be set. Upgrading to 0.11.1 resolves it completely, with no configuration change required. ## Root cause Affected component: the chat-completions handler in `backend/open_webui/main.py`, reached through `POST /api/chat/completions` and `POST /api/v1/chat/completions`. Affected setup: every deployment on 0.10.0 through 0.11.0 with folders enabled. The completions handler gained its own chat-creation branch, which copied the client-supplied folder id into the chat it saved. The ownership and shared-write check lived as duplicated inline code inside the two chat routers rather than in one shared helper, so a third place that learned to set a folder id inherited none of it. Separately, folder listings had been changed to return a folder's chats across all owners so that shared folders work at all, which turned a write that used to be invisible to everyone into one the whole folder can see. ## Proof of concept Reproduced on a running instance at 0.11.0 with three accounts: one administrator and two ordinary users, one acting as victim and one as attacker. 1. The victim creates a folder. The attacker is given no access to it: reading the folder returns 404 and listing its chats returns 403. 2. The attacker sends `POST /api/v1/chats/new` with the victim's folder id. Rejected with 404, which is the pre-existing guard working. 3. The attacker sends `POST /api/chat/completions` with `parent_id: null`, no chat id, and the victim's folder id in the body. Accepted. 4. The victim lists their own folder and sees a chat owned by "Attacker". The victim can open it and read its messages. The attacker then renames their own chat and the new title appears verbatim in the victim's folder listing. Repeating step 3 with the attacker granted read-only access to a shared folder also succeeds on 0.11.0. On 0.11.1 both variants are rejected with 404 and the folder stays empty, while a member holding write access can still create chats there as intended. The three accounts and the folder were created through the normal API. Nothing was written directly to the database. ## Credits whyiug, for reporting the missing folder write-access check on the chat-completions creation path.

CVE-2026-87997 Affected Open WebUI Versions

1 component(s)
Fixed Versions:
0.11.1
Product / Package Ecosystem Affected Versions Fixed Version
open-webui
PyPI
≥ 0.10.0
< 0.11.1
0.11.1

References

Frequently Asked Questions

What is CVE-2026-87997?
CVE-2026-87997 is a security vulnerability in Open WebUI involving Any authenticated user can inject chats into another user's folder via chat completions under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Open WebUI versions are affected?
Affected versions include releases prior to 0.11.1 across affected packages: open-webui.
What version fixes CVE-2026-87997?
Upgrading to 0.11.1 (or the latest patched release for your respective branch) resolves the vulnerability.
Is open-webui affected?
Yes, open-webui is affected in releases prior to 0.11.1. Upgrade your dependency to 0.11.1 or later.
What is the CVSS score of CVE-2026-87997?
CVE-2026-87997 has a CVSS v3.1 base score of 4.3 (MODERATE) with vector string CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N.
What CWE is associated with CVE-2026-87997?
CVE-2026-87997 is classified under 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.).
How can I check PyPI dependencies for CVE-2026-87997?
Run the dependency tree command: 'pip show open-webui'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3pf7-q2g3-wj28",
  "modified" : "2026-09-10T15:10:04Z",
  "published" : "2026-09-10T15:10:04Z",
  "aliases" : [ "CVE-2026-87997" ],
  "summary" : "Open WebUI: Any authenticated user can inject chats into another user's folder via chat completions",
  "details" : "## Summary\nThe chat-completions endpoint reads a folder id out of the request body and saves the newly created chat into that folder without checking that the caller is allowed to write there. Any authenticated user who knows a folder's id can put a chat of their own into another user's folder, including a shared folder where they hold read-only access and a folder they have no access to at all. The chat then shows up in that folder for everyone who can read it, under a title and with content the attacker controls. The dedicated chat-creation and chat-move endpoints already enforced this check, the chat-completions path did not.\n\n## Preconditions\n- An authenticated account of any role. No elevated permission, no admin involvement.\n- Folders enabled, which is the default (`ENABLE_FOLDERS=true`, `USER_PERMISSIONS_FEATURES_FOLDERS=true`).\n- The attacker needs the target folder's id. A member of a shared folder gets it from the shared-folder listing. Sharing a folder with named users is available to ordinary users by default; only wildcard public sharing is gated. A folder that was never shared has an id the attacker cannot obtain through any endpoint available to them, so those folders are not practically reachable.\n- Releases before 0.10.0 contain the same missing check but have no read path that lists a folder's chats across owners, so the injected row was never visible to anyone.\n\n## Impact\nThe integrity of folder contents. An attacker who cannot write to a folder can place chats into it, and every member with read access, the owner included, sees the entry with the attacker's display name and a title the attacker can change to arbitrary text at any time. Members can also open the injected chat and read its messages. In a workspace where a shared folder is treated as trusted, that is a usable surface for planting misleading or phishing content under another team's nose.\n\nNothing is disclosed to the attacker and nothing existing is altered. Writing into a folder grants no read access to it, so the attacker still cannot list or open the folder's other chats, and no data belonging to other users can be modified or deleted through this path. Availability is unaffected.\n\n## Fix\nFixed in 0.11.1 by https://github.com/open-webui/open-webui/pull/28366. Chat creation, chat moves and the chat-completions creation path now share a single folder write-access check, so a folder id the caller cannot write to is rejected everywhere a chat's folder can be set. Upgrading to 0.11.1 resolves it completely, with no configuration change required.\n\n## Root cause\nAffected component: the chat-completions handler in `backend/open_webui/main.py`, reached through `POST /api/chat/completions` and `POST /api/v1/chat/completions`. Affected setup: every deployment on 0.10.0 through 0.11.0 with folders enabled.\n\nThe completions handler gained its own chat-creation branch, which copied the client-supplied folder id into the chat it saved. The ownership and shared-write check lived as duplicated inline code inside the two chat routers rather than in one shared helper, so a third place that learned to set a folder id inherited none of it. Separately, folder listings had been changed to return a folder's chats across all owners so that shared folders work at all, which turned a write that used to be invisible to everyone into one the whole folder can see.\n\n## Proof of concept\nReproduced on a running instance at 0.11.0 with three accounts: one administrator and two ordinary users, one acting as victim and one as attacker.\n\n1. The victim creates a folder. The attacker is given no access to it: reading the folder returns 404 and listing its chats returns 403.\n2. The attacker sends `POST /api/v1/chats/new` with the victim's folder id. Rejected with 404, which is the pre-existing guard working.\n3. The attacker sends `POST /api/chat/completions` with `parent_id: null`, no chat id, and the victim's folder id in the body. Accepted.\n4. The victim lists their own folder and sees a chat owned by \"Attacker\". The victim can open it and read its messages. The attacker then renames their own chat and the new title appears verbatim in the victim's folder listing.\n\nRepeating step 3 with the attacker granted read-only access to a shared folder also succeeds on 0.11.0. On 0.11.1 both variants are rejected with 404 and the folder stays empty, while a member holding write access can still create chats there as intended.\n\nThe three accounts and the folder were created through the normal API. Nothing was written directly to the database.\n\n## Credits\nwhyiug, for reporting the missing folder write-access check on the chat-completions creation path.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "open-webui"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.10.0"
      }, {
        "fixed" : "0.11.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/security/advisories/GHSA-3pf7-q2g3-wj28"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-87997"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/pull/28366"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/commit/d9e23b90c100d19b00270aea3cde0501d2354a6c"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/open-webui/open-webui"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/releases/tag/v0.11.1"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-639", "CWE-862" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-10T15:10:04Z",
    "nvd_published_at" : "2026-09-09T22:18:48Z"
  }
}