github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-07-17 08:21:12 -05:00
Code Issues 2.4k Packages Projects Releases 129 Wiki Activity

issue: Allow Multiple Models in Chat permission bypass via chat import & sharing #5553

New Issue
Closed
opened 2025-11-11 16:24:16 -06:00 by GiteaMirror · 2 comments
GiteaMirror commented 2025-11-11 16:24:16 -06:00
Owner
Copy Link

Originally created by @silentoplayz on GitHub (Jun 16, 2025).

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.14

Ollama Version (if applicable)

v0.9.0

Operating System

Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0

Browser (if applicable)

LibreWolf v135.0.1-1 (Firefox)

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

If a user or a usergroup does not have the Allow Multiple Models in Chat permission enabled, they should be strictly limited to using only one model per chat session. This restriction should apply universally, including to imported chats and shared chats.

Specifically, when importing a chat or accessing a shared chat:

  1. If the imported/shared chat contains multiple models and the importing/accessing user lacks the Allow Multiple Models in Chat permission, the system should either:
    • Reject the import/access to that multi-model configuration.
    • Or, import/open the chat but automatically revert it to a single-model configuration (e.g., by selecting only the first model, or the default model) for that user and not allowing the user to select another model beyond only one.
  2. Cloning an imported or shared multi-model chat should also strictly respect the cloning user's current permissions regarding multiple models.

Actual Behavior

Users who do not have the Allow Multiple Models in Chat permission can bypass this restriction through two distinct methods:

  1. Importing a chat: By importing a .json chat file that was previously exported with multiple models selected, the user gains access to a multi-model chat session.
  2. Accessing a shared chat: By accessing a chat that was shared with them and contains multiple models, the user gains access to a multi-model chat session if they clone the shared chat into their own chats list.

In both bypass scenarios, once the multi-model chat is accessed (either via import or sharing), the user can interact with it, and crucially, they can clone it. The imported/cloned chat also retains the multi-model functionality, allowing them to effectively use multiple models indefinitely by cloning. They can also change the specific models selected in the cloned chat to any other models available to them, while still maintaining the multi-model capability.

Steps to Reproduce

Part 1: Admin Setup (Preparing Multi-Model Chat & Permissions)

  1. Log in to Open WebUI as an Administrator.
  2. Navigate to Admin Panel > Users > Groups.
  3. Create a new user (e.g., testuser) or identify an existing user/user group for whom you intend to disable the Allow Multiple Models in Chat permission. Ensure this user is not an Admin, but a User.
  4. For the testuser's role (or the specific user), disable the Allow Multiple Models in Chat permission. Save changes.
  5. Still logged in as an Administrator, start a new chat.
  6. In the model dropdown, select more than one model (e.g., llama3 and mistral).
  7. Send a message in this chat to ensure the multi-model configuration is triggered.
  8. For Bypass Method 1 (Import): Hover the mouse pointer over the "Download" button (found in the chat options) and then click the Export chat (.json) option. Save the .json file somewhere to your computer.
  9. For Bypass Method 2 (Sharing): Click the "Share Chat" button. Click Copy Link to copy the sharable chat link. Keep it copied to your device's clipboard.

Part 2A: User Reproduction (Bypass Method 1: Import)

  1. Log out of the Administrator account.
  2. Log in as the testuser (the user for whom Allow Multiple Models in Chat was disabled).
  3. Navigate to the Settings page and click on the Chats tab.
  4. Click on the "Import Chats" button.
  5. Select and import the .json file saved in Step 8 of Part 1.
    • Observe: The imported chat loads successfully. When you view the chat, the model dropdown for that chat displays multiple models selected, despite testuser's permissions.
  6. Send a message within this newly imported multi-model chat.
    • Observe: The chat functions correctly using responses from multiple models, demonstrating the permission bypass.
  7. With the imported chat active, click on the "Clone Chat" button in the chat options.
    • Observe: The cloned chat also has multiple models selected in its dropdown, inheriting the multi-model configuration.
    • Observe: You can change the specific models selected in the cloned chat's dropdown (as long as they are available to the user), and it still functions as a multi-model chat.

