## Summary Open WebUI vetted user-supplied URLs by resolving the hostname once and rejecting private, loopback and link-local addresses, then let the HTTP client resolve that hostname again at connect time. An attacker who controls the authoritative DNS for a hostname they submit can answer with a public address during the check and an internal one at connect, so the fetch reaches an address the check was meant to block. Every user-reachable fetch gated by that check was affected, and most of them hand the internal response back to the attacker. ## Preconditions - An account on the instance. No admin rights and no non-default configuration. - Control of the authoritative DNS for a hostname the attacker submits, serving a TTL of 0 and alternating answers. - One of the affected entry points: URL ingest for retrieval, an `image_url` in a chat completion, image editing, or the OAuth profile-picture fetch. - The OAuth path additionally needs OAuth login configured and a picture claim (`OAUTH_PICTURE_CLAIM`, default `picture`) the user can influence, which is the case on self-service OIDC providers and providers with a user-editable avatar URL. On an existing account it also needs `OAUTH_UPDATE_PICTURE_ON_LOGIN`, which is off by default. Deployments without OAuth are not affected on that path; the other paths need no configuration at all. ## Impact The server can be made to issue requests to addresses only it can reach: cloud instance metadata such as 169.254.169.254, loopback-bound admin APIs, and internal network services. The response comes back to the attacker on most paths, as document content on the retrieval path, described by the vision model on the chat image path, and base64-encoded into the profile picture on the OAuth path; the image-edit path is blind. On the OAuth path the server also forwards the OAuth access token as a Bearer header to the fetched URL, so a rebind hands that token to the internal target. On a cloud host with IMDSv1 reachable this is enough to take instance IAM credentials. Exploitation depends on winning the gap between the two resolutions, which the attacker influences but does not fully control. Admin-configured image-generation backends and the shared session pool are not affected and deliberately keep the default client, since an administrator may legitimately point those at an internal host. ## Fix Fixed in v0.11.0 (#24759, #25775, #25960, #26699). The check now happens at the connection layer instead of ahead of it: a `requests` transport adapter resolves the hostname once and connects to that same validated address, and an aiohttp resolver applies the same global-IP check, exposed as a one-off session used by every fetch behind the URL check. Upgrading to v0.11.0 resolves this with no configuration change. ## Root cause Affected components: - retrieval web loader (`SafeWebBaseLoader`) - retrieval content probe (`get_content_from_url`) - chat image fetch (`get_image_base64_from_url`) - image edit fetch (`load_url_image`) - OAuth profile-picture fetch (`_process_picture_url`) The URL check resolved the hostname and inspected the resulting IP, but nothing tied that decision to the connection that followed: the HTTP client resolved the name again on its own, and the second answer was never inspected. The check was therefore an opinion about a past lookup rather than a constraint on the actual connection, which is what a rebinding DNS server defeats. The first connection-layer guard covered only the retrieval loader, leaving the sibling probe, image and OAuth fetches on default clients until each was reported in turn. ## Credits - @rezaduty — the rebinding time-of-check/time-of-use bypass and the retrieval loader path. - @nikchillz — the retrieval content-probe path. - @dhyabi2 — the chat `image_url` path, where the internal response is read back through the vision model. - @geo-chen — the image-edit path. - @bogdancherniy11-sudo — the OAuth profile-picture path, where the rebind also discloses the forwarded OAuth access token.

Ghost is a Node.js content management system. From 6.19.4 until 6.21.1, insufficient validation of the client-supplied Content-Type on Ghost's Admin API file upload endpoint allowed uploaded files to be served from the site with an attacker-chosen content type on S3/GCS storage backends. On installations that serve uploaded files from the same origin as the site, this could have been used to facilitate stored cross-site scripting against site visitors or staff. This vulnerability is fixed in 6.21.1.

### Impact The Universal Import feature in Ghost Admin failed to properly sanitize imported content resulting in XSS in post content. ### Vulnerable versions This vulnerability is present in Ghost from v5.26.0 up to v6.54.0. ### Patches v6.54.1 contains a fix for this issue. ### How to update For self-hosters using Docker, find [Docker's official Ghost image here](https://hub.docker.com/_/ghost). Updating a Docker-based Ghost instance [is documented here](https://docs.ghost.org/install/docker#updating-ghost). If your Ghost is a Ghost-CLI install see our documentation on [updating it to the latest version here](https://docs.ghost.org/update). ### Workarounds If upgrading immediately is not possible, avoid using the Universal Import feature. ### References Ghost thanks meifukun for disclosing this vulnerability responsibly. ### For more information If you have any questions or comments about this advisory, email us at [[email protected]](mailto:[email protected]).

