Open WebUI Shared Folder RBAC Bypass via Chat Forking (CVE-Required)

Vulnerability Overview Title: Read-only shared folder members can still add chats to the folder by forking Description: A shared folder member who previously had write permissions can continue to add chats they previously created to that folder, even after being downgraded to read-only permissions. This occurs because the system does not check whether the user still holds write permissions when creating a chat. Newly created chats will appear to all users who can read the folder. Direct creation, moving chats, and chat completion operations already enforce folder write permissions, but the fork operation does not. Impact Scope Affected Versions: >= 0.11.0, < 0.11.4 Fixed Version: 0.11.4 CVSS Score: 4.3 / 10 Attack Vector: Network Attack Complexity: Low Privileges Required: Low User Interaction: None Scope: Unchanged Confidentiality: None Integrity: Low Availability: None Remediation Fixed Version: 0.11.4 Fix Details: In version 0.11.4, a fork will only retain the source folder if the caller has write permissions to it. Otherwise, the fork will be created outside any folder, consistent with chat creation and chat movement behavior. Upgrading to 0.11.4 completely resolves this issue without requiring additional configuration changes. Prerequisites An authenticated account whose role previously granted write permissions to the shared folder but has since been downgraded to read-only permissions. The member has created at least one chat in the folder while possessing write permissions. The folder feature is enabled (enabled by default), and the chat import permission (held by regular users by default) is enabled. Folders never shared with write permissions, and members who never had write permissions, are unaffected. Impact The integrity of the shared folder's content is compromised. Revoking a member's write permissions does not prevent them from adding entries: using chats they created previously, they can fork them an arbitrary number of times. Each fork will appear in the shared folder of the owner and every other member, with the title and content controlled by the attacker. The owner receives no indication that the downgrade is ineffective. No information is disclosed to the attacker, nor are any other users' data changed or deleted. Availability is not impacted. Root Cause Affected Component: Chat fork handler located at , accessed via . Affected Configuration: Any deployment that had the folder feature enabled between versions 0.11.0 and 0.11.3. Root Cause: The fork operation, added in 0.11.0, constructs new chats by copying the source folder's folder. Since the source folder belongs to the caller, the handler considers it authorized; however, write permissions for the shared folder can be revoked after the chat is placed. In 0.11.1, when the folder write permission check was consolidated into a shared helper, the fork path within other chat creation routes was not redirected. Proof of Concept (PoC) 1. The owner creates a folder and grants the attacker write permissions via . 2. The attacker creates a chat within the folder that has write permissions via . 3. The owner downgrades the attacker to read-only permissions. Direct requests to the folder are now denied. 4. The attacker calls to fork the chat created in step 2. 5. In version 0.11.3, the fork is created using the shared folder's ID and is listed via for both the attacker ( ) and the owner. In version 0.11.4, the fork is created outside any folder and does not appear in the list. Credits Reporter: @avril233 Fix Developer: @classic298

Goal Reached Thanks to every supporter — we hit 100%!

Open WebUI Shared Folder RBAC Bypass via Chat Forking (CVE-Required)

More from this source