Part 2B: User Reproduction (Bypass Method 2: Shared Chat)

  1. Ensure testuser is still logged in (or log in again if necessary).
  2. Paste the shareable link obtained in Step 9 of Part 1 from the admin into your browser's address bar within a new tab and navigate to it.
    • Observe: The shared chat loads successfully. Click Clone at the bottom of the chat to clone it into your chats list as a user.
  3. Send a message within this newly accessed multi-model chat.
    • Observe: The chat functions correctly using responses from multiple models, demonstrating the permission bypass.
  4. With the shared chat active, click on the "Clone Chat" button.
    • Observe: The cloned chat also has multiple models selected in its dropdown, inheriting the multi-model configuration.
    • Observe: You can change the specific models selected in the cloned chat's dropdown (as long as they are available to the user), and it still functions as a multi-model chat.

Logs & Screenshots

https://github.com/user-attachments/assets/f1e8c804-1959-49a8-85ac-2892682ed353

Additional Information

This issue presents a significant security and access control vulnerability. The Allow Multiple Models in Chat permission is intended to restrict certain users or roles from utilizing multi-model capabilities, potentially to manage resource consumption, control access to specific model combinations, or enforce policy. The current behavior allows simple import or chat sharing operations to completely circumvent this established permission, leading to:

  • Undermined Permissions: The permission system is ineffective if easily bypassed by common chat operations.
  • Unintended Resource Usage: Users restricted from multi-model chats may still trigger higher resource usage on the server.
  • Configuration Drift: Administrators might believe permissions are enforced when, in reality, users have ways to bypass them.

A robust solution should consistently validate imported and shared chat configurations against the accessing user's real-time permissions, ensuring consistency and preventing unauthorized feature access.

