Dev

docs/features/chat-conversations/audio/text-to-speech/Kokoro-FastAPI-integration.md

@@ -162,18 +162,32 @@ If the GPU version isn't using your GPU:
 
 ### Connection Issues from Open WebUI
 
-If Open WebUI can't reach Kokoro:
+If Open WebUI can't reach Kokoro, this is usually a Docker networking issue. Choose the method that matches your setup:
 
-- Use `host.docker.internal:8880` instead of `localhost:8880` (Docker Desktop)
-- If both are in Docker Compose, use `http://kokoro-fastapi-gpu:8880/v1`
-- Verify the service is running: `curl http://localhost:8880/health`
+**Option 1 — Docker Desktop (Windows/Mac):**
+
+Use `host.docker.internal` instead of `localhost`:http://host.docker.internal:8880/v1
+
+**Option 2 — Docker Compose (same network):**
+
+Use the service name directly:http://kokoro-fastapi-gpu:8880/v1
+
+**Option 3 — Docker Network (recommended for Linux):**
 
-### CPU Version Performance
+If `host.docker.internal` doesn't work, create a shared Docker network:
 
-The CPU version uses ONNX optimization and performs well for most use cases. If speed is a concern:
+```bash
+# Create a Docker network
+docker network create local-llm
+
+# Connect both containers to the network
+docker network connect local-llm open-webui
+docker network connect local-llm kokoro-fastapi
 
-- Consider upgrading to the GPU version
-- Ensure no other heavy processes are running on the CPU
-- The CPU version is recommended for systems without compatible NVIDIA GPUs
+# Restart both containers
+docker restart open-webui kokoro-fastapi
+```
 
-For more troubleshooting tips, see the [Audio Troubleshooting Guide](/troubleshooting/audio).
+Then set your API Base URL to `http://kokoro-fastapi:8880/v1`
+
+- Verify the service is running: `curl http://localhost:8880/health`

docs/security/index.mdx

@@ -0,0 +1,44 @@
+---
+sidebar_position: 1500
+title: "🛡️ Security"
+---
+
+# Security
+
+**How Open WebUI approaches security — and how to report vulnerabilities responsibly.**
+
+Open WebUI takes the security and confidentiality of user data seriously. Our technical architecture and development processes are designed to minimize vulnerabilities and uphold the trust our stakeholders place in us. Regular assessments, codebase vetting, and systematic adoption of best practice methodologies help keep security a central part of our project lifecycle.
+
+---
+
+## 📋 Security Policy
+
+**Rules of engagement for vulnerability reporting, disclosure, and resolution.**
+
+Everything you need to know before submitting a security report: supported versions, reporting guidelines, expected response times, confidential disclosure requirements, and what is — and isn't — considered a vulnerability.
+
+| | |
+| :--- | :--- |
+| 📝 **Reporting guidelines** | What qualifies, what doesn't, and how to submit |
+| ⏱️ **Response timeframe** | What to expect after submitting a report |
+| 🔒 **Confidential disclosure** | Rules around public disclosure timing |
+| 🔌 **Plugin security** | Security implications of Tools, Functions, and Pipelines |
+| 🏗️ **Production hardening** | Key considerations for production deployments |
+
+[**Read the Security Policy →**](./security-policy)
+
+---
+
+## 📄 Vendor Dispositions
+
+**Our formal assessments of externally reported CVEs and security claims.**
+
+When a CVE is filed against Open WebUI that we believe is inaccurate, mischaracterized, or does not represent a genuine vulnerability within our threat model, we publish a detailed vendor disposition. Each disposition explains our assessment, the reasoning behind it, and — where applicable — any actions taken.
+
+| | |
+| :--- | :--- |
+| 🔍 **Formal assessments** | Detailed analysis of each disputed report |
+| 📐 **Threat model context** | How claims map to Open WebUI's architecture |
+| ✅ **Resolution status** | Whether a report was accepted, disputed, or rejected |
+
+[**View Vendor Dispositions →**](./vendor-dispositions)

docs/security/vendor-dispositions/_category_.json

@@ -0,0 +1,4 @@
+{
+	"label": "📄 Vendor Dispositions",
+	"position": 100
+}