## Summary A user granted write access to a shared chat folder could permanently delete chats and messages belonging to the folder's owner. Deleting a folder cascades into the owner's chats and the entire subfolder subtree, and the deletion handler required only write access on subfolders instead of ownership. Root folders were restricted to the owner or an admin, subfolders were not. ## Preconditions The Folders Sharing permission (`user.permissions.sharing.folders`) must be enabled; it is off by default. The victim must have shared a folder with the attacker at write access. `features.folders` and the `chat.delete` permission are enabled by default and are both required. Deployments that leave folder sharing disabled are not affected, and neither are single-user instances. ## Impact Permanent, irreversible destruction of another user's chat history within and beneath a shared folder. With `delete_contents=false` the same request instead force-moved the owner's chats out of the folder, an unauthorized relocation rather than a deletion. The write grant on the shared root folder is inherited by every descendant, so the attacker could destroy subfolders that were never explicitly shared with them. Nothing outside the shared folder's subtree is reachable, and no data is disclosed that write access did not already expose. ## Fix Fixed in 0.11.0 by https://github.com/open-webui/open-webui/pull/27003. Folder deletion is now restricted to the folder owner or an admin for root folders and subfolders alike, replacing the previous root/subfolder split with a single check. Upgrading fully resolves the issue; no configuration change is required. Owners and admins are unaffected, and a write-collaborator can still create, rename and add to shared folders and delete subfolders they own. ## Root cause Affected component: `backend/open_webui/routers/folders.py`, the `DELETE /api/v1/folders/{id}` handler. Affected setup: any release from 0.10.0 onward that has folder sharing enabled. The cascade that follows the authorization check is bound to the folder owner's id, not the caller's, so whoever passes the check deletes the owner's data. The check itself branched on whether the folder had a parent: root folders demanded ownership or admin, while subfolders accepted any write grant. Because write grants propagate down the folder tree, that branch handed every collaborator deletion rights over the owner's subtree, which is broader than what the sharing model grants write access. ## Credits @legobattman, who reported the issue and its remediation.

## Summary The built-in knowledge search tools let a chat participant choose the pattern used to grep knowledge files. Patterns containing regex metacharacters were compiled with Python's backtracking `re` engine and run against every line of every reachable file, with no time limit anywhere on that path. A single crafted pattern and a single short line of matching text pin one CPU core for as long as the attacker wants, and because the search runs synchronously inside the event loop, that worker serves nobody else while it spins. ## Preconditions - Default configuration. The knowledge builtin tool group is enabled by default, and with `ENABLE_KB_EXEC` at its default of `False` the model is handed `grep_knowledge_files`, which is the affected path. - Any authenticated user, no elevated role and no workspace permission. - One file the attacker can read. `USER_PERMISSIONS_CHAT_FILE_UPLOAD` defaults to true and a user always has read access to their own upload, so both halves of the input are attacker-supplied. - A model willing to call the tool with the attacker's literal pattern. This is the one non-deterministic step: it is reliable in practice by instructing the model in your own chat, but it is not guaranteed on a given turn. - Deployments running with `UVICORN_WORKERS` at its default of 1 lose the whole instance; multi-worker deployments lose one worker per request. ## Impact Availability, against every other user of the affected worker. Cost scales exponentially with the length of the matching text: measured on the vulnerable code, a 24 character subject takes 1.2s, 28 takes 19s and 30 takes 74s, and a 40 character subject extrapolates to roughly a day of CPU. The same subject against a literal pattern takes under a microsecond. There is no confidentiality or integrity effect, and no data is read or altered. ## Fix Fixed in 0.11.0 by https://github.com/open-webui/open-webui/pull/27471. Pattern matching moved from `re` to the `regex` engine, which supports a per-search timeout, and every tool call now runs its searches under a single 2 second matching budget, after which the tool returns an error instead of continuing to match. Upgrading is sufficient; there is nothing an operator has to configure. ## Root cause - `backend/open_webui/tools/knowledge_fs.py`, `build_matcher`: compiled the caller's pattern and returned an unbounded match function. - `backend/open_webui/tools/builtin.py`, `grep_knowledge_files`: the default-configuration caller, which ran that matcher over every line of every reachable file. `build_matcher` treated any pattern containing regex metacharacters as a regex, so no explicit flag was needed to reach the compiler. From there the only limits in place were on results, not on work: a cap on matches returned and a cap on files scanned, neither of which bounds the time a single line can consume. Backtracking cost is exponential in the length of the matched text rather than in the pattern, so capping pattern length or line length would not have bounded it either. The engine had no timeout available and none was imposed elsewhere. ## Proof of concept Against a real instance as an ordinary user: 1. Upload a text file whose content is a single line of 30 `x` characters, and no `y`. 2. In a chat on a model with the knowledge tools available, instruct the model to call `grep_knowledge_files` with the pattern `(x|x)*y` and that file's id. 3. The request never returns. The worker's CPU sits at 100% for the duration, and concurrent requests from other users on the same worker do not complete. Growth measured directly against `build_matcher` on the vulnerable code: | subject length | time | | -------------- | ----- | | 16 | 4.7ms | | 20 | 73ms | | 24 | 1.21s | | 28 | 19.3s | | 30 | 73.9s | ## Credits @Classic298, for the finding and the fix.

