#auth

### Summary Missing chat flow id validation allows an attacker to access arbitrary file. ### Details Commit https://github.com/FlowiseAI/Flowise/commit/8bd3de41533de78e4ef6c980e5704a1f9cb7ae6f and https://github.com/FlowiseAI/Flowise/commit/c2b830f279e454e8b758da441016b2234f220ac7 added check for `filename` when handling file upload operations to prevent path traversal, and additional validation of `chatflowId` and `chatId` from route `/api/v1/attachments`. In some cases, however, `chatflowId` and `chatId` are not validated to ensure they are UUIDs or numbers, which may lead to security issues. **Case 1** When creating new chatflow via `/api/v1/chatflows`, function `addBase64FilesToStorage` is called if there exists base64 file data. Although the `filename` is sanitized, the `chatflowid` comes from request body directly without any validation. An attacker could exploit the path traversal here to write arbitrary file with controlled data. ```typescript export const addBase64Files...

### Summary An arbitrary file read vulnerability in the `chatId` parameter supplied to both the `/api/v1/get-upload-file` and `/api/v1/openai-assistants-file/download` endpoints allows unauthenticated users to read unintended files on the local filesystem. In the default Flowise configuration this allows reading of the local sqlite db and subsequent compromise of all database content. ### Details Both the `/api/v1/get-upload-file` and `/api/v1/openai-assistants-file/download` endpoints accept the `chatId` parameter and pass this to a subsequent call to streamStorageFile(). ``` const chatflowId = req.query.chatflowId as string const chatId = req.query.chatId as string const fileName = req.query.fileName as string ... const fileStream = await streamStorageFile(chatflowId, chatId, fileName, orgId) ``` While streamStorageFile validates that the chatflowId is a UUID and strips traversal sequences from fileName, it performs no validation of chatId. ``` // Validate chatflowId ...

## Description ### Cause of the Vulnerability The `CustomMCP` node allows users to input configuration settings for connecting to an external MCP (Model Context Protocol) server. This node parses the user-provided `mcpServerConfig` string to build the MCP server configuration. However, during this process, it executes JavaScript code without any security validation. Specifically, inside the `convertToValidJSONString` function, user input is directly passed to the `Function()` constructor, which evaluates and executes the input as JavaScript code. Since this runs with full Node.js runtime privileges, it can access dangerous modules such as `child_process` and `fs`. ### Vulnerability Flow 1. **User Input Received**: Input is provided via the API endpoint `/api/v1/node-load-method/customMCP` through the `mcpServerConfig` parameter. 2. **Variable Substitution**: The `substituteVariablesInString` function replaces template variables like `$vars.xxx`, but no security filtering is applie...

### Summary --- A Server-Side Request Forgery (SSRF) vulnerability was discovered in the `/api/v1/fetch-links` endpoint of the Flowise application. This vulnerability allows an attacker to use the Flowise server as a proxy to access internal network web services and explore their link structures. The impact includes the potential exposure of sensitive internal administrative endpoints. ### Details --- #### Vulnerability Overview The `fetch-links` feature in Flowise is designed to extract links from external websites or XML sitemaps. It performs an HTTP request from the server to the user-supplied URL and parses the response (HTML or XML) to extract and return links. The issue arises because the feature performs these HTTP requests **without validating the user-supplied URL**. In particular, when the `relativeLinksMethod` parameter is set to `webCrawl` or `xmlScrape`, the server directly calls the `fetch()` function with the provided URL, making it vulnerable to SSRF attacks. ###...

## Summary An authenticated admin user of **FlowiseAI** can exploit the **Supabase RPC Filter** component to execute **arbitrary server-side code** without restriction. By injecting a malicious payload into the filter expression field, the attacker can directly trigger JavaScript's `execSync()` to launch reverse shells, access environment secrets, or perform any OS-level command execution. This results in **full server compromise** and severe breach of trust boundaries between frontend input and backend execution logic. ## Details FlowiseAI includes a component called `Supabase.ts`, located at: `packages/components/nodes/vectorstores/Supabase/Supabase.ts#L237` <img width="622" height="177" alt="image(3)" src="https://github.com/user-attachments/assets/f30ccd12-4709-44ac-a6ef-8f57a1cb5c3b" /> This creates a function from user-provided string `supabaseRPCFilter` with no filtering, escaping, or sandboxing in place. Any injected JavaScript in this string is compiled and executed **im...

Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions may incorrectly identify the subdomain of a domain name and create a supercookie, which allows remote attackers who control a website that share the same TLD to read cookies set by the application.

Remote staging in Liferay Portal 7.4.0 through 7.4.3.105, and older unsupported versions, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92, 7.3 GA through update 35, and older unsupported versions does not properly obtain the remote address of the live site from the database which, which allows remote authenticated users to exfiltrate data to an attacker controlled server (i.e., a fake “live site”) via the _com_liferay_exportimport_web_portlet_ExportImportPortlet_remoteAddress and _com_liferay_exportimport_web_portlet_ExportImportPortlet_remotePort parameters. To successfully exploit this vulnerability, an attacker must also successfully obtain the staging server’s shared secret and add the attacker controlled server to the staging server’s whitelist.

Multiple cross-site scripting (XSS) vulnerabilities in Liferay Portal 7.3.0 through 7.4.3.111, and Liferay DXP 2023.Q4.0, 2023.Q3.1 through 2023.Q3.4, 7.4 GA through update 92 and 7.3 GA through update 36 allow remote attackers to inject arbitrary web script or HTML via a crafted payload injected into a "Rich Text" type field to (1) a web content structure, (2) a Documents and Media Document Type , or (3) custom assets that uses the Data Engine's module Rich Text field.

During the creation of a new libfuse session with `fuse_session_new`, the operation list was passed as NULL incorrectly. libfuse expects this argument to always point to list of operations. This caused uninitialized memory read and leaks in libfuse.so.

### Impact A stored Cross-Site Scripting (XSS) vulnerability was identified in the `@n8n/n8n-nodes-langchain.chatTrigger` node in n8n. If an authorized user configures the node with malicious JavaScript in the initialMessages field and enables public access, the script will be executed in the browser of anyone who visits the resulting public chat URL. This vulnerability could be exploited for phishing or to steal cookies or other sensitive data from users who access the public chat link, posing a security risk. ### Patches This issue has been patched in version 1.107.0 of n8n. Users should upgrade to version 1.107.0 or later. ### Workarounds Disabling the `n8n-nodes-langchain.chatTrigger` node ([docs](https://docs.n8n.io/hosting/securing/blocking-nodes/)) ### References #18148