Summary
Flowise contains a code-injection vulnerability in its custom JavaScript execution path because caller-controlled VM options can override default security restrictions. An authenticated attacker who can reach the custom-functions route may enable access to sensitive Node.js modules and execute operating-system commands with the Flowise server's privileges.
Flowise contains a code-injection vulnerability in its custom JavaScript execution path because caller-controlled VM options can override default security restrictions. An authenticated attacker who can reach the custom-functions route may enable access to sensitive Node.js modules and execute operating-system commands with the Flowise server's privileges.
Affected context
The issue affects Flowise deployments that expose the custom-functions execution route and use the vulnerable JavaScript utility implementation. It becomes risky when an authenticated user can submit or invoke custom functions that reach executeJavaScriptCode() and influence its nodeVMOptions, particularly the settings governing built-in module access.
The issue affects Flowise deployments that expose the custom-functions execution route and use the vulnerable JavaScript utility implementation. It becomes risky when an authenticated user can submit or invoke custom functions that reach executeJavaScriptCode() and influence its nodeVMOptions, particularly the settings governing built-in module access.
Exploit preconditions
- Attack surface: The authenticated custom-functions route and JavaScript execution utility
- Required access: Valid authentication plus authorization to invoke or submit a custom function
- Trigger point: Execution of a custom function that calls the JavaScript runner with altered VM options
- Why exploitation is possible: Caller-provided options can override restrictive defaults, allowing access to powerful Node.js functionality capable of launching operating-system processes
- Attack surface: The authenticated custom-functions route and JavaScript execution utility
- Required access: Valid authentication plus authorization to invoke or submit a custom function
- Trigger point: Execution of a custom function that calls the JavaScript runner with altered VM options
- Why exploitation is possible: Caller-provided options can override restrictive defaults, allowing access to powerful Node.js functionality capable of launching operating-system processes
Why this happens
The vulnerability results from merging caller-controlled sandbox options over security-sensitive default settings without sufficiently restricting or validating those overrides. This allows untrusted JavaScript execution to change the module-access policy of the Node.js VM and reach capabilities intended to remain unavailable.
The behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced input changes the execution environment for dynamically evaluated code and enables unintended command execution.
The vulnerability results from merging caller-controlled sandbox options over security-sensitive default settings without sufficiently restricting or validating those overrides. This allows untrusted JavaScript execution to change the module-access policy of the Node.js VM and reach capabilities intended to remain unavailable.
The behavior maps to CWE-94: Improper Control of Generation of Code, because attacker-influenced input changes the execution environment for dynamically evaluated code and enables unintended command execution.
Potential impact
- An attacker may execute arbitrary operating-system commands on the Flowise server
- Commands could run with the privileges of the Flowise service, potentially including root
- Sensitive application data, credentials, and environment secrets could be exposed
- The attacker could modify flows, services, or stored data
- The host could be used for persistence, lateral movement, or further compromise
- An attacker may execute arbitrary operating-system commands on the Flowise server
- Commands could run with the privileges of the Flowise service, potentially including root
- Sensitive application data, credentials, and environment secrets could be exposed
- The attacker could modify flows, services, or stored data
- The host could be used for persistence, lateral movement, or further compromise
General mitigation guidance
Mitigation generally focuses on preventing untrusted callers from changing sandbox security boundaries.
Common defensive patterns include:
- Keeping dangerous VM options under server-side control rather than accepting them from callers
- Allowing only a narrowly defined set of JavaScript capabilities and built-in modules
- Using an explicit allowlist for modules and rejecting security-sensitive overrides
- Separating custom-code execution into a strongly isolated, least-privileged worker
- Running the service without root privileges and limiting filesystem, network, and process capabilities
- Applying authorization policies that restrict access to custom-function execution
- Treating user-authored flows and custom functions as untrusted input
- Using resource limits, read-only filesystems, and separate credentials for execution workers
Mitigation generally focuses on preventing untrusted callers from changing sandbox security boundaries.
Common defensive patterns include:
- Keeping dangerous VM options under server-side control rather than accepting them from callers
- Allowing only a narrowly defined set of JavaScript capabilities and built-in modules
- Using an explicit allowlist for modules and rejecting security-sensitive overrides
- Separating custom-code execution into a strongly isolated, least-privileged worker
- Running the service without root privileges and limiting filesystem, network, and process capabilities
- Applying authorization policies that restrict access to custom-function execution
- Treating user-authored flows and custom functions as untrusted input
- Using resource limits, read-only filesystems, and separate credentials for execution workers
How teams detect issues like this
Detection can include:
- Static analysis rules for dynamic code execution and user-controlled sandbox or VM configuration
- Code review checks for option merges where caller input can override security-sensitive defaults
- Searches for unrestricted Node.js built-in module access, process-spawning APIs, and custom-function execution routes
- Runtime monitoring for unexpected child processes, shell commands, privilege changes, or outbound connections from Flowise
- Authorization and policy checks confirming that only approved roles can invoke custom JavaScript
- Automated security review tools that flag dangerous module imports and unsafe execution-boundary changes
Detection can include:
- Static analysis rules for dynamic code execution and user-controlled sandbox or VM configuration
- Code review checks for option merges where caller input can override security-sensitive defaults
- Searches for unrestricted Node.js built-in module access, process-spawning APIs, and custom-function execution routes
- Runtime monitoring for unexpected child processes, shell commands, privilege changes, or outbound connections from Flowise
- Authorization and policy checks confirming that only approved roles can invoke custom JavaScript
- Automated security review tools that flag dangerous module imports and unsafe execution-boundary changes
