CVE-2026-46442: Flowiseai Flowise RCE Vulnerability

CVE-2026-46442 Overview

Flowise is a drag-and-drop user interface for building customized large language model (LLM) workflows. CVE-2026-46442 is an authenticated remote code execution (RCE) vulnerability affecting Flowise versions prior to 3.1.2. The POST /api/v1/node-custom-function endpoint lacks route-level authorization, permitting any authenticated user or API key holder to submit arbitrary JavaScript to the Custom JS Function node. When E2B_APIKEY is not configured, the code executes inside a NodeVM sandbox that can be escaped to reach the host process object and invoke child_process. The result is authenticated remote code execution on the Flowise server host. The issue is categorized under [CWE-94] (Improper Control of Generation of Code).

Critical Impact

Any authenticated Flowise user or API key holder can execute arbitrary operating system commands on the Flowise server when E2B_APIKEY is unset, which is the default deployment posture.

Affected Products

• Flowiseai Flowise versions prior to 3.1.2
• Deployments where E2B_APIKEY is not configured (default)
• Self-hosted Flowise instances exposing /api/v1/node-custom-function

Discovery Timeline

• 2026-06-08 - CVE-2026-46442 published to NVD
• 2026-06-11 - Last updated in NVD database

Technical Details for CVE-2026-46442

Vulnerability Analysis

The vulnerability resides in the POST /api/v1/node-custom-function route handler in Flowise. The route accepts a JavaScript payload intended to be evaluated by the Custom JS Function node within an LLM workflow. The handler does not enforce role- or permission-based authorization, treating any authenticated session or API key as sufficient to submit code for execution.

Flowise routes the supplied JavaScript to a NodeVM sandbox when no E2B sandbox key is set. NodeVM is a userland isolation wrapper, not a security boundary. Researchers have repeatedly demonstrated sandbox escapes that traverse from the sandboxed context back to the parent Node.js process object. Once the host process is reachable, an attacker imports child_process and runs arbitrary system commands under the Flowise service account.

Because the default Flowise deployment does not set E2B_APIKEY, the unsafe NodeVM execution path is the production code path for the majority of installations. The vulnerability provides full host-level command execution chained to a single low-privilege HTTP request.

Root Cause

The root cause is twofold. First, the endpoint omits authorization checks that should restrict code submission to privileged roles. Second, the runtime relies on NodeVM as a security boundary, despite NodeVM not being designed to contain adversarial code. The combination converts a feature intended for trusted workflow authors into an RCE primitive for any authenticated principal.

Attack Vector

The attack vector is network-based and requires only low-privilege authentication. An attacker obtains valid credentials or an API key, submits a crafted JavaScript payload to /api/v1/node-custom-function, and uses a known NodeVM escape technique to access the host process object. The payload then invokes child_process.exec or equivalent to run arbitrary commands. No user interaction is required.

No verified public proof-of-concept code is available. See the GitHub Security Advisory GHSA-9rvc-vf7m-pgm2 for vendor details.

Detection Methods for CVE-2026-46442

Indicators of Compromise

• HTTP POST requests to /api/v1/node-custom-function originating from non-administrative accounts or unexpected API keys.
• Child processes such as sh, bash, cmd.exe, powershell.exe, curl, or wget spawned by the Flowise Node.js process.
• Outbound network connections from the Flowise host to unfamiliar IP addresses shortly after Custom JS Function invocations.
• Unexpected file writes under the Flowise working directory or temporary directories by the Flowise service account.

Detection Strategies

• Inspect web server and reverse proxy logs for POST /api/v1/node-custom-function calls and correlate with the authenticating user or API key.
• Monitor process ancestry on the Flowise host and alert when the node process running Flowise spawns shells or system utilities.
• Audit Flowise application logs for Custom JS Function executions that reference process, require, child_process, or constructor chains commonly used in NodeVM escapes.

Monitoring Recommendations

• Enable endpoint detection and response (EDR) coverage on Flowise hosts to capture process creation and command-line telemetry.
• Forward application, proxy, and host telemetry to a centralized SIEM and build detections for the Custom JS Function endpoint.
• Alert on any usage of /api/v1/node-custom-function by accounts that are not designated workflow authors.

How to Mitigate CVE-2026-46442

Immediate Actions Required

• Upgrade Flowise to version 3.1.2 or later, which adds route-level authorization to /api/v1/node-custom-function.
• Rotate all Flowise API keys and user credentials, especially if the server was internet-exposed prior to patching.
• Restrict network access to the Flowise management interface so it is reachable only from trusted administrative networks.
• Review audit logs for prior invocations of the Custom JS Function endpoint and investigate any anomalies on the host.

Patch Information

The vendor released the fix in Flowise 3.1.2. Refer to the Flowise 3.1.2 release notes and the GitHub Security Advisory GHSA-9rvc-vf7m-pgm2 for upgrade guidance.

Workarounds

• Configure E2B_APIKEY so Custom JS Function code executes inside the hardened E2B sandbox instead of NodeVM.
• Place Flowise behind an authenticating reverse proxy that blocks POST /api/v1/node-custom-function for non-administrative principals.
• Run the Flowise process as an unprivileged user inside a container with no outbound internet access to limit post-exploitation impact.
• Disable or remove API keys that do not require Custom JS Function access.

# Example reverse proxy rule (nginx) blocking the vulnerable route
location = /api/v1/node-custom-function {
    allow 10.0.0.0/24;   # admin subnet
    deny  all;
    proxy_pass http://flowise_upstream;
}