## Summary Any authenticated user can store a chat message whose math block makes KaTeX fail with a stack overflow instead of a parse error. When that happens the renderer falls back to inserting the original math source into the page as HTML rather than as text, so script in the message runs in the browser of whoever views it. Every surface that renders messages is affected, including shared chats and channels, and the missing control is output escaping on the error path. ## Preconditions Default configuration, no flags involved. The attacker needs a normal user account and a way to get the target to open the content: a shared chat link, a channel the target reads, or any other message surface. No admin rights and no non-default settings are required on either side. ## Impact Script executes in the viewer's browser on the Open WebUI origin, which puts the session token in localStorage within reach and therefore allows taking over the viewing account. If the viewer is an administrator, that is administrator access to the instance. Exploitation needs the target to open the content, but nothing beyond that: no interaction with the message itself. Server-side data and availability are unaffected; the impact is entirely in the viewer's browser session. ## Fix Fixed in 0.11.0 by commit bc600d3f0 (PR #26718). The error path now HTML-escapes the math source before it reaches the DOM, so a failed render displays the formula as text instead of as markup. Upgrading fully resolves the issue; no configuration change is needed. ## Root cause Affected component: `src/lib/components/chat/Messages/Markdown/KatexRenderer.svelte`, the reactive block that renders math and its `catch` branch. Affected setup: releases 0.10.0 through 0.10.2, which are the versions carrying that fallback. KaTeX was called with `throwOnError: false`, which suppresses parse errors but not a `RangeError` from deeply nested input. The surrounding `catch` treated any failure as "show the original formula" and assigned the untouched source to the value that the template inserts with `{@html}`. Because the Markdown math tokenizer captures everything between the delimiters verbatim, including angle brackets and complete tags, the attacker controls that string exactly. ## Proof of concept Send a chat message (or store one via any endpoint that writes message content) consisting of a single inline math block: an opening `$`, 100000 `{` characters, an `<img src=x onerror=alert(document.domain)>` tag, 100000 `}` characters, and a closing `$`. ``` python3 -c 'N=100000; print("$"+"{"*N+"<img src=x onerror=alert(document.domain)>"+"}"*N+"$")' ``` Open the chat as any user who can view it. KaTeX overflows the stack, the fallback inserts the raw source, and the `onerror` handler fires. Replacing `alert()` with a request carrying `localStorage.token` sends the viewer's session token to an attacker-controlled host; this was demonstrated against a shared chat opened by an administrator account. ## Credits @maxntv — reported the unescaped KaTeX error fallback and demonstrated session-token theft through a shared chat.

## Summary A workspace tool shared with a read grant returned its full Python source to the recipient. Any authenticated non-admin who could use a shared tool could also read its source, including any user on the instance when a tool was shared publicly. Source is meant to be a writer-only tier: the list response schema deliberately omits it and source export sits behind its own permission. The read endpoints delivered it anyway. ## Preconditions - Authentication enabled (`WEBUI_AUTH=true`, default) and plugins enabled (`ENABLE_PLUGINS=true`, default). - The attacker is an authenticated non-admin without the `workspace.tools` permission and without a write grant on the tool. - A tool is shared with a read grant to the attacker, to one of their groups, or to all users (`user:*`). Deployments that share no tools, or share them only with users who already hold write access, are not affected. ## Impact A non-admin obtains another user's server-side tool source. Tool source commonly embeds hard-coded API keys, credentials and internal service URLs, so the practical loss frequently extends past the code itself. The attack needs no special permission beyond an ordinary account that a tool was shared with, and no user interaction. Confidentiality only: it grants no ability to create, modify or execute tools, and no integrity or availability impact. ## Fix Fixed in 0.11.0 by commit `c05de13b4` (#27005) together with `310ae9130`. The per-id endpoint now drops the source for callers without write access, and the two list endpoints no longer load source at all. Function specs stay visible to read users, since the chat tool listing renders a tool's functions from them. Tool execution loads source server-side, so shared tools keep working. Upgrading to 0.11.0 fully resolves the issue with no configuration change. ## Root cause Affected components: `GET /api/v1/tools/`, `GET /api/v1/tools/list` and `GET /api/v1/tools/id/{id}` in `backend/open_webui/routers/tools.py`, and the response models in `backend/open_webui/models/tools.py`. Every build carrying the plugin routes is affected. `ToolResponse` deliberately omits the source and the specs, but its subclass `ToolUserResponse` permits extra fields, and each handler built its response by spreading a full dump of the tool model. The omitted fields were re-admitted as extras and serialised back to the caller, so the schema meant to enforce the writer-only tier enforced nothing at all. The listing path carried a second, independent defect: the flag that was supposed to keep source out of listings never changed the query it guarded. ## Proof of concept Against a default instance on 0.10.2, with an admin account and a second account of role `user`: 1. As the admin, create a tool whose source contains a marker secret and share it read-only with everyone: ``` POST /api/v1/tools/create {"id": "poctool", "name": "PoC Tool", "content": "API_KEY = \"TOOL_SRC_SECRET\"\nclass Tools:\n def hello(self) -> str: return 'hi'", "meta": {"description": "poc"}, "access_grants": [{"principal_type": "user", "principal_id": "*", "permission": "read"}]} ``` 2. As the non-admin, call any of the three read endpoints: ``` GET /api/v1/tools/list -> 200, item "poctool": write_access=false, content="API_KEY = \"TOOL_SRC_SECRET\" ..." ``` The same source is returned by `GET /api/v1/tools/` and `GET /api/v1/tools/id/poctool`. On 0.11.0 the identical run returns the item with no source for the non-admin, while the owner still receives it. ## Credits - bogdancherniy11-sudo — reported the disclosure across the three tool read endpoints.

