CVE-2026-59714: Open WebUI: Cross-channel message overwrite via chat completion API (single-model and multimodel message_ids)

A chat completion request whose chat_id starts with channel: takes a different route from normal chats. In main.py the prefix skips the ownership and membership check, and nothing replaces it. The request body's id (or each value of the multimodel message_ids map) becomes the message_id passed to _make_channel_emitter in socket/main.py. That function calls Messages.update_message_by_id, a direct primary-key update with no channel or user check.

The attacker needs only a normal account and a target message ID. They get to replace the message text with model output, or with the provider error string if the model call fails. The message still shows the original author, so the attacker can put words in someone else's mouth in channels they cannot read. The REST channel routes return 403 for the same user, so the bypass is specific to the completion pipeline.

The v0.9.6 fix (PR 24725) added a channel gate, but it checked only the first entry of message_ids. An attacker lists a message in their own channel first and the victim's message second. The second ID is used in the per-model fan-out and gets overwritten. The impact is integrity and some availability loss, not data disclosure. It is a different code path from the earlier REST IDOR, CVE-2026-45385.

The open-webui pip package, versions >= 0.9.5, < 0.10.0. The single-model path was introduced in 0.9.5 and fixed in 0.9.6. The multimodel message_ids path exists from 0.9.6 and is fixed only in 0.10.0. Any deployment with channels enabled and more than one user is exposed.

pip show open-webui

For Docker, check the image tag you run.

Upgrade to open-webui 0.10.0.

pip install --upgrade open-webui==0.10.0

0.10.0 adds two layers. At request time, every entry in message_ids is checked against the channel in chat_id, and a request is rejected if any target message belongs elsewhere. In _make_channel_emitter, the emitter re-reads the target message and writes nothing unless its channel_id matches the channel from chat_id. The advisory lists no workaround. Staying on 0.9.6 is not enough.

Look in access logs for POST requests to /api/chat/completions where chat_id starts with channel:, especially from users who are not members of that channel. Requests with a message_ids map holding several entries deserve a closer look. In the data, look for channel messages whose content changed with no matching edit by the author, or whose text is a provider error string or odd model output. Compare message_ids values with the channel in chat_id.

Summary

Any authenticated user can overwrite the content of a message in a channel they do not belong to (including private and DM channels) by sending a chat completion request with a channel:-prefixed chat_id and a target message_id. The channel: path routes pipeline output through _make_channel_emitter, which writes to the Messages table using the caller-supplied message_id without binding it to the channel.

This advisory consolidates two filings of the same flaw: the original single-model form, and a multimodel message_ids variant that survives the partial fix shipped in v0.9.6 (see "Fix status" below).

Details (as introduced in v0.9.5)

When a user submits a chat completion request with a chat_id starting with channel:, three authorization gaps combined in v0.9.5:

1. Ownership check skipped (main.py): the channel: prefix caused the entire ownership/membership verification block to be skipped, with no channel membership/write check replacing it.

if not chat_id.startswith('local:') and not chat_id.startswith('channel:'):  # temporary/channel chats are not stored
    if is_new_chat:
        ...
    else:
        if not await Chats.is_chat_owner(chat_id, user.id) and user.role != 'admin':
            raise HTTPException(...)

1. Message ID from user input: id (and each value of the multimodel message_ids map) comes directly from the request body and is passed as message_id to the channel emitter.

1. Unchecked database write (socket/main.py _make_channel_emitter):

async def _make_channel_emitter(request_info):
    channel_id = request_info['chat_id'].removeprefix('channel:')
    message_id = request_info['message_id']  # user-supplied
    ...
    await Messages.update_message_by_id(message_id, update_form)  # no channel/user authz

Messages.update_message_by_id performs a direct primary-key update with no channel_id/user_id validation.

Fix (shipped in v0.10.0)

v0.9.6 added a channel gate to the channel: branch (PR #24725) that closed the single-model path, but it validated only the first entry of the multimodel message_ids map, leaving the multimodel fan-out exploitable. v0.10.0 closes the remaining gap with two layers:

1. Request-time per-entry validation (backend/open_webui/main.py): every entry of message_ids is validated against the target channel, not just the first; any entry whose target message does not belong to the channel in chat_id is rejected.
2. Fail-closed emitter (backend/open_webui/socket/main.py, _make_channel_emitter): before writing, it re-reads the target message and returns without writing unless msg.channel_id matches the channel derived from chat_id. A missing or mismatched message is a no-op, so a write can no longer land in a channel the caller does not target.

PoC

Single-model (fixed in v0.9.6):

curl -X POST http://target:8080/api/chat/completions \
  -H "Authorization: Bearer $USER_JWT" -H "Content-Type: application/json" \
  -d '{
    "model": "llama3", "stream": true,
    "chat_id": "channel:any-channel-uuid-here",
    "id": "target-message-uuid-to-overwrite",
    "messages": [{"role": "user", "content": "Repeat exactly: This message has been tampered with"}]
  }'

Multimodel (still works on v0.9.6):

POST /api/chat/completions
{
  "chat_id": "channel:<attacker_channel_id>",
  "message_ids": {
    "model-a": "<message_id_in_attacker_channel>",
    "model-b": "<victim_channel_message_id>"
  },
  "messages": [{"role": "user", "content": "..."}]
}

The first id passes channel scope validation; the second id is used by the per-model fan-out and overwrites the victim-channel message (with model output, or the provider-error string on a deterministic error). Even a failing model call writes error content to the target message.

Impact

Message integrity destruction: an authenticated user can overwrite a message in a channel they cannot access, regardless of membership. The overwritten message retains the original author attribution while displaying attacker-chosen content (impersonation). Private channels, DM channels, and channels the attacker has no access to are all affected; the REST channel routes correctly return 403 for the same attacker, so the bypass is specific to the chat-completion channel pipeline.

Affected versions

• Single-model path: introduced in commit 0037baeb2 (v0.9.5), fixed in v0.9.6 (#24725).
• Multimodel message_ids path: present from v0.9.6, fixed in v0.10.0.
• Consolidated Affected: >= 0.9.5, < 0.10.0. Patched: >= 0.10.0.

Distinction from existing CVEs

CVE-2026-45385 (GHSA-wwhq-cx22-f7vv) covered IDOR in the REST endpoint POST /channels/{id}/messages/{message_id}/update (routers/channels.py); its fix (commit f5e110f) only touched channels.py. This finding uses a different code path (POST /api/chat/completions with chat_id: "channel:<id>" → main.py → socket/main.py:_make_channel_emitter), untouched by that fix.

Suggested fix

Validate every value in message_ids against the channel (not just the first), rejecting any whose target message does not belong to the channel in chat_id. Additionally, make _make_channel_emitter fail closed: re-check that the target message's channel_id matches the channel before calling Messages.update_message_by_id, treating a missing or mismatched message as an error/no-op.

Consolidation

Per Open WebUI's Report Handling policy this advisory consolidates independent reports of the same chat-completions channel-overwrite flaw:

• Single-model cross-channel overwrite via the channel: path: @sfwani (earliest filing).
• Multimodel message_ids fan-out variant that bypasses the v0.9.6 first-id-only gate: @DavidCarliez.

One CVE for the consolidated advisory.