CVE-2026-69253 in Flowise
Summary
by MITRE • 08/04/2026
Flowise is a drag-and-drop user interface for building customized large language model (LLM) flows. Prior to version 3.1.3, several custom-tool components — AgentAsTool, ChatflowTool, and ExecuteFlow — ran code in the in-process vm2 sandbox. To build that code, they inserted a user-controlled baseURL value straight into the JavaScript source, for example const url = "${baseURL}/..."; . The only check on baseURL was isValidURL , but a valid-looking URL can still contain characters that break out of a code string. An authenticated user could craft a baseURL that passed this check, closed the surrounding string, and injected their own JavaScript into the sandboxed script (code injection, CWE-94). The vm2 sandbox runs in the same Node.js process as Flowise and exposes risky dependencies. As a result, the injected code could escape the sandbox and run arbitrary code on the Flowise server as the Flowise process user. Exploitation only requires an authenticated session. The issue is fixed in version 3.1.3, which passes the URL to the sandbox as data instead of inserting it into code and adds stricter URL validation.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 08/04/2026
Flowise represents a significant vulnerability in its handling of user-controlled input within sandboxed execution environments, specifically affecting versions prior to 3.1.3. The platform's custom-tool components including AgentAsTool, ChatflowTool, and ExecuteFlow were designed to execute code within vm2 sandboxes, which are intended to provide isolation for untrusted JavaScript execution. However, these components failed to properly sanitize user-provided baseURL values before incorporating them into JavaScript source code strings, creating a critical code injection vector that bypassed the intended security boundaries.
The vulnerability stems from inadequate input validation and improper string interpolation techniques within the code generation process. When users provided baseURL values, the system inserted these inputs directly into JavaScript source code using template literals without proper sanitization or encoding. While Flowise implemented a basic isValidURL check, this validation was insufficient as it only verified URL syntax rather than examining for potential injection characters that could break out of string contexts. This weakness aligns with CWE-94, which describes the improper execution of code due to inadequate input validation and code generation practices.
The operational impact of this vulnerability extends far beyond simple code injection, as the vm2 sandbox operates within the same Node.js process as Flowise itself, creating a direct path for privilege escalation. When malicious JavaScript was injected into the sandboxed environment, it could escape the intended isolation boundaries and execute arbitrary code with the privileges of the Flowise process user. This presents a severe risk for server compromise, particularly since exploitation requires only an authenticated session, making it accessible to any user with valid credentials. The attack vector demonstrates how insufficient input sanitization can create chain reactions that undermine fundamental security assumptions about sandboxed execution environments.
The remediation implemented in version 3.1.3 addresses the core issues through proper data handling and enhanced validation measures. The fix ensures that URLs are passed to the sandbox as isolated data rather than being interpolated directly into JavaScript source code, eliminating the injection opportunity. Additionally, the updated validation mechanism provides stricter checks that prevent malicious characters from bypassing basic syntax verification. This approach aligns with security best practices for input sanitization and demonstrates proper separation of concerns between data and code execution contexts. Organizations using Flowise should prioritize immediate upgrade to version 3.1.3 or later to address this vulnerability, as the risk of server compromise remains significant for unpatched installations. The incident underscores the critical importance of proper input validation even within sandboxed environments and highlights how seemingly innocuous validation functions can create exploitable gaps in security architecture.