0Xer3N

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** An issue exists in the self-hosted artificial intelligence platform where collection-level Access Control List (ACL) checks can be bypassed when Milvus multitenancy mode is enabled. The ACL permits unknown non-Knowledge Base (KB) collection names, treating them as legacy or ephemeral collections. In Milvus multitenancy mode, a user-controlled collection name is used as a `resource id` and interpolated into a Milvus expression without proper escaping. This allows an authenticated non-admin user to execute queries that return private knowledge-base chunks belonging to other users. Technical details include: - **API Endpoints**: '/api/v1/retrieval/query/collection' and '/api/v1/retrieval/query/doc' - **Vulnerable Parameters**: `collection names` - **Vulnerable Variable**: `resource id` **Recommendations** Update to version 0.9.6. As a temporary workaround, restrict access to the '/api/v1/retrieval/query/collection' and '/api/v1/retrieval/query/doc' endpoints or disable Milvus multitenancy mode until the update is applied.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** Open WebUI allows users with permissions to create, update, or import workspace models to store arbitrary `meta.knowledge` entries without verifying ownership or read access to the referenced files. The system treats `meta.knowledge` entries of type `file` as an authorization source, which can be exploited by a malicious model owner to attach another user's file ID to their model metadata. This allows the attacker to read or delete private files belonging to other users. Technical details include: - **API Endpoints:** `GET '/api/v1/files/{id}/content'` and `DELETE '/api/v1/files/{id}'` can be used to read or delete unauthorized files. - **Vulnerable Parameters:** The `meta.knowledge` field within the model metadata is used to inject unauthorized file IDs. - **Function Names:** The `view file()` tool and the `has access to file()` function incorrectly trust the forged metadata for authorization. **Recommendations** Update to version 0.9.6. As a temporary workaround, restrict the `workspace.models` and `workspace.models import` permissions to trusted users only to prevent the creation of malicious models.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** Open WebUI contains a stored Cross-Site Scripting (XSS) issue where the platform fails to validate profile images for models. While similar issues were patched for user and webhook profile images, the `ModelMeta` class lacks a `validate profile image url` field validator. Additionally, the model image serving endpoint does not implement a MIME allowlist or the `X-Content-Type-Options: nosniff` header. An authenticated user with `workspace.models` permissions can store a malicious `data:image/svg+xml;base64,...` payload in a model's profile image. If another user navigates to the image URL, the embedded script executes in the application's origin, potentially leading to full account takeover via token theft from local storage. Technical details include: - **API Endpoints:** '/api/v1/models/create', '/api/v1/models/update', '/api/v1/models/import', and the serving endpoint '/api/v1/models/model/profile/image'. - **Vulnerable Parameters:** The `profile image url` variable within the `ModelMeta` class. **Recommendations** Update to version 0.9.6. As a temporary workaround, restrict the `workspace.models` permission to trusted administrators to prevent unauthorized users from uploading malicious model profile images.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** Open WebUI contains an authorization flaw in its prompt version-history endpoints. While the system authorizes the `prompt id` provided in the URL, it fails to verify that the requested history entries actually belong to that specific prompt. An authenticated user with access to any prompt they control can use a victim's history ID to read or delete another user's private prompt history, which may contain private text, internal instructions, and sensitive variables. Technical details regarding the affected endpoints: - '/api/v1/prompts/id/{prompt id}/history/diff' (GET): Allows reading another prompt's history snapshots. - '/api/v1/prompts/id/{prompt id}/update/version' (POST): Allows restoring another prompt's snapshot into the caller's prompt, exposing its content. - '/api/v1/prompts/id/{prompt id}/history/{history id}' (DELETE): Allows deleting another prompt's history entry. The issue stems from the `compute diff()`, `update prompt version()`, and `delete history entry()` functions, which fetch history entries globally by ID without ensuring the `prompt id` matches the authorized prompt. **Recommendations** Update to version 0.9.6.

