CVE-2026-87994: Open WebUI Channel Members Can Overwrite Another Vulnerability

MODERATE
Advisory Identifier: GHSA-fmqh-xp37-5hr8
CVSS 4.3
CWE-639 CWE-862
Published
Advisory Summary

CVE-2026-87994 is a MODERATE (CVSS 4.3) channel members can overwrite another vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Open WebUI libraries in the PyPI ecosystem. The issue involves channel members can overwrite another member's message via the chat completions endpoint. Remediation is available by upgrading affected packages to version 0.11.1.

CVE-2026-87994 at a Glance

CVE Identifier CVE-2026-87994
GHSA Identifier GHSA-fmqh-xp37-5hr8
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-87994

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-87994, 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 Any member of a channel who can post to it could also replace the text of a message written by a different member. The channel branch of the chat completions endpoint checked that the caller may write to the channel, and that the targeted message belongs to that channel, but never checked that the caller actually wrote the message being edited. The message kept its original author, so the replacement text was displayed and stored as though the victim had written it. The dedicated channel message edit route performed the authorship check correctly and refused the same edit, so the two paths disagreed about who may modify a message. ## Preconditions - Channels must be enabled. `ENABLE_CHANNELS` defaults to `False`, so a default deployment is not affected until an administrator turns channels on. - The attacker must be an approved user holding write access to the target channel, which is the ordinary state for any participant. No elevated role, group membership or additional permission is needed, and the attacker does not need to be the channel owner. - The attacker must know the id of the targeted message. That id is returned to every member who reads the channel, so it requires no further access. - Channels the attacker cannot post to are not affected, and neither are deployments with channels disabled. ## Impact An attacker can rewrite what another member said, under that member's name, in a shared channel. The stored record and every later reader show the victim as the author of text they never wrote, so this is a loss of both integrity and non-repudiation: the victim cannot point to the record to show what they actually said. A conversation can be silently altered after the fact rather than only appended to. How much control the attacker has over the replacement text depends on the configured model, because the text is produced by generating a completion into the victim's message. Reducing a message to unrelated or empty content works regardless of the model, while reproducing an exact attacker-chosen string requires a model that returns the supplied prompt closely enough. The attack grants no new role or permission, does not reach channels the attacker cannot already post to, and exposes no message content they could not already read. ## Fix Fixed in 0.11.1 by commit `7d392bedc` (#28631). The gate on the channel branch now also compares the targeted message's author against the calling user and refuses when they differ, which is the condition the dedicated channel message update route already applied. Administrators retain the ability to edit any message, on both paths, as before. Upgrading to 0.11.1 fully resolves this, and no configuration change is required. ## Root cause Affected components: - the channel branch of the chat completions handler, which resolves a client-supplied message id for editing - the channel event emitter, which re-checks the message before persisting the update Not affected: the dedicated channel message update route, which already held the correct check. The channel branch was written to answer the question of whether the caller may write into this channel and whether the message belongs to it. Both of those checks were present and effective. The question it never asked was whether the caller wrote the message. Ownership of a channel message is carried by the message record rather than by the channel, so channel-level write access was treated as sufficient authority over every message inside it. The dedicated edit route grew the authorship comparison because editing is its only purpose, while the completions path reached the same operation through a general-purpose entry point and inherited only the coarser channel check. ## Proof of concept Reproduced against a running instance built from the development branch, with channels enabled and an OpenAI-compatible upstream that echoes the submitted prompt so the replacement text is deterministic. Setup, entirely through the ordinary API: an administrator creates two further accounts, Alice and Mallory, both with the plain user role and no additional permissions, creates a channel, and grants both accounts read and write access. Alice posts a message reading `ALICE ORIGINAL MESSAGE`. Nothing is written directly to the database. Control, through the dedicated route: ``` POST /api/v1/channels/<channel_id>/messages/<alice_message_id>/update Authorization: Bearer <mallory_token> {"content": "PWNED_BY_MALLORY"} -> 403 ``` Attack, submitting the same target id to the completions endpoint: ``` POST /api/chat/completions Authorization: Bearer <mallory_token> {"model": "<model>", "stream": true, "chat_id": "channel:<channel_id>", "id": "<alice_message_id>", "messages": [{"role": "user", "content": "PWNED_BY_MALLORY"}]} -> 200 ``` Reading the channel back afterwards shows the targeted message content replaced with the attacker's string while its recorded author is still Alice. ## Credits - **@Classic298** — identified that the completions path and the dedicated edit route disagreed on message authorship, and reproduced the cross-member overwrite end to end.

CVE-2026-87994 Affected Open WebUI Versions

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

References

Frequently Asked Questions