Improper access control in Azure Cosmos DB allows an unauthorized attacker to execute code over a network.

## Summary The terminal WebSocket route authenticates its own first-message JWT instead of going through the HTTP dependency chain, and never applies the role check that `get_verified_user` enforces on every HTTP terminal route. An account whose role is `pending`, meaning registered but not approved, or approved and later deactivated back to `pending`, can therefore open an interactive terminal session that the HTTP terminal endpoints would refuse. The missing control is the verified-user role gate, not the terminal access grants, which are evaluated correctly. ## Preconditions At least one terminal server must be configured, which is off by default, and its access grants must cover the account: either public read (`principal_id: "*"`) or a group the account still belongs to. The attacker needs a valid, unexpired JWT for a `pending` account and the terminal server id. Both are obtainable by an account that registered while approvals are pending, or by one that held access and was deactivated, since deactivation sets the role to `pending` without revoking the token, which lasts four weeks by default. Deployments with no terminal server configured, or whose terminal grants are admin-only, are not affected. ## Impact A deployment loses the account-approval boundary for terminal access. An unapproved or deactivated account gets interactive shell access, file browsing and terminal-backed tooling in the terminal environment, for as long as its token remains valid. Because the HTTP terminal routes correctly reject the same account, the two planes disagree, so an administrator who deactivates a user sees access revoked over HTTP while the WebSocket keeps working. The terminal access grants themselves are not bypassed: an account with no grant is still refused, so this only widens access to terminals already shared broadly or with a group the account remains in. ## Fix Fixed in v0.11.0 by https://github.com/open-webui/open-webui/pull/27537. Token decoding, revocation checking, user lookup and the role check are consolidated into a single `get_verified_user_by_token` helper, and both the terminal WebSocket route and the Socket.IO handshake now go through it. The role set lives in one constant shared with the HTTP gate so the two cannot drift apart again. Upgrading fully resolves the issue; no configuration change is required. ## Root cause Affected component: `backend/open_webui/routers/terminals.py`, the `_resolve_authenticated_connection` helper backing the `/{server_id}/api/terminals/{session_id}` WebSocket route. Affected setup: every build from v0.8.8 onward, since the route was introduced there. WebSocket handshakes cannot use FastAPI dependencies, so this route reimplemented authentication inline. The reimplementation reproduced the parts that are visible in the token, that it decodes and that the user row exists, and silently dropped the part that lives in the database row, the role check. Authorization then ran on two independent code paths with no shared definition of what an authenticated user is, and only one of them was updated when the role gate was introduced. ## Credits Reported by @rexpository.

SGLang contains an unauthenticated RCE in /load_lora_adapter_from_tensors via bypass of SafeUnpickler’s incomplete denylist, allowing arbitrary command execution through crafted base64-encoded pickle payloads.

SGLang contains an RCE vulnerability when the optional dumper subsystem is enabled, allowing for a sandbox escape when DUMPER_SERVER_PORT is set, enabling code execution on inference requests.

