Read-only shared folder members can still add chats to the folder by forking

Upgrade to 0.11.4

Fix

Fixed in 0.11.4 by https://github.com/open-webui/open-webui/pull/30069. A fork now keeps the source chat's folder only when the caller still has write access to it and is otherwise created outside any folder, matching chat creation and chat moves. Upgrading to 0.11.4 resolves it completely, with no configuration change required.

Root cause

Affected component: the chat fork handler in backend/open_webui/routers/chats.py, reached through POST /api/v1/chats/{id}/fork. Affected setup: every deployment on 0.11.0 through 0.11.3 with folders enabled.

The fork action was added in 0.11.0 and built the new chat by copying the folder of the source chat. Because the source chat belongs to the caller, the handler treated its folder as already authorized, but write access to a shared folder can be revoked after the chat was placed there. When the folder write check was consolidated into one shared helper for the other chat creation paths in 0.11.1, the fork path was not routed through it.

Proof of concept

Reproduced on running 0.11.3 and 0.11.4 instances with two accounts: an administrator acting as folder owner and an ordinary user acting as attacker.

1. The owner creates a folder and grants the attacker write access through POST /api/v1/folders/{id}/access/update.
2. The attacker creates a chat in that folder with POST /api/v1/chats/new.
3. The owner downgrades the attacker to read access. A direct POST /api/v1/chats/new into the folder is now rejected.
4. The attacker calls POST /api/v1/chats/{chat_id}/fork on the chat from step 2.
5. On 0.11.3 the fork is created with the shared folder's id and is listed by GET /api/v1/folders/{id}/shared/chats for both the attacker (folder_permission: read) and the owner. On 0.11.4 the fork is created outside any folder and does not appear in the listing.

Credits

• @avrlab233 (reporter)