fix: Default prompt permissions to respect user access rights
Pull Request Checklist
Pull Request Checklist
Target branch: This PR targets the dev branch
Description: A detailed description of the security vulnerability and fix is provided
Changelog: Added below
Documentation: No documentation updates needed as this maintains existing functionality but fixes security
Dependencies: No new dependencies added
Testing: I've verified the logic, but request maintainer testing with various permission configurations
Code review: Self-reviewed for security implications and code correctness
Prefix: Used "fix" as this addresses a security vulnerability
Description
This PR addresses a security vulnerability where prompts could be unintentionally shared with all users, bypassing access control restrictions. When users create prompts without explicitly setting access control permissions (by not clicking the "Access" button), the system defaults to public access (null) even when users don't have permission to create public prompts or the admin has disabled public sharing.
Vulnerability details:
What is the vulnerability / how to execute the vulnerability:
By default, all prompts are created with accessControl = null (public access), unless the user manually, explicitly opens the access-settings when creating a new prompt - in that case, his actual permissions would be loaded and correctly set. If the user never opens the access settings during prompt creation, the prompt is always saved as a public prompt, regardless of public sharing permissions.
When a user doesn't open the access control modal during prompt creation, they inadvertently, always create public prompts
This results in private/sensitive prompts being exposed to all users when they type / in the chat interface
Important note to maintainer (Tim):
While I've carefully reviewed the changes, I kindly request your additional verification and testing. The scope was intentionally kept narrow to address just the vulnerability without introducing regressions.
Impact:
Based on CVSS, this would likely score as a Medium severity vulnerability due to the unauthorized information disclosure across user boundaries with no special privileges required to exploit.
If you are affected: How to fix?
If you are affected by this here is a fix for affected prompts: As a user:
Edit all your prompts, open the access settings and ensure it is set to private, then save the prompt.
As an admin:
Edit all the prompts that your users created and check the access settings. If the access settings show "Public", then this prompt is affected by the vulnerability (user did not open access settings during prompt creation). Change it to private and save the edited prompt. Do this for all prompts.
Solution
The fix modifies PromptEditor.svelte to default prompt access based on user permissions:
Users with public sharing permission still default to public prompts (backward compatible)
Users without public sharing permission now default to private prompts
Existing prompts maintain their current access control settings
** Does NOT change the default behaviour of the access settings when creating a prompt. If you have the ability to create public prompts, the default behaviour will remain to create public prompts. If you do not have the ability to create public prompts, your prompts will only be created privately **
This ensures the principle of least privilege - users can only share prompts publicly when they explicitly choose to AND have the permission to do so.
Changelog Entry
Changed
Changed default access control value to be based on user permissions rather than always public, regardless of the user's permissions set by admins
Fixed
Fixed vulnerability where prompts could be unintentionally shared with all users
Fixed access control defaults to respect user permissions set by admins
Security
Addressed information disclosure vulnerability with prompt sharing
Additional Information
Fixed missing comma for coding-style-guideline adherence in unrelated file
The fix should maintain full backward compatibility with existing prompts
This implements proper default security based on user permissions rather than requiring explicit action to make prompts private
This fix was co-created with AI (Claude 3.7 Sonnet)
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.
## 📋 Pull Request Information
**Original PR:** https://github.com/open-webui/open-webui/pull/12757
**Author:** [@Classic298](https://github.com/Classic298)
**Created:** 4/11/2025
**Status:** ❌ Closed
**Base:** `dev` ← **Head:** `dev`
---
### 📝 Commits (5)
- [`95d80ec`](https://github.com/open-webui/open-webui/commit/95d80ec50a7fae3d14f26657e47f5a0e66989ab0) Update __init__.py
- [`ebcc838`](https://github.com/open-webui/open-webui/commit/ebcc8384b22f2cdffe7395bfc6f4720f60e8c340) Merge branch 'open-webui:dev' into dev
- [`0d4a1dd`](https://github.com/open-webui/open-webui/commit/0d4a1dd6273f11a26bb4d0de536e4342e5c979e6) Merge branch 'open-webui:dev' into dev
- [`e5e6ac2`](https://github.com/open-webui/open-webui/commit/e5e6ac2500764f9d8d8fcc9a8d2c6931f406d672) Update PromptEditor.svelte
- [`ea537bd`](https://github.com/open-webui/open-webui/commit/ea537bd2db3a1375cc1b5c61309eeeacbfb4b6f6) Update PromptEditor.svelte
### 📊 Changes
**2 files changed** (+5 additions, -3 deletions)
<details>
<summary>View changed files</summary>
📝 `backend/open_webui/__init__.py` (+1 -1)
📝 `src/lib/components/workspace/Prompts/PromptEditor.svelte` (+4 -2)
</details>
### 📄 Description
# fix: Default prompt permissions to respect user access rights
**Pull Request Checklist**
## Pull Request Checklist
- [x] **Target branch:** This PR targets the `dev` branch
- [x] **Description:** A detailed description of the security vulnerability and fix is provided
- [x] **Changelog:** Added below
- [X] **Documentation:** No documentation updates needed as this maintains existing functionality but fixes security
- [X] **Dependencies:** No new dependencies added
- [ ] **Testing:** I've verified the logic, but request maintainer testing with various permission configurations
- [x] **Code review:** Self-reviewed for security implications and code correctness
- [x] **Prefix:** Used "fix" as this addresses a security vulnerability
## Description
This PR addresses a security vulnerability where prompts could be unintentionally shared with all users, bypassing access control restrictions. When users create prompts without explicitly setting access control permissions (by not clicking the "Access" button), the system defaults to public access (`null`) _even when users don't have permission to create public prompts or the admin has disabled public sharing._
**Vulnerability details:**
What is the vulnerability / how to execute the vulnerability:
- By default, all prompts are created with `accessControl = null` (public access), unless the user manually, explicitly opens the access-settings when creating a new prompt - in that case, his actual permissions would be loaded and correctly set. If the user never opens the access settings during prompt creation, the prompt is **always saved as a public prompt, regardless of public sharing permissions.**
- When a user doesn't open the access control modal during prompt creation, they inadvertently, always create public prompts
- This results in private/sensitive prompts being exposed to all users when they type `/` in the chat interface
**Important note to maintainer (Tim):**
While I've carefully reviewed the changes, I kindly request your additional verification and testing. The scope was intentionally kept narrow to address just the vulnerability without introducing regressions.
**Impact:**
Based on CVSS, this would likely score as a Medium severity vulnerability due to the unauthorized information disclosure across user boundaries with no special privileges required to exploit.
## **If you are affected: How to fix?**
If you are affected by this here is a fix for affected prompts:
**As a user:**
Edit all your prompts, open the access settings and ensure it is set to private, then save the prompt.
**As an admin:**
Edit all the prompts that your users created and check the access settings. If the access settings show "Public", then this prompt is affected by the vulnerability (user did not open access settings during prompt creation). Change it to private and save the edited prompt. Do this for all prompts.
## Solution
The fix modifies `PromptEditor.svelte` to default prompt access based on user permissions:
- Users with public sharing permission still default to public prompts (backward compatible)
- Users without public sharing permission now default to private prompts
- Existing prompts maintain their current access control settings
- \*\* **Does NOT change the default behaviour of the access settings when creating a prompt. If you have the ability to create public prompts, the default behaviour will remain to create public prompts. If you do not have the ability to create public prompts, your prompts will only be created privately** \*\*
This ensures the principle of least privilege - users can only share prompts publicly when they explicitly choose to AND have the permission to do so.
## Changelog Entry
### Changed
- Changed default access control value to be based on user permissions rather than always public, regardless of the user's permissions set by admins
### Fixed
- Fixed vulnerability where prompts could be unintentionally shared with all users
- Fixed access control defaults to respect user permissions set by admins
### Security
- Addressed information disclosure vulnerability with prompt sharing
---
### Additional Information
- Fixed missing comma for coding-style-guideline adherence in unrelated file
- The fix should maintain full backward compatibility with existing prompts
- This implements proper default security based on user permissions rather than requiring explicit action to make prompts private
- This fix was co-created with AI (Claude 3.7 Sonnet)
### Related Issue / Discussion
- Originally identified in issue: https://github.com/open-webui/open-webui/issues/12690
- Later discussed here: https://github.com/open-webui/open-webui/discussions/12718
- Related: https://github.com/open-webui/open-webui/issues/8586
---
<sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
📋 Pull Request Information
Original PR: https://github.com/open-webui/open-webui/pull/12757
Author: @Classic298
Created: 4/11/2025
Status: ❌ Closed
Base:
dev← Head:dev📝 Commits (5)
95d80ecUpdate __init__.pyebcc838Merge branch 'open-webui:dev' into dev0d4a1ddMerge branch 'open-webui:dev' into deve5e6ac2Update PromptEditor.svelteea537bdUpdate PromptEditor.svelte📊 Changes
2 files changed (+5 additions, -3 deletions)
View changed files
📝
backend/open_webui/__init__.py(+1 -1)📝
src/lib/components/workspace/Prompts/PromptEditor.svelte(+4 -2)📄 Description
fix: Default prompt permissions to respect user access rights
Pull Request Checklist
Pull Request Checklist
devbranchDescription
This PR addresses a security vulnerability where prompts could be unintentionally shared with all users, bypassing access control restrictions. When users create prompts without explicitly setting access control permissions (by not clicking the "Access" button), the system defaults to public access (
null) even when users don't have permission to create public prompts or the admin has disabled public sharing.Vulnerability details:
What is the vulnerability / how to execute the vulnerability:
accessControl = null(public access), unless the user manually, explicitly opens the access-settings when creating a new prompt - in that case, his actual permissions would be loaded and correctly set. If the user never opens the access settings during prompt creation, the prompt is always saved as a public prompt, regardless of public sharing permissions./in the chat interfaceImportant note to maintainer (Tim):
While I've carefully reviewed the changes, I kindly request your additional verification and testing. The scope was intentionally kept narrow to address just the vulnerability without introducing regressions.
Impact:
Based on CVSS, this would likely score as a Medium severity vulnerability due to the unauthorized information disclosure across user boundaries with no special privileges required to exploit.
If you are affected: How to fix?
If you are affected by this here is a fix for affected prompts:
As a user:
Edit all your prompts, open the access settings and ensure it is set to private, then save the prompt.
As an admin:
Edit all the prompts that your users created and check the access settings. If the access settings show "Public", then this prompt is affected by the vulnerability (user did not open access settings during prompt creation). Change it to private and save the edited prompt. Do this for all prompts.
Solution
The fix modifies
PromptEditor.svelteto default prompt access based on user permissions:This ensures the principle of least privilege - users can only share prompts publicly when they explicitly choose to AND have the permission to do so.
Changelog Entry
Changed
Fixed
Security
Additional Information
Related Issue / Discussion
🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.