## Summary In every affected release, automation recurrence parsing anchors minutely and hourly rules at a fixed date of 2000-01-01 and then walks forward one interval at a time to find the next run. A single `FREQ=MINUTELY` rule therefore enumerates roughly a quarter-century of occurrences, synchronously, on the event loop that also serves the scheduler, HTTP and WebSocket traffic. Nothing bounds the walk, and nothing moves it off the loop. ## Preconditions Any user who can create an automation. `USER_PERMISSIONS_FEATURES_AUTOMATIONS` defaults to `false`, so on a default deployment only an admin can reach the create path; it becomes reachable by ordinary users on any deployment that has granted the automations feature, which is the normal way to make the feature usable. `UVICORN_WORKERS` defaults to 1, so there is no second worker to absorb the stall. The rule needs no unusual syntax: `FREQ=MINUTELY` with no `DTSTART`, or with a `DTSTART` set well in the past, is enough. ## Impact Availability, against every other user of the instance. One evaluation of `RRULE:FREQ=MINUTELY` takes 18.9 s of blocking CPU; adding a ten-value `BYSECOND` list multiplies the walk and takes 64.2 s. `FREQ=HOURLY` costs 0.34 s and is not materially exploitable on its own. The cost does not stop at creation: once the automation is stored, the scheduler recomputes the next run for every claimed row on each poll, so the same walk repeats on a default 10 s interval and the instance stays wedged rather than recovering. Instances that have not enabled the automations feature for non-admin users are exposed only to an admin doing this. ## Fix Fixed in 0.11.0. Sub-daily rules are now anchored to the current clock instead of the year-2000 date, so the walk starts at the next occurrence rather than a quarter-century behind it. A caller-supplied `DTSTART` is honoured only when the number of occurrences it implies stays under a fixed bound, and is otherwise replaced by the clock-aligned anchor. The same rules that cost 18.9 s and 64.2 s now cost under a millisecond. Upgrading fully resolves the issue, no configuration change is required. ## Root cause Affected component: `backend/open_webui/utils/automations.py`, `_parse_rule`, reached from the automation create, update and toggle handlers in `backend/open_webui/routers/automations.py` and from the scheduler's claim path in `backend/open_webui/models/automations.py`. Affected setup: every build from 0.9.0 onward, since that is when the automations feature shipped. The fixed anchor existed to make sub-daily intervals snap to clock boundaries, so that "every 5 minutes" lands on :00, :05, :10 rather than drifting from whenever the automation happened to be created. Snapping only needs a reference point of the right phase, but the implementation used a literal far-past date as that reference and left the recurrence library to walk forward from it. The distance between the anchor and the present is therefore attacker-influenced work that grows with real time, and it was never treated as a cost that needed a bound or a thread. ## Proof of concept Measured cost of a single next-run computation against the shipped 0.10.2 parser: | rule | cost | | --- | --- | | `RRULE:FREQ=MINUTELY` | 18,880 ms | | `RRULE:FREQ=MINUTELY;BYSECOND=0,1,2,3,4,5,6,7,8,9` | 64,236 ms | | `DTSTART:20000101T000000` + `RRULE:FREQ=MINUTELY` | 26,237 ms | | `RRULE:FREQ=HOURLY` | 339 ms | Measured at function level deliberately. Persisting such an automation has the scheduler repeat the walk on every poll and wedge the instance indefinitely, which is the actual impact but makes a live end-to-end run destructive to the test instance. ## Credits Reported by @Classic298.

SGLang contains an SSRF and local file read in the multimodal generation endpoint /v1/chat/completions due to unsanitized image_url, allowing access to internal metadata, secrets, and services.

SGLang contains a RCE vulnerability when attempting to load model weights from a HuggingFace repository, specifically within the /update_weights_from_disk, where torch.load(..., weights_only=False) fallback enables pickle deserialization of .bin files.

SGLang contains a credential leakage vulnerability in the /server_info endpoint, which will return API keys and SSL keyfile information when only the --admin-api-key is configured.

SGLang contains a model weight exfiltration vulnerability when no API keys are configured, as SGLang will expose two endpoints that allow a remote attacker to trigger distributed weight broadcasting using NCCL and then triggering data transfer, attackers can exfiltrate all model weights.

## Summary Open WebUI lets a client define a model inline on a chat request instead of selecting a saved workspace model. The knowledge attached to such an inline model was used as-is, without checking that the caller can read what it points at. Any authenticated user who knows another user's file id could therefore have the builtin knowledge tools return that file's indexed content back to them. ## Preconditions Authenticated user of any role, no admin rights needed. The request must carry a session id and use native function calling, which is the default (only `function_calling: legacy` opts out), and the model's `builtin_tools` capability must not be disabled (default enabled). The attacker must already know the target file's id; ids are UUIDs and are not enumerable through this path. No admin setting needs to be turned on: enabling Direct Connections is not required for the backend to accept an inline model. Knowledge bases attached this way were never affected, their own access grants were enforced on every path. ## Impact An authenticated user could read the indexed chunks of another user's or group's file, a cross-user confidentiality loss limited to files whose ids the attacker already holds. It is read-only: nothing is modified or deleted, knowledge-base permissions are unaffected, and saved workspace models were already validated at creation time. ## Fix Fixed in 0.11.0 by commit 305880f2e. An inline model's attached knowledge is filtered against the caller's real read access before it is used, dropping any file, knowledge base or note the caller cannot read. Upgrading fully resolves it, no configuration change is required. ## Root cause Affected component: the chat completion, chat completed and chat action endpoints, which accept an inline model definition, and the builtin knowledge tools that consume the model's attached knowledge. Affected setups: all builds from 0.8.8 through 0.10.2. Saved workspace models have their attached file references validated against the author when the model is created, updated or imported, so a stored model can only carry files its creator can read. An inline model never passes through that path, yet everything downstream treated its attached knowledge with the same trust, including a helper that grants read access to a file purely because the running model claims it as attached knowledge. The missing control was an access check at the point where client-supplied model metadata enters the request. ## Credits Reported by @whyiug.

