CVE-2024-58351: Flowise RCE and sandbox escape

CISO Take

Flowise before 2.1.4 exposes a critical code injection vulnerability through its overrideConfig parameter, which is enabled by default with no allow-list and accessible without authentication via both the frontend and Prediction API. The underlying sandboxing relies on vm2, a JavaScript sandbox with a well-documented history of escape vulnerabilities, making this an effective unauthenticated path to full server compromise — RCE, SSRF, DoS, prompt injection, and credential exfiltration are all explicitly confirmed attack outcomes. With a CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N) and 94 prior CVEs in this package, Flowise deployments represent a high-concentration risk in AI agent infrastructure where servers typically hold API keys, internal service credentials, and access to proprietary data sources. Organizations using Flowise in any environment reachable from untrusted networks should upgrade to 2.1.4 immediately or firewall the Prediction API to trusted sources only as an interim control.

Sources: NVD GitHub Advisory ATLAS github.com/FlowiseAI vulncheck.com

What is the risk?

Critical. CVSS 9.8 with no authentication, no user interaction, and full network accessibility makes this trivially exploitable at scale. The vm2 sandbox is deprecated and has a history of escape CVEs, validating the real-world exploitability of this attack chain. Default-enabled feature with zero hardening out of the box means every unpatched public-facing Flowise instance is vulnerable. The 94 prior CVEs in this package indicate systemic security debt. No active exploitation or public PoC observed at time of analysis, but the attack complexity is effectively zero once the API endpoint is located.

How does the attack unfold?

Initial Access

Attacker locates an internet-facing Flowise instance and sends an unauthenticated HTTP POST to the Prediction API endpoint with a crafted overrideConfig payload.

AML.T0049

Configuration Injection

The malicious configuration is injected into the Chainflow execution context without validation or allow-list filtering, reaching the vm2 sandbox runtime.

AML.T0081

Sandbox Escape

The attacker exploits vm2's known sandbox escape vulnerabilities through constructor chain abuse or prototype pollution to break out of the JavaScript isolation boundary and gain host-level code execution.

AML.T0105

Impact

Attacker harvests API keys and credentials from server environment variables, establishes a reverse shell for persistence, uses SSRF to pivot to internal services, or crashes the server for denial of service.

AML.T0025

Initial Access

Attacker locates an internet-facing Flowise instance and sends an unauthenticated HTTP POST to the Prediction API endpoint with a crafted overrideConfig payload.

AML.T0049

Configuration Injection

The malicious configuration is injected into the Chainflow execution context without validation or allow-list filtering, reaching the vm2 sandbox runtime.

AML.T0081

Sandbox Escape

The attacker exploits vm2's known sandbox escape vulnerabilities through constructor chain abuse or prototype pollution to break out of the JavaScript isolation boundary and gain host-level code execution.

AML.T0105

Impact

Attacker harvests API keys and credentials from server environment variables, establishes a reverse shell for persistence, uses SSRF to pivot to internal services, or crashes the server for denial of service.

AML.T0025

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Flowise	npm	—	No patch

Do you use Flowise? You're affected.

How severe is it?

CVSS 3.1

9.8 / 10

EPSS

N/A

Exploitation Status

No known exploitation

Sophistication

Trivial

What is the attack surface?

AV Network

AC Low

PR None

UI None

S Unchanged

C High

I High

A High

What should I do?

6 steps

Upgrade to Flowise 2.1.4 immediately — this is the only complete fix.
If patching is not immediately possible: restrict network access to the Prediction API to trusted IP ranges only (firewall/WAF rule).
Audit Flowise server logs for unexpected outbound connections (SSRF indicator) or unusual process spawns.
Rotate all API keys and credentials stored in Flowise environment configuration post-patch, treating them as compromised.
Inventory all Flowise deployments across the organization — this is frequently deployed ad-hoc by development teams.
If overrideConfig is not required for business functionality, confirm the 2.1.4 patch restricts or removes it rather than just adding an allow-list, and test accordingly.

How is it classified?

Code Execution Data Extraction DoS Agent Framework Plugin AML.T0025 - Exfiltration via Cyber Means AML.T0049 - Exploit Public-Facing Application AML.T0050 - Command and Scripting Interpreter AML.T0051 - LLM Prompt Injection AML.T0072 - Reverse Shell AML.T0081 - Modify AI Agent Configuration AML.T0097 - Virtualization/Sandbox Evasion AML.T0105 - Escape to Host

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art.9 - Risk management system

ISO 42001

A.6.2.6 - Information security in AI system development

NIST AI RMF

GOVERN 6.2 - Policies and procedures are in place to address AI risk

OWASP LLM Top 10

LLM04:2023 - Model Denial of Service LLM07:2023 - Insecure Plugin Design

Frequently Asked Questions

What is CVE-2024-58351?