What is CVE-2026-87994?
CVE-2026-87994 is a security vulnerability in Open WebUI involving Channel members can overwrite another member's message via the chat completions endpoint 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-87994?
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-87994?
CVE-2026-87994 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-87994?
CVE-2026-87994 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-87994?
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-fmqh-xp37-5hr8",
  "modified" : "2026-09-10T15:10:29Z",
  "published" : "2026-09-10T15:10:29Z",
  "aliases" : [ "CVE-2026-87994" ],
  "summary" : "Open WebUI: Channel members can overwrite another member's message via the chat completions endpoint",
  "details" : "## Summary\nAny member of a channel who can post to it could also replace the text of a message written by a different member. The channel branch of the chat completions endpoint checked that the caller may write to the channel, and that the targeted message belongs to that channel, but never checked that the caller actually wrote the message being edited. The message kept its original author, so the replacement text was displayed and stored as though the victim had written it. The dedicated channel message edit route performed the authorship check correctly and refused the same edit, so the two paths disagreed about who may modify a message.\n\n## Preconditions\n- Channels must be enabled. `ENABLE_CHANNELS` defaults to `False`, so a default deployment is not affected until an administrator turns channels on.\n- The attacker must be an approved user holding write access to the target channel, which is the ordinary state for any participant. No elevated role, group membership or additional permission is needed, and the attacker does not need to be the channel owner.\n- The attacker must know the id of the targeted message. That id is returned to every member who reads the channel, so it requires no further access.\n- Channels the attacker cannot post to are not affected, and neither are deployments with channels disabled.\n\n## Impact\nAn attacker can rewrite what another member said, under that member's name, in a shared channel. The stored record and every later reader show the victim as the author of text they never wrote, so this is a loss of both integrity and non-repudiation: the victim cannot point to the record to show what they actually said. A conversation can be silently altered after the fact rather than only appended to.\n\nHow much control the attacker has over the replacement text depends on the configured model, because the text is produced by generating a completion into the victim's message. Reducing a message to unrelated or empty content works regardless of the model, while reproducing an exact attacker-chosen string requires a model that returns the supplied prompt closely enough. The attack grants no new role or permission, does not reach channels the attacker cannot already post to, and exposes no message content they could not already read.\n\n## Fix\nFixed in 0.11.1 by commit `7d392bedc` (#28631). The gate on the channel branch now also compares the targeted message's author against the calling user and refuses when they differ, which is the condition the dedicated channel message update route already applied. Administrators retain the ability to edit any message, on both paths, as before. Upgrading to 0.11.1 fully resolves this, and no configuration change is required.\n\n## Root cause\nAffected components:\n- the channel branch of the chat completions handler, which resolves a client-supplied message id for editing\n- the channel event emitter, which re-checks the message before persisting the update\n\nNot affected: the dedicated channel message update route, which already held the correct check.\n\nThe channel branch was written to answer the question of whether the caller may write into this channel and whether the message belongs to it. Both of those checks were present and effective. The question it never asked was whether the caller wrote the message. Ownership of a channel message is carried by the message record rather than by the channel, so channel-level write access was treated as sufficient authority over every message inside it. The dedicated edit route grew the authorship comparison because editing is its only purpose, while the completions path reached the same operation through a general-purpose entry point and inherited only the coarser channel check.\n\n## Proof of concept\nReproduced against a running instance built from the development branch, with channels enabled and an OpenAI-compatible upstream that echoes the submitted prompt so the replacement text is deterministic.\n\nSetup, entirely through the ordinary API: an administrator creates two further accounts, Alice and Mallory, both with the plain user role and no additional permissions, creates a channel, and grants both accounts read and write access. Alice posts a message reading `ALICE ORIGINAL MESSAGE`. Nothing is written directly to the database.\n\nControl, through the dedicated route:\n\n```\nPOST /api/v1/channels/<channel_id>/messages/<alice_message_id>/update\nAuthorization: Bearer <mallory_token>\n{\"content\": \"PWNED_BY_MALLORY\"}\n-> 403\n```\n\nAttack, submitting the same target id to the completions endpoint:\n\n```\nPOST /api/chat/completions\nAuthorization: Bearer <mallory_token>\n{\"model\": \"<model>\", \"stream\": true,\n \"chat_id\": \"channel:<channel_id>\",\n \"id\": \"<alice_message_id>\",\n \"messages\": [{\"role\": \"user\", \"content\": \"PWNED_BY_MALLORY\"}]}\n-> 200\n```\n\nReading the channel back afterwards shows the targeted message content replaced with the attacker's string while its recorded author is still Alice.\n\n## Credits\n- **@Classic298** — identified that the completions path and the dedicated edit route disagreed on message authorship, and reproduced the cross-member overwrite end to end.",
  "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.9.5"
      }, {
        "fixed" : "0.11.1"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/security/advisories/GHSA-fmqh-xp37-5hr8"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-87994"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/pull/28631"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/open-webui/open-webui/commit/7d392bedc9c1aaecc94509a58e59186b614433dc"
  }, {
    "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:29Z",
    "nvd_published_at" : "2026-09-09T22:18:47Z"
  }
}