## Summary A user with write access to one knowledge base could delete directories, and drop file embeddings, belonging to knowledge bases they do not control. The sync cleanup endpoint verified write access on the knowledge base named in the URL and then acted on the directory and file ids supplied in the request body without checking that those objects belonged to that knowledge base. ## Preconditions Default configuration, no flags involved. The attacker needs write access to at least one knowledge base, which comes from owning one, from a write access grant, or from the admin role; `workspace.knowledge` is off by default, so an ordinary user cannot simply create one. They also need the victim's directory or file id, which are UUIDs and are not enumerable, so in practice the attacker is someone who can already see the target knowledge base, typically a read-only collaborator on a shared one. Deployments where no knowledge base is shared beyond its owner are not reachable. ## Impact The attacker deletes a target directory and, because the deletion runs without moving files to the parent, the knowledge_file associations for every file in that subtree are removed as well, so those documents silently drop out of the victim's knowledge base and out of its retrieval results. Separately, the per-file vector cleanup dropped the standalone `file-<id>` collection for any file id, breaking chat-with-file for that document. The stored files and their database rows survive, since that path was gated on file ownership, and an owner can restore the state by re-adding and reprocessing. Nothing about the target knowledge base's contents is disclosed to the attacker. ## Fix Fixed in https://github.com/open-webui/open-webui/pull/26722. Both request-body loops are now scoped to the knowledge base in the URL: a directory is resolved and skipped unless its `knowledge_id` matches, and the per-file vector cleanup runs only for files that are members of that knowledge base. Upgrading fully resolves the issue. ## Root cause Affected component: `backend/open_webui/routers/knowledge.py`, handler `sync_knowledge_cleanup`, endpoint `POST /api/v1/knowledge/{id}/sync/cleanup`. Affected setup: all builds from 0.9.6 onward, no optional dependency involved. The handler treated the write-access check on the URL knowledge base as authorization for everything it went on to do, but the objects it acted on came from the request body and were addressed by primary key alone. Directory deletion at the model layer deletes by directory id and has no notion of a parent knowledge base, so the only thing that could have bound the two together was a membership check in the handler, and there was none. The explicit directory-delete endpoint in the same router already carried that check, which is what makes this a gap in one handler rather than a missing model-layer control. ## Credits Reported by @whyiug.

Hypequery is a TypeScript semantic layer for ClickHouse. Prior to 2.0.2, escapeValue() in packages/clickhouse/src/core/utils.ts did not escape backslashes before single quotes during parameter substitution, allowing attacker controlled query parameters with a trailing backslash to escape the closing quote and inject arbitrary SQL. This issue is fixed in version 2.0.2.

Vulnerability in the Oracle Enterprise Command Center Framework product of Oracle E-Business Suite (component: Core). The supported version that is affected is V16. Easily exploitable vulnerability allows unauthenticated attacker with access to the physical communication segment attached to the hardware where the Oracle Enterprise Command Center Framework executes to compromise Oracle Enterprise Command Center Framework. Successful attacks of this vulnerability can result in takeover of Oracle Enterprise Command Center Framework. CVSS 3.1 Base Score 8.8 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Vulnerability in the Oracle Enterprise Command Center Framework product of Oracle E-Business Suite (component: Core). The supported version that is affected is V16. Difficult to exploit vulnerability allows unauthenticated attacker with access to the physical communication segment attached to the hardware where the Oracle Enterprise Command Center Framework executes to compromise Oracle Enterprise Command Center Framework. Successful attacks of this vulnerability can result in takeover of Oracle Enterprise Command Center Framework. CVSS 3.1 Base Score 7.5 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H).

Vulnerability in the Oracle Enterprise Command Center Framework product of Oracle E-Business Suite (component: Core). The supported version that is affected is V16. Easily exploitable vulnerability allows low privileged attacker with network access via HTTP to compromise Oracle Enterprise Command Center Framework. Successful attacks of this vulnerability can result in unauthorized creation, deletion or modification access to critical data or all Oracle Enterprise Command Center Framework accessible data as well as unauthorized read access to a subset of Oracle Enterprise Command Center Framework accessible data and unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of Oracle Enterprise Command Center Framework. CVSS 3.1 Base Score 8.3 (Confidentiality, Integrity and Availability impacts). CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:H).

IBM Langflow OSS 1.0.0 through 1.10.1  are vulnerable to unauthenticated remote code execution via environment variable injection in the MCP (Model Context Protocol) stdio launcher. The vulnerability exists in src/lfx/src/lfx/base/mcp/util.py where the DANGEROUS_ENV_VARS blocklist fails to include SHELLOPTS , BASHOPTS , and PS4 environment variables.

IBM Langflow OSS 1.0.0 through 1.10.1 allows authenticated users to access and manipulate other users' build jobs through improper access control on log retrieval and unauthenticated build endpoints.

