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

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

Summary

A member of a shared folder who once had write access and was later downgraded to read-only could keep adding new chats to that folder. Forking a chat they had created in the folder while they could still write produced a new chat inside the same folder, without checking whether they could still write there. The new chat then appears to everyone who can read the folder. Direct chat creation, chat moves and chat completions already enforced folder write access; the fork action did not.

Preconditions

• An authenticated account of any role that was given write access to a shared folder and later downgraded to read-only by the folder owner.
• The member created at least one chat in that folder while they still had write access.
• Folders enabled, which is the default (ENABLE_FOLDERS=true, USER_PERMISSIONS_FEATURES_FOLDERS=true), and the chat import permission, which forking requires and which ordinary users hold by default (USER_PERMISSIONS_CHAT_IMPORT=true).
• Folders that were never shared with write access, and members who never had write access, are not affected.

Impact

The integrity of shared folder contents. Revoking a member's write access did not stop them from adding entries: using the chat they created earlier, they could fork it any number of times, and each fork shows up in the shared folder for the owner and every other member, under a title and with content the attacker controls. The owner has no signal that the downgrade was ineffective.

Nothing is disclosed to the attacker and nothing belonging to other users is changed or deleted. Availability is unaffected.

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)