**Name of the Vulnerable Software and Affected Versions** Open WebUI versions prior to 0.9.6 **Description** An authenticated user can attach arbitrary `file id` values to their own chat messages because the system fails to verify if the user owns or has read access to those files. By sharing the chat and granting themselves read access, the `has access to file()` function incorrectly treats the victim's file as accessible. This allows an attacker to read a victim's file via the 'GET /api/v1/files/{id}/content' endpoint or delete it via the 'DELETE /api/v1/files/{id}' endpoint. Additionally, the shared-chat authorization branch ignores the `access type`, meaning a user granted only read access to a legitimately shared chat can delete files attached to that chat. **Recommendations** Update to version 0.9.6 or later. As a temporary workaround, restrict access to the 'GET /api/v1/files/{id}/content' and 'DELETE /api/v1/files/{id}' endpoints to authorized administrators only.

**Name of the Vulnerable Software and Affected Versions** @angular/platform-server versions prior to 19.2.23 @angular/platform-server versions prior to 20.3.22 @angular/platform-server versions prior to 21.2.15 @angular/platform-server versions prior to 22.0.0-rc.2 **Description** An issue in the `@angular/platform-server` package allows remote attackers to bypass host allowlist constraints and direct server-side outgoing requests to arbitrary external endpoints. This is caused by a parser differential between the strict WHATWG URL parser used for allowlist validation and the lenient Domino URL parser used to initialize the server emulated DOM. When a request contains a malformed URL with a double port structure, such as `http://evil.com:80:80/path`, the strict `URL.canParse(url)` logic returns `false`, skipping host check validation. Subsequently, the Domino internal parser accepts the URL and resolves the origin to `http://evil.com:80`. The SSR HTTP request interceptor `relativeUrlsTransformerInterceptorFn()` then resolves relative backend HTTP requests against this origin, enabling a Server-Side Request Forgery (SSRF) attack. This can lead to the redirection of API queries containing sensitive credentials, session cookies, and internal authorization tokens to an attacker-controlled server, as well as response injection and content poisoning within the rendered HTML. **Recommendations** Update to version 19.2.23 or later. Update to version 20.3.22 or later. Update to version 21.2.15 or later. Update to version 22.0.0-rc.2 or later.

**Name of the Vulnerable Software and Affected Versions** LiquidJS versions prior to 10.26.0 **Description** A flaw in the `strip html` filter logic allows for Cross-Site Scripting (XSS). The filter is designed to remove HTML tags from strings to act as a sanitizer; however, it uses a regular expression where the catch-all branch (`<.*?>`) fails to match line terminators. Consequently, any HTML tag containing a newline (` `) or carriage return (`r`) character is passed through unmodified. Since web browsers treat these characters as whitespace within a tag, an attacker can bypass sanitization by inserting a newline into a tag (e.g., `<img src=x onerror=alert(1)>`), leading to the execution of arbitrary JavaScript. This occurs in applications that render attacker-controlled strings using the `strip html` filter and do not separately HTML-escape the output, which is the default behavior when the `outputEscape` variable is unset. **Recommendations** Update to version 10.26.0 or later. As a temporary workaround, avoid using the `strip html` filter for sanitizing untrusted content and instead use the `escape` filter to HTML-escape output.

**Name of the Vulnerable Software and Affected Versions** ApostropheCMS versions prior to 3.5.3 @apostrophecms/import-export versions prior to 3.5.3 **Description** ApostropheCMS contains a Zip Slip vulnerability in the `extract()` function within `gzip.js`. The `path.join()` function does not sanitize or resolve traversal segments like `../`, allowing a crafted `.tar.gz` file uploaded through the CMS import UI to write attacker-controlled content to any path the Node.js process can access on the host filesystem. This is possible because the function constructs file-write paths without performing a canonical-path check before opening the write stream. Any user with Global Content Modify permission, a role routinely assigned to content editors and site managers, can exploit this issue. The vulnerability allows for arbitrary file write, potentially leading to site defacement, malicious asset injection, persistent backdoors, credential theft, and denial of service. The `extract()` function is located in `packages/import-export/lib/formats/gzip.js` lines 132–157. The vulnerability requires the 'Global Content Modify' permission. **Recommendations** Update to version 3.5.3 of `@apostrophecms/import-export` or later.