Breaking the AI Sandbox: Critical Flowise Flaw (CVE-2026-46442) Grants Host-Level RCE

A severe vulnerability discovered in the popular open-source generative AI development platform Flowise allows authenticated users to completely escape its backend sandbox and execute arbitrary system commands on the underlying host server.

Flowise is actively relied upon by technical teams and AI engineering groups to visually orchestrate LLM workflows and build intelligent AI agents. However, a newly disclosed security advisory, tracked as CVE-2026-46442 with a critical CVSS severity score of 9.4, has exposed a dangerous combination of missing route authorization and a sandbox escape mechanism.

According to technical documentation, the vulnerability functions as a two-stage exploit chain that violates distinct architectural security boundaries within the Flowise server layout.

Stage 1: Missing Route-Level Authorization

The entry point of the exploit stems from a critical coding omission within the application’s backend server routing logic. Flowise provides a “Custom JS Function” node that allows developers to run bespoke JavaScript scripts inside an AI flow.

While other highly sensitive routes in the codebase (such as saving chatflows) explicitly call the platform’s checkAnyPermission middleware to gate restricted tiers, the endpoint responsible for processing the custom JavaScript function entirely lacked an authentication gate:

// packages/server/src/routes/node-custom-functions/index.ts
// Registered with no permission middleware:
router.post('/', nodesRouter.executeCustomFunction)

While global /api/v1 authentication boundaries still apply, this missing check means that any valid authenticated standard user, or the holder of a low-privileged API key, can successfully reach and interact with this raw execution endpoint.

Stage 2: The NodeVM Sandbox Escape

To isolate the execution of custom scripts, Flowise is engineered to offload code processing into an external, sandboxed environment provided by an E2B API key. However, if the API key is not actively configured—which represents the vast majority of standard, local, or self-hosted deployments—Flowise silently falls back to executing the JavaScript locally inside a basic NodeVM sandbox container.

Researchers discovered that an attacker could deliberately craft an error-handling payload to force the runtime to leak components of the host architecture. Because the runtime error ultimately originates within the broader host context, its constructor chain resolves right back to the outer, unconstrained Node.js environment.

By traversing up this leaked prototype chain, an attacker can capture the host’s actual Function constructor (e.constructor.constructor). From there, they can directly tap into core Node.js system libraries like child_process and execute commands straight on the server:

// Example sandbox escape sequence used to compromise the host
const FunctionCtor = e.constructor.constructor;
const cp = FunctionCtor('return process.getBuiltinModule("child_process")')();
return cp.execSync('id').toString().trim();

For security professionals, the blast radius of a successful breakout is total server compromise. An authenticated adversary can seamlessly leverage this host remote code execution (RCE) vector to drop persistent web shells, steal sensitive system environment files, exfiltrate hardcoded database secrets or master AI API credentials, and use the server as an internal launching pad to pivot laterally across adjacent internal corporate networks.

The vulnerability impacts all self-hosted and corporate Flowise deployments running version 3.1.1 or lower. Maintainers have addressed the flaw in Flowise version 3.1.2.

Security teams are strongly recommended to deploy the following active countermeasures immediately:

1. Patch Immediately: Update all production instances of Flowise directly to version 3.1.2 or later to apply the necessary route permission checking logic.
2. Enforce Strict Gating: Ensure that the sensitive POST /api/v1/node-custom-function route is completely restricted using the platform’s standard checkPermission middleware patterns to isolate the function away from standard user roles or generic API key tiers.
3. Fail-Closed Sandbox Defaults: Configure application environment setups to fail-closed if a secure, cloud-hosted sandbox API key is missing. The platform should explicitly reject untrusted script execution rather than silently downgrading to an insecure local NodeVM fallback model.

Support Our Threat Intelligence

If you find our CVE report and cybersecurity news helpful, consider supporting our work.

Buy Me a Coffee PayPal

Crypto

USDT (TRC20):

TN8BdV8cp4T1Cd28gK9qTAnZknzzuwyUtm Copy

USDT (ERC20):

0x3725e1a7d3bc5765499fa6aaafe307fabcd75bce Copy

Do Son

Do Son (aka Ddos) is a seasoned news reporter, bringing over a decade of expertise to the forefront of cyber security and technology reporting. My work provides timely and insightful analysis of emerging trends and critical developments in these rapidly evolving sectors.