IBM Langflow OSS 1.0.0 through 1.8.4 contains multiple broken access control vulnerabilities in its file handling API that allow unauthorized access to user files.The /api/v1/files/images/{flow_id}/{file_name} endpoint does not enforce authentication or authorization checks, allowing unauthenticated remote attackers to retrieve image files associated with any flow by specifying a valid flow_id and file_name.Additionally, the /api/v1/files/download/{flow_id}/{file_name} endpoint requires authentication but fails to properly validate ownership of the requested resource. As a result, an authenticated user can access files belonging to other users by supplying arbitrary identifiers, leading to an authorization bypass (IDOR).Successful exploitation may result in unauthorized disclosure of sensitive data, including files stored in private flows. This issue breaks tenant isolation in multi-user deployments.

IBM Langflow OSS 1.0.0 through 1.10.1 could allow a remote attacker to traverse directories on the system. An attacker could send a specially crafted URL request containing "dot dot " sequences ( /.. /) to view arbitrary files on the system.

Missing authentication for critical function vulnerability in Universal Software Inc. UKBS allows Accessing Functionality Not Properly Constrained by ACLs. This issue affects UKBS: through 28072026. NOTE: The vendor was contacted and it was learned that the product is not supported.

MaxSite CMS 109.5 and earlier contains an authentication bypass vulnerability in the AJAX dispatcher that allows unauthenticated attackers to access admin-gated endpoints by supplying any X-Requested-With header and requesting a base64-encoded path resolving to any *-ajax.php file in the codebase. Attackers can exploit this dispatcher bypass to reach privileged plugin endpoints without credentials, enabling actions such as manipulating poll states and vote counts, and amplifying the impact of any dangerous operation performed by admin-only ajax files across the plugin tree.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 until 0.11.0, the terminal file-preview serveUrl iframe branch always granted allow-same-origin together with allow-scripts for HTML files served from the application origin. Any authenticated user with access to a configured terminal server could cause script in a previewed file to run in the Open WebUI origin, read the victim's session token from localStorage, and take over the account, with possible server-side code execution if the victim was an admin or held workspace.functions. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.0 until 0.11.0, Open WebUI checked whether a user-supplied URL destination was globally routable by applying ipaddress.is_global to the literal IPv6 address without examining IPv4 addresses embedded in transition encodings. On a deployment with a NAT64 gateway, any verified user could wrap an internal or cloud-metadata IPv4 address in the NAT64 well-known prefix, pass the filter, and receive the internal response body through RAG URL ingestion, URL-to-markdown conversion, or web-search content retrieval. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.7.0 until 0.11.0, the legacy chat-completions features block trusted a client-supplied image_generation flag and did not re-check the features.image_generation permission that the direct image routes and native function-calling path enforce. An authenticated user whose image-generation permission had been revoked could still consume the operator's configured image provider through chat completions, spending API credits and provider quota and writing generated files to operator storage, without exposing provider credentials or other users' data. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 until 0.11.0, DELETE /api/v1/chats/{id} cancelled a chat's in-flight tasks before checking whether the caller could delete that chat. Any authenticated user who knew another user's chat id could abort that user's running model response, title generation, or tag generation, even though the delete was refused and no chat data was deleted, modified, or disclosed. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.8.0 until 0.11.0, when ENABLE_OAUTH_TOKEN_EXCHANGE=True, /oauth/{provider}/token/exchange accepts a raw provider access token and validates it by calling the provider userinfo endpoint without confirming which OAuth client the token was issued to. Anyone holding an access token minted for any client registered with the same provider could exchange it for an Open WebUI session as that token user, including applications the operator does not control and has never authorized. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.5.0 until 0.11.0, the standard channel message update and delete handlers accepted any caller holding write access on the channel without checking that the caller wrote the message. Because write access is the same grant a member needs to post, any ordinary participant in a shared standard channel could rewrite or permanently delete another participant message, while group and direct message handlers enforced authorship. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.6.34 until 0.11.0, Open WebUI renders vega and vega-lite fenced code blocks in chat content by building a Vega view in the viewer browser without a restricted resource loader. Any user who can place such a block where another user will see it can make that user browser issue attacker-chosen outbound GET requests and read responses from same-origin or CORS-permissive targets into the rendered page. This issue is fixed in 0.11.0.