docs/security/vendor-dispositions/cve-2024-7040.mdx

@@ -0,0 +1,79 @@
+---
+sidebar_position: 600
+title: "CVE-2024-7040"
+---
+
+# CVE-2024-7040
+
+| | |
+| :--- | :--- |
+| **CVE ID** | [CVE-2024-7040](https://www.cve.org/CVERecord?id=CVE-2024-7040) |
+| **Vendor Disposition** | Rejected — out of scope |
+| **Published** | 2025-10-15 |
+| **Issuing CNA** | huntr.dev |
+| **Claimed Severity** | Medium (CVSS 4.9 — CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N) |
+| **CWE** | CWE-639 (Authorization Bypass Through User-Controlled Key) |
+
+
+---
+
+## What the CVE Claims
+
+In Open WebUI v0.3.8, an administrator can access the chat history of another administrator by manipulating the `user_id` parameter on an admin-gated chat-listing endpoint (`/api/v1/chats/list/user/{user_id}`). The frontend UI ordinarily exposes the listing only for non-admin accounts, but the back-end does not enforce a target-role check, so an admin who substitutes another admin's `user_id` can read that other admin's chats.
+
+---
+
+## Why This Is Out of Scope
+
+Both the requesting party and the targeted party in this report are **administrators of the same Open WebUI instance**. The cited endpoint is gated by `Depends(get_admin_user)` — only administrators can call it. The only documented authorization boundary on this endpoint holds: it requires admin privileges, and both parties have them.
+
+### Administrators Share a Trust Boundary
+
+Administrators can install any Tool or Function — which execute arbitrary Python on the server and can read or modify the database directly — and can modify any other user, including other administrators (e.g. resetting passwords). They typically also have direct server and database access at the deployment layer.
+
+Even if this specific listing endpoint were restricted, an administrator could still access another administrator's chats through any of these equivalent paths:
+
+- Resetting the other administrator's password and logging in as them
+- Installing a Tool or Function with a few lines of code that reads the chat table directly
+- Accessing the SQLite/PostgreSQL database file at the server level
+- Using the backup/export functionality
+- Reading the `WEBUI_SECRET_KEY` and forging a JWT for the other administrator
+
+Fixing the listing endpoint alone would close the most convenient path while leaving half a dozen equivalent ones open. Hard-enforcing inter-admin data boundaries makes little sense when administrators can still reset each other's passwords — a legitimate and necessary feature for account recovery and operational continuity — and have multiple other paths to the same data. The result would be a false sense of security, not actual isolation. Shared access between administrators is expected and intended behavior in Open WebUI's RBAC architecture, not a gap to be patched.
+
+### Frontend Behavior Is UX, Not a Security Boundary
+
+The report interprets the frontend's decision to hide the chat listing for admin accounts as evidence of a privacy boundary. This is a misreading. The frontend hides other administrators' chats for the same reason any multi-user UI hides irrelevant content: to avoid cluttering the interface. In an instance with multiple administrators, showing every other admin's chats by default would be noise. This is a UX convenience decision, not a security assertion — the backend has never enforced or documented an inter-admin access boundary on this endpoint.
+
+### CWE Mismatch
+
+The published CWE-639 (Authorization Bypass Through User-Controlled Key) does not apply. There is no authorization being bypassed — the endpoint's only access control is `Depends(get_admin_user)`, and that check passes for both the requesting and the targeted party. What the report describes is not a bypass of an existing control, but an expectation that a control should exist that never did. Expectation mismatch is not CWE-639.
+
+### Applicable Security Policy Rules
+
+- **[Rule 9](/security/security-policy#reporting-guidelines):** Admins have full system control and are expected to understand the security implications of their actions and configurations. Administrators within the same instance share a single trust boundary.
+- **[Rule 7](/security/security-policy#reporting-guidelines):** The report does not acknowledge the project's self-hosted, multi-administrator architecture in which administrators share trust at the infrastructure level.
+- **[Rule 12](/security/security-policy#reporting-guidelines):** The issue crosses no security boundary against a party other than the reporter's own peer administrators within the same trust boundary.
+
+---
+
+## Impact to Users
+
+**No action required.** If your deployment has multiple administrators, be aware that administrators share a trust boundary and can access each other's data — this is inherent to the administrator role, consistent with how comparable self-hosted applications (Linux root, Kubernetes cluster-admins, PostgreSQL superusers) handle shared administrative access.
+
+### Recommended Practice
+
+We recommend treating admin accounts as **configuration-only accounts** — similar to service accounts. Create your admin account with a dedicated email address or username, and use it exclusively for administrative tasks (managing settings, users, Tools, Functions, etc.). For day-to-day usage (chatting, creating knowledge bases, etc.), create a separate regular user account.
+
+This separation keeps your personal conversations out of admin-gated UI endpoints like the one cited in this CVE. Note that this is an organizational best practice, not a hard security boundary — administrators with server or database access, or the ability to install Tools and Functions, can still reach any data on the instance if they choose to.
+
+That said, this is only a recommendation — usage patterns differ. If you prefer to work within your admin account, that is perfectly fine. Just be aware that other administrators can, as they should be able to, reset accounts, install and execute code via Tools and Functions, and therefore also access your chats. This is inherent to the shared trust boundary of the administrator role.
+
+---
+
+## References
+
+- [CVE-2024-7040 on CVE.org](https://www.cve.org/CVERecord?id=CVE-2024-7040)
+- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2024-7040)
+- [Open WebUI Security Policy](../security-policy)
+- [Role-Based Access Control (RBAC)](/features/authentication-access/rbac/)

docs/security/vendor-dispositions/cve-2025-15603.mdx

@@ -0,0 +1,68 @@
+---
+sidebar_position: 100
+title: "CVE-2025-15603"
+---
+
+# CVE-2025-15603
+
+| | |
+| :--- | :--- |
+| **CVE ID** | [CVE-2025-15603](https://www.cve.org/CVERecord?id=CVE-2025-15603) |
+| **Vendor Disposition** | Rejected — practically unexploitable |
+| **Published** | 2026-03-09 |
+| **Issuing CNA** | VulDB (originating from huntr.com) |
+| **Claimed Severity** | Low (CVSS 3.7 — CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N) |
+| **CWE** | CWE-330 (Use of Insufficiently Random Values) |
+
+
+---
+
+## What the CVE Claims
+
+The Windows shell variable `%RANDOM%` is used in `backend/start_windows.bat` to derive a fallback `WEBUI_SECRET_KEY`, producing insufficiently random values that could allow JWT forgery.
+
+---
+
+## Why This Is Not a Vulnerability
+
+`start_windows.bat` is one of three documented startup mechanisms for Open WebUI. Its first line carries the comment *"This method is not recommended, and we recommend you use the start.sh file with WSL instead,"* but it is a fully supported startup script.
+
+### The Cited Code Path Is a First-Run Fallback
+
+The `%RANDOM%` path runs **only** when both of the following are simultaneously true:
+
+1. The operator has **not** provided `WEBUI_SECRET_KEY` via environment variable.
+2. **No** `.webui_secret_key` file exists on the host.
+
+In this first-run setup state, the script generates an on-disk key file by appending the value of `%RANDOM%` twelve times, persists the result to `.webui_secret_key`, and reads from that persisted file on every subsequent invocation. The `%RANDOM%` path is reached **at most once per host**, in the absence of any operator configuration, and is bypassed entirely on every subsequent run and in every deployment where the operator has set `WEBUI_SECRET_KEY` — which is the documented production guidance.
+
+### Entropy Analysis
+
+`%RANDOM%` returns 0–32767 (15 bits). Twelve concatenated values yield approximately 180 bits of total entropy. While the underlying generator is a non-cryptographic PRNG seeded from system time, practical exploitation would require an attacker to determine the exact second the script first ran on the target host (to estimate the seed), plus pre-existing network access to test forged tokens. VulDB's own CVSS rating of 3.7 (LOW) reflects this.
+
+### Other Startup Mechanisms Use Cryptographic Entropy
+
+The other two supported startup mechanisms — `start.sh` and `open-webui serve` — both use cryptographic-strength entropy: `start.sh` generates from `/dev/random`, and `open-webui serve` uses `random.randbytes(12)` via Python's `random` module.
+
+### Applicable Security Policy Rules
+
+- **[Rule 1](/security/security-policy#reporting-guidelines):** Configuration options and expected protocol behavior are not vulnerabilities. A setup-time entropy property of a first-run fallback is a configuration concern.
+- **[Rule 6](/security/security-policy#reporting-guidelines):** The cited path manifests only in a particular first-run state and is bypassed by every documented production configuration.
+
+### Disclosure Pathway
+
+No report corresponding to this CVE was filed through the project's official reporting channel ([GitHub Security Advisories](https://github.com/open-webui/open-webui/security)) prior to publication.
+
+---
+
+## Impact to Users
+
+**No action required** for the vast majority of deployments. If you are running Open WebUI via `start_windows.bat` without having set `WEBUI_SECRET_KEY` in the environment, the generated key file (`.webui_secret_key`) provides adequate entropy for typical deployments. For high-security environments, set `WEBUI_SECRET_KEY` explicitly — which is the documented production guidance regardless of startup mechanism.
+
+---
+
+## References
+
+- [CVE-2025-15603 on CVE.org](https://www.cve.org/CVERecord?id=CVE-2025-15603)
+- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2025-15603)
+- [Open WebUI Security Policy](../security-policy)

docs/security/vendor-dispositions/cve-2025-29446.mdx

@@ -0,0 +1,56 @@
+---
+sidebar_position: 700
+title: "CVE-2025-29446"
+---
+
+# CVE-2025-29446
+
+| | |
+| :--- | :--- |
+| **CVE ID** | [CVE-2025-29446](https://www.cve.org/CVERecord?id=CVE-2025-29446) |
+| **Vendor Disposition** | Rejected — not a vulnerability |
+| **Published** | 2025-04-21 |
+| **Issuing CNA** | MITRE |
+| **Claimed Severity** | Low (CVSS 3.3 — CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) |
+| **CWE** | CWE-918 (Server-Side Request Forgery) |
+
+
+---
+
+## What the CVE Claims
+
+The `verify_connection` function in `backend/open_webui/routers/ollama.py` performs an outbound HTTP request using a URL string supplied by the caller, without sufficient URL validation, allowing the URL parameter to point to internal services (SSRF). The reported PoC sends `POST /ollama/verify` with a body such as `{"url":"http://attacker/?id=1' or 1=1 -- #","key":""}`, where the trailing `#` truncates the appended `/api/version` path, causing the server to make an arbitrary GET request to the attacker-supplied URL.
+
+---
+
+## Why This Is Not a Vulnerability
+
+The endpoint `POST /ollama/verify` is gated by a `Depends(get_admin_user)` authentication dependency. It is reachable **only by administrators**. Its sole purpose is to allow the administrator to verify that an Ollama model server URL — which the administrator themselves has just configured — responds correctly.
+
+### The "Attacker" Is the Administrator
+
+The "attacker" in the cited scenario is the administrator entering a URL into a settings field that they own. The administrator can, of course, point the URL at internal services — that is the entire purpose of configuring a model server URL — but doing so does not constitute crossing a privilege boundary. There is no path by which an unprivileged user can reach this endpoint.
+
+The same pattern (admin-authenticated outbound URL probe to verify a configured integration endpoint) is present in analogous router files for other model-provider integrations. None of these are reachable by unprivileged users.
+
+### Applicable Security Policy Rules
+
+- **[Rule 9](/security/security-policy#reporting-guidelines):** "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."
+
+### Disclosure Pathway
+
+No report corresponding to this CVE was filed through the project's official reporting channel ([GitHub Security Advisories](https://github.com/open-webui/open-webui/security)) prior to publication.
+
+---
+
+## Impact to Users
+
+**No action required.** The cited endpoint is accessible only to administrators and serves its intended purpose of verifying admin-configured model server URLs.
+
+---
+
+## References
+
+- [CVE-2025-29446 on CVE.org](https://www.cve.org/CVERecord?id=CVE-2025-29446)
+- [NVD Entry](https://nvd.nist.gov/vuln/detail/CVE-2025-29446)
+- [Open WebUI Security Policy](../security-policy)