AI Threat Alert
CVE-2026-69253: Flowise: code injection in agent tools escapes vm2 sandbox
GHSA-wg86-r78f-74mp CRITICALFlowise's AgentAsTool, ChatflowTool, and ExecuteFlow components build sandboxed JavaScript by string-concatenating a user-supplied baseURL directly into code, and the only guard was a URL-format check that doesn't stop string-breakout characters — so an authenticated user can inject arbitrary JavaScript that escapes the in-process vm2 sandbox and runs as the Flowise server process. This is rated critical and requires only an authenticated session, not admin rights, which is a low bar in any multi-tenant Flowise deployment; however, EPSS sits at just 0.31% (top 76th percentile), it's not in CISA KEV, has no public exploit or Nuclei template, and CISA SSVC scores it TRACK — so there's no evidence of active or imminent exploitation. The real risk driver is architectural: vm2 is a known-weak, effectively unmaintained sandbox with a documented history of escapes, and this Flowise package alone carries 158 other CVEs, signaling a broader pattern of insufficient isolation in this low-code LLM agent builder. Patch to Flowise 3.1.3 immediately — it passes baseURL as data instead of interpolating it into code and adds stricter validation; until patched, restrict who can create or edit AgentAsTool, ChatflowTool, and ExecuteFlow configurations, and treat any Flowise instance as a single trust boundary since a malicious authenticated user can pivot to full host compromise.
What is the risk?
Rated critical primarily on impact (full RCE as the Flowise process user), not on current exploitability. Attack complexity is low from a technical standpoint (a straightforward code-injection/string-breakout, not a novel research technique) but exploitation requires an authenticated Flowise account, which limits opportunistic internet-wide exploitation while leaving multi-tenant, self-hosted, or shared-team Flowise instances exposed to any user with a login — including low-privilege collaborators. No KEV listing, no public PoC/exploit, no Nuclei template, EPSS 0.31% (top 76th percentile), and CISA SSVC TRACK all indicate exploitation has not been observed in the wild and isn't imminently expected. The package's track record (158 prior CVEs, 0/100 internal risk score, 0 downstream npm dependents suggesting most usage is direct/self-hosted rather than embedded) argues for treating Flowise as an immature security surface deserving conservative access controls regardless of this specific CVE's current EPSS score.
How does the attack unfold?
What systems are affected?
How severe is it?
What should I do?
1 step-
1) Upgrade flowise and flowise-components to 3.1.3 or later immediately — this is the definitive fix (data-only URL passing + stricter validation). 2) Until patched, restrict creation/editing of AgentAsTool, ChatflowTool, and ExecuteFlow nodes to trusted administrators only, and avoid exposing self-hosted Flowise instances to untrusted or low-privilege authenticated users. 3) Review authentication and authorization boundaries — this vuln only requires an authenticated session, so any Flowise instance with open registration or broadly shared credentials is at higher risk. 4) Post-patch, audit logs/process history for anomalous child processes or outbound network connections originating from the Flowise server process around the time affected tool configurations were last modified. 5) Given vm2's known weaknesses, evaluate whether Flowise's broader sandboxing model (not just this CVE) meets your risk tolerance for any deployment handling sensitive data or credentials.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-69253?
Flowise's AgentAsTool, ChatflowTool, and ExecuteFlow components build sandboxed JavaScript by string-concatenating a user-supplied baseURL directly into code, and the only guard was a URL-format check that doesn't stop string-breakout characters — so an authenticated user can inject arbitrary JavaScript that escapes the in-process vm2 sandbox and runs as the Flowise server process. This is rated critical and requires only an authenticated session, not admin rights, which is a low bar in any multi-tenant Flowise deployment; however, EPSS sits at just 0.31% (top 76th percentile), it's not in CISA KEV, has no public exploit or Nuclei template, and CISA SSVC scores it TRACK — so there's no evidence of active or imminent exploitation. The real risk driver is architectural: vm2 is a known-weak, effectively unmaintained sandbox with a documented history of escapes, and this Flowise package alone carries 158 other CVEs, signaling a broader pattern of insufficient isolation in this low-code LLM agent builder. Patch to Flowise 3.1.3 immediately — it passes baseURL as data instead of interpolating it into code and adds stricter validation; until patched, restrict who can create or edit AgentAsTool, ChatflowTool, and ExecuteFlow configurations, and treat any Flowise instance as a single trust boundary since a malicious authenticated user can pivot to full host compromise.
Is CVE-2026-69253 actively exploited?
No confirmed active exploitation of CVE-2026-69253 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-69253?
1) Upgrade flowise and flowise-components to 3.1.3 or later immediately — this is the definitive fix (data-only URL passing + stricter validation). 2) Until patched, restrict creation/editing of AgentAsTool, ChatflowTool, and ExecuteFlow nodes to trusted administrators only, and avoid exposing self-hosted Flowise instances to untrusted or low-privilege authenticated users. 3) Review authentication and authorization boundaries — this vuln only requires an authenticated session, so any Flowise instance with open registration or broadly shared credentials is at higher risk. 4) Post-patch, audit logs/process history for anomalous child processes or outbound network connections originating from the Flowise server process around the time affected tool configurations were last modified. 5) Given vm2's known weaknesses, evaluate whether Flowise's broader sandboxing model (not just this CVE) meets your risk tolerance for any deployment handling sensitive data or credentials.
What systems are affected by CVE-2026-69253?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, low-code LLM orchestration platforms, multi-agent tool-calling pipelines.
What is the CVSS score for CVE-2026-69253?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0012 Valid Accounts AML.T0050 Command and Scripting Interpreter AML.T0053 AI Agent Tool Invocation Compliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An adversary who has obtained (or purchased/phished) low-privilege but valid credentials to a shared or multi-tenant Flowise instance creates or edits an AgentAsTool, ChatflowTool, or ExecuteFlow node and sets its baseURL field to a value that passes the isValidURL check but contains characters that terminate the surrounding JavaScript string literal — for example closing the string and appending a payload like require('child_process').exec(...). When the flow executes, Flowise builds the vm2 sandbox script by directly concatenating this value into source code; the injected JavaScript runs inside vm2, which — due to its documented sandbox-escape weaknesses and shared-process design — allows the payload to reach out of the sandbox and execute as the Flowise Node.js process itself. From there the attacker has arbitrary code execution on the server, enabling credential theft (LLM API keys, DB connection strings), lateral movement, or full takeover of the AI agent platform and every flow/chatbot it hosts.
Weaknesses (CWE)
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Primary
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Primary
CWE-95 Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection') 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").
- [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, denylis
Source: MITRE CWE corpus.
References
Timeline
Related Vulnerabilities
CVE-2025-71338 10.0 Flowise: unauthenticated file write enables RCE
Same package: flowise CVE-2025-59528 10.0 Flowise: Unauthenticated RCE via MCP config injection
Same package: flowise CVE-2025-61913 9.9 Flowise: path traversal in file tools leads to RCE
Same package: flowise CVE-2026-40933 9.9 Flowise: RCE via MCP stdio command injection
Same package: flowise CVE-2026-46442 9.9 Flowise: sandbox escape enables authenticated RCE
Same package: flowise