SA-26-393 High

Open WebUI: Cross-channel message overwrite via chat completion API (single-model and multimodel…

Open WebUI

Severity
High, CVSS 7.1
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L
Record
CVE-2026-59714
Affects
Open WebUI
Known exploited
Not listed in the CISA Known Exploited Vulnerabilities catalog
Published
Record first published by the source
July 24, 2026
Source last modified
July 24, 2026

Description

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(...)

2. 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.

3. 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.

Description quoted from the NVD record.

Who is affected

Open WebUI is a chat interface for working with AI models. This flaw affects version 0.9.5 and later versions before 0.10.0, including 0.9.6, which fixed only part of the problem. Any user who can sign in could change the text of a message in a channel they do not belong to, including private channels and direct messages. They do this through the part of the product that sends chat requests to AI models. The changed message still shows the original author's name, so it could be used to impersonate a colleague. This flaw is rated High.

What to do

  1. Find out who runs Open WebUI for your organization: the person who installed it, or the IT provider or vendor who manages it for you.
  2. If your organization runs it yourselves, have that person update Open WebUI to version 0.10.0 or later. Version 0.9.6 does not fully fix this flaw.
  3. If an IT provider or vendor runs it for you, send them this advisory and ask when the update to 0.10.0 will be done.
  4. After the update, have the person who runs it check that Open WebUI now shows version 0.10.0 or later.

Analysis written from the source record as of July 24, 2026 and reviewed before publishing.

Sources

MORE ADVISORIES

See all