AI Threat AlertCVE-2026-73602: Flowise: vm2 sandbox escape enables RCE
UNKNOWNFlowise, a widely used low-code platform for building LLM agent workflows, ships a JavaScript sandbox (vm2) that authenticated users rely on to run custom code nodes safely — but a flaw in moment.js locale validation lets an attacker craft a fake String object whose match function bypasses the sandbox's path traversal checks, allowing it to load and execute arbitrary JavaScript staged in the document store and break out to full code execution on the host. This isn't remotely exploitable by an anonymous attacker — it requires an authenticated account — which keeps EPSS low (0.00437, top 64th percentile) and explains why it isn't in CISA KEV and has no public exploit or Nuclei template (CISA SSVC: TRACK). The real exposure is any multi-tenant or externally-shared Flowise deployment where low-privilege users can create chatflows or upload documents, since a single hostile or compromised account becomes a path to full host compromise, including whatever LLM API keys, vector DB credentials, or other tenants' flows live on that box. Patch to Flowise 3.1.3 immediately; until then, restrict who can create/edit custom function nodes and upload to the document store, and treat any Flowise instance with external or self-serve user signup as high priority. Detection-wise, watch for unexpected child processes or file reads outside the expected sandbox directory tree originating from the Flowise service.
What is the risk?
Moderate-to-high impact, low near-term exploitation likelihood. The vulnerability grants full sandbox escape and arbitrary code execution (CWE-95), which is severe in consequence, but the attack requires an authenticated Flowise account and non-trivial technical knowledge of vm2 internals and moment.js locale parsing to craft the bypass — placing sophistication at the advanced end. No CVSS score is published, it is absent from CISA KEV, there is no public PoC or Nuclei template, and EPSS sits at 0.00437 (top 64th percentile), all consistent with CISA's own SSVC TRACK decision. Risk concentrates sharply in multi-tenant or open-registration Flowise deployments where the attacker can obtain a low-privilege account cheaply; single-tenant, trusted-user deployments carry much lower practical risk despite the same technical severity.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Flowise | npm | — | No patch |
Do you use Flowise? You're affected.
How severe is it?
What should I do?
1 stepUpgrade to Flowise 3.1.3 or later immediately (patch commit 4211bfc). Until patched, restrict creation/editing of custom function/code nodes and document store uploads to fully trusted administrators only, and avoid exposing Flowise to self-serve or externally-registered users. Review user role assignments for least privilege on any multi-tenant instance. For detection, monitor for anomalous file access outside the expected document-store sandbox path, unexpected child processes spawned by the Flowise Node.js process, and unusual outbound network activity from the Flowise host following code-node executions.
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-73602?
Flowise, a widely used low-code platform for building LLM agent workflows, ships a JavaScript sandbox (vm2) that authenticated users rely on to run custom code nodes safely — but a flaw in moment.js locale validation lets an attacker craft a fake String object whose match function bypasses the sandbox's path traversal checks, allowing it to load and execute arbitrary JavaScript staged in the document store and break out to full code execution on the host. This isn't remotely exploitable by an anonymous attacker — it requires an authenticated account — which keeps EPSS low (0.00437, top 64th percentile) and explains why it isn't in CISA KEV and has no public exploit or Nuclei template (CISA SSVC: TRACK). The real exposure is any multi-tenant or externally-shared Flowise deployment where low-privilege users can create chatflows or upload documents, since a single hostile or compromised account becomes a path to full host compromise, including whatever LLM API keys, vector DB credentials, or other tenants' flows live on that box. Patch to Flowise 3.1.3 immediately; until then, restrict who can create/edit custom function nodes and upload to the document store, and treat any Flowise instance with external or self-serve user signup as high priority. Detection-wise, watch for unexpected child processes or file reads outside the expected sandbox directory tree originating from the Flowise service.
Is CVE-2026-73602 actively exploited?
No confirmed active exploitation of CVE-2026-73602 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-73602?
Upgrade to Flowise 3.1.3 or later immediately (patch commit 4211bfc). Until patched, restrict creation/editing of custom function/code nodes and document store uploads to fully trusted administrators only, and avoid exposing Flowise to self-serve or externally-registered users. Review user role assignments for least privilege on any multi-tenant instance. For detection, monitor for anomalous file access outside the expected document-store sandbox path, unexpected child processes spawned by the Flowise Node.js process, and unusual outbound network activity from the Flowise host following code-node executions.
What systems are affected by CVE-2026-73602?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, RAG pipelines, document processing pipelines, low-code AI orchestration.
What is the CVSS score for CVE-2026-73602?
No CVSS score has been assigned yet.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0011.002Poisoned AI Agent ToolAML.T0050Command and Scripting InterpreterAML.T0105Escape to HostAML.T0107Exploitation for Defense EvasionCompliance Controls Affected
What are the technical details?
Original Advisory
Flowise before 3.1.3 contains a sandbox escape vulnerability in the vm2 JavaScript sandbox that allows authenticated users to execute arbitrary code by exploiting moment locale validation bypass. Attackers can craft a fake String object with a match function that bypasses path traversal checks to load and execute malicious JavaScript files stored in the document store outside the sandbox.
Exploitation Scenario
An attacker obtains a low-privilege authenticated account on a Flowise instance (e.g., a shared internal agent-builder deployment or a multi-tenant SaaS built on Flowise). They upload a malicious JavaScript file to the document store, then create or edit a custom function node whose input crafts a fake String object with a manipulated match method — this exploits Flowise's moment.js locale validation logic to fool vm2's path traversal defenses. When the function node executes, the sandbox loads and runs the attacker's staged file as if it were legitimate, breaking out of the vm2 isolation boundary and executing arbitrary code on the host. From there the attacker can harvest LLM/vector-DB credentials, pivot to other tenants' flows, or use the compromised host as a foothold into the broader environment.
Weaknesses (CWE)
CWE-95Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')CWE-95Improper 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-7133810.0Flowise: unauthenticated file write enables RCE
Same package: flowiseCVE-2025-5952810.0Flowise: Unauthenticated RCE via MCP config injection
Same package: flowiseCVE-2025-619139.9Flowise: path traversal in file tools leads to RCE
Same package: flowiseCVE-2026-409339.9Flowise: RCE via MCP stdio command injection
Same package: flowiseCVE-2026-464429.9Flowise: sandbox escape enables authenticated RCE
Same package: flowise