CVE-2026-70481

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

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