From fd0e9652a8c2dd1e970dd47c4d7430b26b81bbb9 Mon Sep 17 00:00:00 2001 From: Timothy Jaeryang Baek Date: Thu, 16 Oct 2025 11:36:26 -0500 Subject: [PATCH] chore: format --- docs/SECURITY.md | 19 +- .../admin/Settings/Documents.svelte | 162 +++++++++--------- 2 files changed, 95 insertions(+), 86 deletions(-) diff --git a/docs/SECURITY.md b/docs/SECURITY.md index 996c2c2f6..f08c46547 100644 --- a/docs/SECURITY.md +++ b/docs/SECURITY.md @@ -32,18 +32,20 @@ We appreciate the community's interest in identifying potential vulnerabilities. > [!NOTE] > A PoC (Proof of Concept) is a **demonstration of exploitation of a vulnerability**. Your PoC must show: +> > 1. What security boundary was crossed (Confidentiality, Integrity, Availability, Authenticity, Non-repudiation) > 2. How this vulnerability was abused > 3. What actions the attacker can now perform > > **Examples of valid PoCs:** +> > - Step-by-step reproduction instructions with exact commands > - Complete exploit code with detailed execution instructions > - Screenshots/videos demonstrating the exploit (supplementary to written steps) > > **Failure to provide a reproducible PoC may lead to closure of the report** > We will notify you, if we struggle to reproduce the exploit using your PoC to allow you to improve your PoC -> However, if we repeatedly cannot reproduce the exploit using the PoC, the report may be closed +> However, if we repeatedly cannot reproduce the exploit using the PoC, the report may be closed 5. **Required Patch or Actionable Remediation Plan Submission**: Along with the PoC, reporters must provide a patch or some actionable steps to remediate the identified vulnerability. This helps us evaluate and implement fixes rapidly. @@ -53,17 +55,16 @@ We appreciate the community's interest in identifying potential vulnerabilities. > [!NOTE] > **Note**: If you believe you have found a security issue that -> 1) affects default configurations **or** -> 2) represents a genuine bypass of intended security controls **or** -> 3) works only with non-default configurations **but the configuration in question is likely to be used by production deployments** -> **then we absolutely want to hear about it.** This policy is intended to filter configuration issues and deployment problems, not to discourage legitimate security research. +> +> 1. affects default configurations **or** +> 2. represents a genuine bypass of intended security controls **or** +> 3. works only with non-default configurations **but the configuration in question is likely to be used by production deployments** > **then we absolutely want to hear about it.** This policy is intended to filter configuration issues and deployment problems, not to discourage legitimate security research. 8. **Threat Model Understanding Required**: Reports must demonstrate understanding of Open WebUI's self-hosted, authenticated, role-based access control architecture. Comparing Open WebUI to services with fundamentally different security models without acknowledging the architectural differences may result in report rejection. 9. **CVSS Scoring Accuracy:** If you include a CVSS score with your report, it must accurately reflect the vulnerability according to CVSS methodology. Common errors include 1) rating PR:N (None) when authentication is required, 2) scoring hypothetical attack chains instead of the actual vulnerability, or 3) inflating severity without evidence. **We will adjust inaccurate CVSS scores.** Intentionally inflated scores may result in report rejection. -> [!WARNING] -> **Using CVE Precedents:** If you cite other CVEs to support your report, ensure they are **genuinely comparable** in vulnerability type, threat model, and attack vector. Citing CVEs from different product categories, different vulnerability classes or different deployment models will lead us to suspect the use of AI in your report. +> [!WARNING] > **Using CVE Precedents:** If you cite other CVEs to support your report, ensure they are **genuinely comparable** in vulnerability type, threat model, and attack vector. Citing CVEs from different product categories, different vulnerability classes or different deployment models will lead us to suspect the use of AI in your report. 11. **Admin Actions Are Out of Scope:** Vulnerabilities that require an administrator to actively perform unsafe actions are **not considered valid vulnerabilities**. Admins have full system control and are expected to understand the security implications of their actions and configurations. This includes but is not limited to: adding malicious external servers (models, tools, webhooks), pasting untrusted code into Functions/Tools, or intentionally weakening security settings. **Reports requiring admin negligence or social engineering of admins may be rejected.** @@ -71,10 +72,12 @@ We appreciate the community's interest in identifying potential vulnerabilities. > [!NOTE] > AI-aided vulnerability reports **will not be rejected by us by default.** But: +> > - If we suspect you used AI (but you did not disclose it to us), we will be asking tough follow-up questions to validate your understanding of the reported vulnerability and Open WebUI itself. > - If we suspect you used AI (but you did not disclose it to us) **and** your report ends up being invalid/not a vulnerability/not reproducible, then you **may be banned** from reporting future vulnerabilities. > > This measure was necessary due to the extreme rise in clearly AI written vulnerability reports, where the vast majority of them +> > - were not a vulnerability > - were faulty configurations rather than a real vulnerability > - did not provide a PoC @@ -90,6 +93,7 @@ If you want to report a vulnerability and can meet the outlined requirements, [o ## Product Security And For Non-Vulnerability Security Concerns: If your concern does not meet the vulnerability requirements outlined above, such as: + - Suggestions for better default configuration values - Security hardening recommendations - Deployment best practices guidance @@ -99,6 +103,7 @@ If your concern does not meet the vulnerability requirements outlined above, suc - General security questions about production deployment **then use one of the following channels instead:** + - **Documentation issues/improvement ideas:** Open an issue on our [Documentation Repository](https://github.com/open-webui/docs) - **Feature requests:** Create a discussion in [GitHub Discussions - Ideas](https://github.com/open-webui/open-webui/discussions/) to discuss with the community if this feature request is wanted by multiple people - **Configuration help:** Ask the community for help and guidance on our [Discord Server](https://discord.gg/5rJgQTnV4s) or on [Reddit](https://www.reddit.com/r/OpenWebUI/) diff --git a/src/lib/components/admin/Settings/Documents.svelte b/src/lib/components/admin/Settings/Documents.svelte index f0216e108..efa63d89b 100644 --- a/src/lib/components/admin/Settings/Documents.svelte +++ b/src/lib/components/admin/Settings/Documents.svelte @@ -759,89 +759,93 @@ bind:value={RAGConfig.MISTRAL_OCR_API_KEY} /> - {:else if RAGConfig.CONTENT_EXTRACTION_ENGINE === 'mineru'} - -
-
-
- {$i18n.t('API Mode')} -
- -
-
- - -
- -
- - - {#if RAGConfig.MINERU_API_MODE === 'cloud'} + {:else if RAGConfig.CONTENT_EXTRACTION_ENGINE === 'mineru'} +
- +
+ {$i18n.t('API Mode')} +
+ +
+ + + +
+
+ + + {#if RAGConfig.MINERU_API_MODE === 'cloud'} +
+ +
+ {/if} + + +
+
+ + {$i18n.t('Parameters')} + +
+
+