Originally created by @silentoplayz on GitHub (Jun 16, 2025). ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.14 ### Ollama Version (if applicable) v0.9.0 ### Operating System Edition: Windows 11 Pro | Version: 24H2 | OS Build: 26100.4351 | Windows Feature Experience Pack: 1000.26100.107.0 ### Browser (if applicable) LibreWolf v135.0.1-1 (Firefox) ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior If a user or a usergroup does not have the `Allow Multiple Models in Chat` permission enabled, they should be strictly limited to using only one model per chat session. This restriction should apply universally, including to imported chats and shared chats. Specifically, when importing a chat or accessing a shared chat: 1. If the imported/shared chat contains multiple models and the importing/accessing user lacks the `Allow Multiple Models in Chat` permission, the system should either: * Reject the import/access to that multi-model configuration. * Or, import/open the chat but automatically revert it to a single-model configuration (e.g., by selecting only the first model, or the default model) for that user and not allowing the user to select another model beyond only one. 2. Cloning an imported or shared multi-model chat should also strictly respect the cloning user's current permissions regarding multiple models. ### Actual Behavior Users who do *not* have the `Allow Multiple Models in Chat` permission can bypass this restriction through **two distinct methods**: 1. **Importing a chat:** By importing a `.json` chat file that was previously exported with multiple models selected, the user gains access to a multi-model chat session. 2. **Accessing a shared chat:** By accessing a chat that was shared with them and contains multiple models, the user gains access to a multi-model chat session if they clone the shared chat into their own chats list. In both bypass scenarios, once the multi-model chat is accessed (either via import or sharing), the user can interact with it, and crucially, they can **clone** it. The imported/cloned chat also retains the multi-model functionality, allowing them to effectively use multiple models indefinitely by cloning. They can also change the specific models selected in the cloned chat to any other models available to them, while still maintaining the multi-model capability. ### Steps to Reproduce **Part 1: Admin Setup (Preparing Multi-Model Chat & Permissions)** 1. Log in to Open WebUI as an Administrator. 2. Navigate to `Admin Panel` > `Users` > `Groups`. 3. Create a new user (e.g., `testuser`) or identify an existing user/user group for whom you intend to *disable* the `Allow Multiple Models in Chat` permission. Ensure this user is *not* an `Admin`, but a `User`. 4. For the `testuser`'s role (or the specific user), **disable** the `Allow Multiple Models in Chat` permission. Save changes. 5. Still logged in as an Administrator, start a new chat. 6. In the model dropdown, select **more than one** model (e.g., `llama3` and `mistral`). 7. Send a message in this chat to ensure the multi-model configuration is triggered. 8. **For Bypass Method 1 (Import):** Hover the mouse pointer over the "Download" button (found in the chat options) and then click the `Export chat (.json)` option. Save the `.json` file somewhere to your computer. 9. **For Bypass Method 2 (Sharing):** Click the "Share Chat" button. Click `Copy Link` to copy the sharable chat link. Keep it copied to your device's clipboard. **Part 2A: User Reproduction (Bypass Method 1: Import)** 10. Log out of the Administrator account. 11. Log in as the `testuser` (the user for whom `Allow Multiple Models in Chat` was disabled). 12. Navigate to the `Settings` page and click on the `Chats` tab. 13. Click on the "Import Chats" button. 14. Select and import the `.json` file saved in Step 8 of **Part 1**. * **Observe:** The imported chat loads successfully. When you view the chat, the model dropdown for that chat displays **multiple models selected**, despite `testuser`'s permissions. 15. Send a message within this newly imported multi-model chat. * **Observe:** The chat functions correctly using responses from multiple models, demonstrating the permission bypass. 16. With the imported chat active, click on the "Clone Chat" button in the chat options. * **Observe:** The cloned chat also has multiple models selected in its dropdown, inheriting the multi-model configuration. * **Observe:** You can change the specific models selected in the cloned chat's dropdown (as long as they are available to the user), and it still functions as a multi-model chat. **Part 2B: User Reproduction (Bypass Method 2: Shared Chat)** 17. Ensure `testuser` is still logged in (or log in again if necessary). 18. Paste the shareable link obtained in Step 9 of **Part 1** from the admin into your browser's address bar within a new tab and navigate to it. * **Observe:** The shared chat loads successfully. Click `Clone` at the bottom of the chat to clone it into your chats list as a user. 19. Send a message within this newly accessed multi-model chat. * **Observe:** The chat functions correctly using responses from multiple models, demonstrating the permission bypass. 20. With the shared chat active, click on the "Clone Chat" button. * **Observe:** The cloned chat also has multiple models selected in its dropdown, inheriting the multi-model configuration. * **Observe:** You can change the specific models selected in the cloned chat's dropdown (as long as they are available to the user), and it still functions as a multi-model chat. ### Logs & Screenshots https://github.com/user-attachments/assets/f1e8c804-1959-49a8-85ac-2892682ed353 ### Additional Information This issue presents a significant security and access control vulnerability. The `Allow Multiple Models in Chat` permission is intended to restrict certain users or roles from utilizing multi-model capabilities, potentially to manage resource consumption, control access to specific model combinations, or enforce policy. The current behavior allows simple import or chat sharing operations to completely circumvent this established permission, leading to: * **Undermined Permissions:** The permission system is ineffective if easily bypassed by common chat operations. * **Unintended Resource Usage:** Users restricted from multi-model chats may still trigger higher resource usage on the server. * **Configuration Drift:** Administrators might believe permissions are enforced when, in reality, users have ways to bypass them. A robust solution should consistently validate imported and shared chat configurations against the accessing user's real-time permissions, ensuring consistency and preventing unauthorized feature access.
GiteaMirror added the bug label 2025-11-11 16:24:16 -06:00
GiteaMirror commented 2025-11-11 16:24:16 -06:00
Author
Owner
Copy Link

@tjbck commented on GitHub (Jun 16, 2025):

Addressed with a47e3b429e327c0ae07c886ac98f461b23807f5a!

@tjbck commented on GitHub (Jun 16, 2025): Addressed with a47e3b429e327c0ae07c886ac98f461b23807f5a!
GiteaMirror commented 2025-11-11 16:24:17 -06:00
Author
Owner
Copy Link

@silentoplayz commented on GitHub (Jun 16, 2025):

Addressed with a47e3b4!

Awesome! I can confirm that this commit does indeed mitigate the reported issues in this thread. Thanks for the speedy fix!

@silentoplayz commented on GitHub (Jun 16, 2025): > Addressed with [a47e3b4](https://github.com/open-webui/open-webui/commit/a47e3b429e327c0ae07c886ac98f461b23807f5a)! Awesome! I can confirm that this commit does indeed mitigate the reported issues in this thread. Thanks for the speedy fix!
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
confirmed
confirmed issue
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#5553
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?