Open WebUI is an extensible, feature-rich, and user-friendly self-hosted AI platform. From 0.9.6 until 0.11.0, with WEB_LOADER_ENGINE=playwright, the Playwright web loader validates only the top-level page request and lets sub-resource requests pass unvalidated. A page supplied by an authenticated user can use JavaScript to reach blocked internal addresses, and returned DOM can include data read from those addresses in web-search or RAG output. This issue is fixed in 0.11.0.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the POST /api/v1/oauth2-credential/refresh/:credentialId endpoint is included in WHITELIST_URLS and requires no authentication. The endpoint decrypts the stored credential, sends a refresh request to the configured OAuth provider with the client secret and refresh token, and returns the refreshed access_token in the response body. An attacker with a credential ID can use the token to access the victim's connected service and can also exhaust refresh-token quota. This issue is fixed in 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, a prompt injection sent to a chatflow using a CSV Agent node can cause the LLM to respond with a malicious Python script that bypasses the blocklist validator and executes in an unsandboxed Pyodide environment. The specific flaw exists within the run method of the CSV_Agents class, where untrusted data is used to construct an LLM prompt and the resulting pythonCode is validated by validatePythonCodeForDataFrame before execution. An attacker can leverage this to execute arbitrary code in the context of the service account. This issue is fixed in 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, several organization billing endpoints in packages/server/src/enterprise/routes/organization.route.ts and packages/server/src/enterprise/controllers/organization.controller.ts accept attacker-controlled Stripe subscriptionId values without verifying that the identifier belongs to the authenticated user's organization. An authenticated attacker can perform unauthorized Stripe subscription operations on other tenants, including changing subscription plans or modifying seat quantities, resulting in financial impact and service disruption. This issue is fixed in 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the PUT /api/v1/executions/:id endpoint in packages/server/src/routes/executions/index.ts lacks the checkAnyPermission() middleware that protects other execution endpoints. Any authenticated user, regardless of assigned permissions, can modify execution state, data, and metadata of any execution in their workspace, enabling privilege escalation and manipulation of workflow execution results. This issue is fixed in 3.1.3.

Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise GET /api/v1/upsert-history returns the entire server-wide upsert history instead of being scoped to the requesting user, tenant, or workspace. The response can exceed 100MB and includes sensitive configuration data, including Vector Store settings such as Qdrant Server URL and collection name. The observed behavior indicates missing or insufficient authorization checks, workspace/project/tenant isolation, and pagination or limits, exposing integration parameters and infrastructure details that may enable further targeted attacks. This issue is fixed in version 3.1.3.

Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise injects $vars into the code execution sandbox without requiring variables:view, bypassing the permission-protected Variables API. Variables for the active workspace are fetched at packages/components/src/utils.ts and runtime variables are resolved from server environment variables, while the official variables route enforces variables:view. A user or API key that is denied variables:view can call /api/v1/node-custom-function and receive $vars pre-populated with all variables for the workspace, including Variable.name to Variable.value static variables and Variable.name to process.env[Variable.name] runtime variables. This can expose secrets such as database passwords, JWT secrets, SMTP passwords, and cloud keys, depending on the workspace Variables configuration. This issue is fixed in version 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise validatePythonCodeForDataFrame in packages/components/src/pythonCodeValidator.ts can be bypassed with Unicode homoglyph identifiers, allowing arbitrary Python execution inside Pyodide and full OS command execution on the Flowise host via Pyodide js module interop. The validator gates pyodide.runPythonAsync in packages/components/nodes/agents/CSVAgent/CSVAgent.ts and packages/components/nodes/agents/AirtableAgent/AirtableAgent.ts with an ASCII word-boundary blacklist. JavaScript regex word boundaries are ASCII-only, while Python 3 NFKC-normalizes identifiers at parse time, so homoglyph forms such as __cl𝐚ss__, __subcl𝐚sses__, __b𝐚se__, and __b𝐮iltins__ bypass the blacklist and are parsed as their ASCII equivalents. This issue is fixed in version 3.1.3.

Atlas-Livre contains an improper access control vulnerability in the admin controllers under Espace_admin/controleur/ that allows unauthenticated attackers to bypass session-based authentication guards by sending raw HTTP requests that ignore redirects. Attackers can invoke destructive admin actions such as record deletion by requesting controller endpoints with GET parameters like supp, because the PHP header() redirect is never followed by an exit or die call, allowing all subsequent code including database operations to execute regardless of session state.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the CSVAgent in packages/components/nodes/agents/CSVAgent/CSVAgent.ts extracted attacker-controlled CSV data with file.split(',').pop() and interpolated it directly into executable Python as base64_string = "${base64String}" before calling Pyodide. The validatePythonCodeForDataFrame() denylist only checked later LLM-generated code and did not validate this initial code block. An authenticated attacker could inject a closing quote followed by Python code, use Pyodide's js bridge to load Node.js child_process, and execute arbitrary operating system commands as root in the Flowise container. This issue is fixed in version 3.1.3.

Flowise is a drag & drop user interface to build a customized large language model flow. Prior to 3.1.3, the OAuth2 token refresh endpoint POST /api/v1/oauth2-credential/refresh/:credentialId is unauthenticated by design and performs a server-side HTTP request to the credential-controlled accessTokenUrl without SSRF protections. Runtime validation confirmed that the endpoint was reachable without authentication, triggered outbound POST requests to an attacker-controlled server, reflected the full remote response body to the caller through tokenInfo, and sent client_id, client_secret, grant_type=refresh_token, and refresh_token in the request body. This issue is fixed in version 3.1.3.

Apache NiFi 1.5.0 through 2.10.0 support gzip-encoded HTTP requests for the application REST API using a Jersey encoding filter. The framework enforced a configurable maximum request size on the compressed payload rather than the decompressed output, allowing a malicious client to send crafted requests that could consume excessive amounts of memory. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, which relocates response compression to Jetty Server and disables decompression of gzip-encoded HTTP requests.