CVE-2026-70481: Open WebUI: Any member with write access to a standard channel can edit or delete other members' messages

Two handlers in backend/open_webui/routers/channels.py are at fault: update_message_by_id (POST /api/v1/channels/{id}/messages/{message_id}/update) and delete_message_by_id (DELETE .../delete). For group and direct message channels, they asked whether the caller wrote the message. For standard channels, they asked only whether the caller may write in the channel. Posting needs the same grant, so every ordinary participant passed. The model layer looks up messages by primary key alone, so the router check was the only authorization.

The attacker is a plain user account with write access, granted publicly, per user or through a group. No channel ownership or manager role is needed. Channel and message ids come from the listing endpoints the member can already call.

They can replace the text of a colleague's message while it stays attributed to the original author, attach arbitrary data and meta payloads, or delete messages, up to the channel's whole visible history. That means forged content under someone else's name and destroyed records. It does not disclose anything beyond what a member could already read, and it does not reach other channels.

Open WebUI >= 0.5.0, <= 0.10.2 when an administrator has enabled channels (ENABLE_CHANNELS, off by default) and the channel is a standard channel. Group and direct message channels are not affected. Check the version:

pip show open-webui

Upgrade to 0.11.0:

pip install --upgrade open-webui==0.11.0

Commit c609ec411 (PR 27197) applies the authorship check that group and direct message channels already used, so a non-admin can act only on their own messages. No configuration change is needed. If you cannot upgrade yet, leaving ENABLE_CHANNELS off removes the exposure, since the sources say channels are disabled by default and required for the attack.

Compare channel history with what members say they posted. Look in access logs for POST /api/v1/channels/{id}/messages/{message_id}/update and DELETE calls where the caller is not the message author. Messages with unexpected data or meta fields, or gaps in channel history, are signs of abuse. Database backups let you recover deleted messages.

Summary

On standard channels, the message update and delete handlers accepted any caller holding write access on the channel, without checking that the caller wrote the message. Write access is the same grant a member needs in order to post, so every ordinary participant in a shared channel could rewrite or permanently delete any other participant's messages. The group and direct message branch of the same handlers enforced authorship; the standard branch did not.

Preconditions

Channels are disabled by default and must be enabled by an administrator (ENABLE_CHANNELS). The channel must be a standard channel; group and direct message channels are not affected. The attacker is any authenticated account with role user that holds write access on the channel, whether granted publicly, per user, or through a group. No ownership of the channel, channel manager role, or elevated role is required. Channel and message ids are returned by the listing endpoints the member can already call.

Impact

An ordinary member could replace the content of another member's message while the message stayed attributed to its original author, and could attach arbitrary data and meta payloads to it through the same form. The member could also permanently delete other members' messages, up to the entire visible history of the channel. This is an integrity and availability loss against other users of the channel: content can be forged under a colleague's name and records can be destroyed. It reaches no further than channels the attacker already has write access to, and it discloses nothing the attacker could not already read as a member. Pinning is unaffected and is not part of this issue.

Fix

Fixed in c609ec411 (#27197), released in 0.11.0. Both handlers now apply the same authorship check the group and direct message branch already used, so a non-admin caller can act only on their own messages regardless of write access. Upgrading fully resolves it, with no configuration change required.

Root cause

Affected components:

• backend/open_webui/routers/channels.py, update_message_by_id (POST /api/v1/channels/{id}/messages/{message_id}/update)
• backend/open_webui/routers/channels.py, delete_message_by_id (DELETE /api/v1/channels/{id}/messages/{message_id}/delete)

Both handlers branch on channel type, and the two branches asked different questions. The group and direct message branch asked whether the caller wrote the message. The standard branch asked whether the caller is allowed to write in the channel, which is a permission level, not an identity. Those are not interchangeable: posting a message runs that same write check, so the grant that lets a member participate was silently accepted as the grant to rewrite and remove everyone else's content, and every ordinary participant satisfied it. The model layer looks messages up by primary key alone, so the router branch was the only authorization that ran.

Proof of concept

Reported with a script that runs end to end against a live instance. An administrator seeds the accounts and a standard channel granting read and write; everything after that is performed by a separate plain user account in no group that owns neither the channel nor any of the messages. That account edits a victim's message, attaches structured payloads to it, and deletes a second victim message, all returning 200, with the channel history dumped before and after. Controls in the same run confirm the scoping: a read-only member is refused with 403, and a cross-member edit on a group channel is refused with 403.

Credits

@Foxer131 — reported the missing authorship check on the standard-channel update and delete handlers.