Flowise before 2.1.4 exposes a critical code injection vulnerability through its overrideConfig parameter, which is enabled by default with no allow-list and accessible without authentication via both the frontend and Prediction API. The underlying sandboxing relies on vm2, a JavaScript sandbox with a well-documented history of escape vulnerabilities, making this an effective unauthenticated path to full server compromise — RCE, SSRF, DoS, prompt injection, and credential exfiltration are all explicitly confirmed attack outcomes. With a CVSS of 9.8 (AV:N/AC:L/PR:N/UI:N) and 94 prior CVEs in this package, Flowise deployments represent a high-concentration risk in AI agent infrastructure where servers typically hold API keys, internal service credentials, and access to proprietary data sources. Organizations using Flowise in any environment reachable from untrusted networks should upgrade to 2.1.4 immediately or firewall the Prediction API to trusted sources only as an interim control.

Is CVE-2024-58351 actively exploited?

No confirmed active exploitation of CVE-2024-58351 has been reported, but organizations should still patch proactively.

How to fix CVE-2024-58351?

1. Upgrade to Flowise 2.1.4 immediately — this is the only complete fix. 2. If patching is not immediately possible: restrict network access to the Prediction API to trusted IP ranges only (firewall/WAF rule). 3. Audit Flowise server logs for unexpected outbound connections (SSRF indicator) or unusual process spawns. 4. Rotate all API keys and credentials stored in Flowise environment configuration post-patch, treating them as compromised. 5. Inventory all Flowise deployments across the organization — this is frequently deployed ad-hoc by development teams. 6. If overrideConfig is not required for business functionality, confirm the 2.1.4 patch restricts or removes it rather than just adding an allow-list, and test accordingly.

What systems are affected by CVE-2024-58351?

This vulnerability affects the following AI/ML architecture patterns: agent frameworks, LLM application platforms, AI workflow orchestration, model serving, RAG pipelines.

What is the CVSS score for CVE-2024-58351?

CVE-2024-58351 has a CVSS v3.1 base score of 9.8 (CRITICAL).

What is the AI security impact?

Affected AI Architectures

agent frameworksLLM application platformsAI workflow orchestrationmodel servingRAG pipelines

MITRE ATLAS Techniques

AML.T0025 Exfiltration via Cyber Means

AML.T0049 Exploit Public-Facing Application

AML.T0050 Command and Scripting Interpreter

AML.T0051 LLM Prompt Injection

AML.T0072 Reverse Shell

AML.T0081 Modify AI Agent Configuration

AML.T0097 Virtualization/Sandbox Evasion

AML.T0105 Escape to Host

Compliance Controls Affected

EU AI Act: Art.9

ISO 42001: A.6.2.6

NIST AI RMF: GOVERN 6.2

OWASP LLM Top 10: LLM04:2023, LLM07:2023

What are the technical details?

Original Advisory

Flowise before 2.1.4 allows configuration to be injected into the Chainflow during execution via the overrideConfig option, supported in both the frontend web integration and the backend Prediction API. Because this feature is enabled by default with no allow-list of permitted variables and relies on vm2 for sandboxing, an attacker can abuse it to achieve remote code execution and sandbox escape, denial of service by crashing the server, server-side request forgery, prompt injection, and server variable and data exfiltration. These issues are self-targeted and do not persist to other users.

Exploitation Scenario

An attacker identifies a Flowise instance via Shodan or direct scanning, locates the Prediction API endpoint (typically /api/v1/prediction/<chatflowId>), and sends a crafted POST request with a malicious overrideConfig payload targeting vm2-exploitable properties. The payload is injected into the Chainflow execution context without validation. Using a known vm2 sandbox escape technique (e.g., constructor chain abuse), the attacker breaks out of the JavaScript sandbox and achieves host-level code execution. From there, they harvest API keys from environment variables (OpenAI, Anthropic, database connection strings), establish a reverse shell for persistence, and use SSRF to map and pivot into internal services that Flowise integrates with — including databases, internal APIs, and model serving infrastructure.

Weaknesses (CWE)

CWE-94 Improper Control of Generation of Code ('Code Injection') Primary CWE-94 Improper Control of Generation of Code ('Code Injection')

CWE-94 — Improper Control of Generation of Code ('Code Injection'): The product constructs all or part of a code segment using externally-influenced input from an upstream component, but it does not neutralize or incorrectly neutralizes special elements that could modify the syntax or behavior of the intended code segment.

[Architecture and Design] Refactor your program so that you do not have to dynamically generate code.
[Architecture and Design] Run your code in a "jail" or similar sandbox environment that enforces strict boundaries between the process and the operating system. This may effectively restrict which code can be executed by your product. Examples include the Unix chroot jail and AppArmor. In general, managed code may provide some protection. This may not be a feasible solution, and it only limits the impact to the operating system; the rest of your application may still be subject to compromise. Be careful to avoid CWE-243 and other weaknesses related to jails.

Source: MITRE CWE corpus.