Summary
Open WebUI: Channel members can overwrite another member's message via the chat completions endpoint
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_CHANNELSdefaults toFalse, 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.
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.
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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-87994 has a CVSS score of 4.3 (Medium). The vector is network-reachable, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (0.11.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-87994? CVE-2026-87994 is a medium-severity missing authorization vulnerability in open-webui (pip), affecting versions >= 0.9.5, < 0.11.1. It is fixed in 0.11.1. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-87994? CVE-2026-87994 has a CVSS score of 4.3 (Medium). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of open-webui are affected by CVE-2026-87994? open-webui (pip) versions >= 0.9.5, < 0.11.1 is affected.
- Is there a fix for CVE-2026-87994? Yes. CVE-2026-87994 is fixed in 0.11.1. Upgrade to this version or later.
- Is CVE-2026-87994 exploitable, and should I be worried? Whether CVE-2026-87994 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-87994 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-87994? Upgrade
open-webuito 0.11.1 or later.