CVE-2026-70481: Open WebUI: members can edit/delete others' channel 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.

An organization enables open-webui channels for team collaboration around AI workflows and grants a standard channel public write access so any employee can participate. A disgruntled or compromised low-privilege employee account calls the channel's message-listing endpoint to enumerate message IDs belonging to a colleague, then issues an authenticated POST to the update-message endpoint for a message they didn't write — the handler checks only that the caller has channel write access, not authorship, so the request succeeds and the colleague's message is silently rewritten while still displaying as authored by the original user. The same account then issues DELETE requests against other members' messages to erase parts of the channel's history, for example scrubbing evidence of a flagged AI output or an incident discussion, with no elevated role or channel ownership ever required.