Affected: open-webui

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. Prior to 0.10.0, channel thread parent and reply handling did not bind parent_id to the channel in the URL, allowing an authenticated user to reference a message from another private or DM channel and disclose thread context across channels. This issue is fixed in version 0.10.0.

Affected: PyPI: open-webui

## Summary

A normal authenticated user can read the content of a message in a private channel they do not belong to. `GET /api/v1/channels/{id}/messages/{message_id}/thread` authorizes the caller against the URL channel, but the underlying thread lookup loads the thread *parent* by id and returns it without verifying the parent belongs to that channel. By requesting a thread in a channel they can access while supplying a victim channel's message id as the thread root, the attacker receives the victim message — content, channel id, and author.

## Affected component

- `backend/open_webui/models/messages.py` — `get_messages_by_parent_id()` - `backend/open_webui/routers/channels.py` — `get_channel_thread_messages()` (read), `new_message_handler()` (parent/reply binding on write)

## Root cause

`get_messages_by_parent_id(channel_id, parent_id)` filters the thread *replies* by `channel_id`, but loads the thread *parent* by id alone and appends it without requiring `parent.channel_id == channel_id`:

```python message = await db.get(Message, parent_id) # loaded by id only — no channel binding if not message: return [] # replies are filtered by channel_id ... if len(all_messages) < limit: all_messages.append(message) # parent appended unconditionally ```

`get_channel_thread_messages()` authorizes only the URL channel, then calls `get_messages_by_parent_id(id, message_id)` with the caller-supplied `message_id`. The reply insert path (`new_message_handle…