CVE-2026-119978: Flowise: sandbox escape allows authenticated RCE

HIGH

Published October 30, 2026

CISO Take

Flowise through 3.1.4 has a sandbox escape in its custom function node: an authenticated user can submit JavaScript to /api/v1/node-custom-function that writes a file into the allowlisted mammoth package via LocalFileStore and then requires it, breaking out of vm2 and running OS commands as the Flowise process user. The CVSS is 8.5 (high, scope changed). Exploitation needs a valid low-privilege account and the non-default ALLOW_BUILTIN_DEP=true setting, which limits exposure. There is no CISA KEV listing, no public exploit, no Nuclei template and no EPSS score yet, so there is no evidence of active exploitation today. The risk is still real: Flowise has 179 other CVEs, which points to a recurring sandbox weakness, and it typically holds LLM API keys and database credentials. Check whether ALLOW_BUILTIN_DEP is enabled and disable it or restrict the allowlist now. Upgrade as soon as a fixed release is published, because the advisory lists no patched version, and restrict Flowise access to trusted users.

Sources:NVDGitHub AdvisoryATLASvulncheck.com

What is the risk?

High, but conditional. The attack is network-reachable with no user interaction, and the impact on confidentiality, integrity and availability is high with a changed scope. Attack complexity is high and a low-privilege account is required. The exploit also depends on ALLOW_BUILTIN_DEP=true, which narrows the exposed population. No KEV listing, no public exploit and no EPSS data are available, so likelihood is currently moderate to low. Impact if exploited is severe: full code execution on the host as the Flowise user. The risk rises sharply for multi-tenant or internet-exposed Flowise instances with open self-registration or shared accounts.

How does the attack unfold?

Initial Access

Attacker authenticates to Flowise with a low-privilege account.

AML.T0012

Exploitation

Attacker submits JavaScript to /api/v1/node-custom-function that writes a file into the mammoth package via LocalFileStore.

AML.T0049

Sandbox Escape

The script requires the written file, escaping vm2 and executing OS commands as the Flowise user.

AML.T0050

Impact

Attacker steals stored LLM and database credentials and pivots into connected systems.

AML.T0105

Initial Access

Attacker authenticates to Flowise with a low-privilege account.

AML.T0012

Exploitation

Attacker submits JavaScript to /api/v1/node-custom-function that writes a file into the mammoth package via LocalFileStore.

AML.T0049

Sandbox Escape

The script requires the written file, escaping vm2 and executing OS commands as the Flowise user.

AML.T0050

Impact

Attacker steals stored LLM and database credentials and pivots into connected systems.

AML.T0105

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

8.5 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 25% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACHigh

PRLow

UINone

SChanged

CHigh

IHigh

AHigh

What should I do?

1 step

1) Set ALLOW_BUILTIN_DEP=false, or remove langchain and mammoth from the allowlist, to remove the exploit path. 2) Upgrade Flowise to a release after 3.1.4 once a fixed version is available. Track the GHSA-9gvv-qjj3-2p6g advisory, because no patched version is listed yet. 3) Restrict access to the Flowise UI and API with network controls, SSO and least-privilege roles, and disable open signups. 4) Run Flowise in a hardened container as a non-root user with a read-only filesystem, minimal egress and no host mounts. 5) Rotate the API keys and credentials stored in Flowise if you suspect abuse. 6) Detect: monitor requests to /api/v1/node-custom-function, unexpected writes under node_modules/mammoth, and child processes spawned by the Flowise node process.

How is it classified?

Code ExecutionFrameworkAgentAML.T0012- Valid Accounts AML.T0049- Exploit Public-Facing Application AML.T0050- Command and Scripting Interpreter AML.T0097- Virtualization/Sandbox Evasion

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Art. 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2.6-AI system operation and monitoring

NIST AI RMF

MANAGE 2.3-Response to previously unknown risks

OWASP LLM Top 10

LLM06-Excessive Agency

Frequently Asked Questions

What is CVE-2026-119978?

Is CVE-2026-119978 actively exploited?

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

How to fix CVE-2026-119978?

1) Set ALLOW_BUILTIN_DEP=false, or remove langchain and mammoth from the allowlist, to remove the exploit path. 2) Upgrade Flowise to a release after 3.1.4 once a fixed version is available. Track the GHSA-9gvv-qjj3-2p6g advisory, because no patched version is listed yet. 3) Restrict access to the Flowise UI and API with network controls, SSO and least-privilege roles, and disable open signups. 4) Run Flowise in a hardened container as a non-root user with a read-only filesystem, minimal egress and no host mounts. 5) Rotate the API keys and credentials stored in Flowise if you suspect abuse. 6) Detect: monitor requests to /api/v1/node-custom-function, unexpected writes under node_modules/mammoth, and child processes spawned by the Flowise node process.

What systems are affected by CVE-2026-119978?

This vulnerability affects the following AI/ML architecture patterns: Agent frameworks, Low-code LLM workflow builders, RAG pipelines, Multi-tenant AI platforms.

What is the CVSS score for CVE-2026-119978?

CVE-2026-119978 has a CVSS v3.1 base score of 8.5 (HIGH). The EPSS exploitation probability is 0.32%.

What is the AI security impact?

Affected AI Architectures

Agent frameworksLow-code LLM workflow buildersRAG pipelinesMulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012Valid Accounts

AML.T0049Exploit Public-Facing Application

AML.T0050Command and Scripting Interpreter

AML.T0097Virtualization/Sandbox Evasion

Compliance Controls Affected

EU AI Act: Art. 15

ISO 42001: A.6.2.6

NIST AI RMF: MANAGE 2.3

OWASP LLM Top 10: LLM06

What are the technical details?

Original Advisory

Flowise through 3.1.4 contains a sandbox escape vulnerability that allows authenticated users to execute OS commands by abusing allowlisted langchain and mammoth modules when ALLOW_BUILTIN_DEP=true. Attackers can submit JavaScript to /api/v1/node-custom-function that writes a file into the mammoth package via LocalFileStore and requires it, escaping vm2 as the Flowise process user.

Exploitation Scenario

An attacker obtains or registers a low-privilege Flowise account, for example through a phished user or a shared workspace. They submit JavaScript to /api/v1/node-custom-function that uses LocalFileStore from the allowlisted langchain module to write a malicious file into the mammoth package directory. The script then requires that file, which runs outside the vm2 sandbox with the privileges of the Flowise process. The attacker spawns a shell, reads environment variables holding LLM and database keys, and uses them to reach connected vector stores and internal services.

Weaknesses (CWE)

CWE-749Exposed Dangerous Method or FunctionPrimary CWE-749Exposed Dangerous Method or Function

CWE-749 — Exposed Dangerous Method or Function: The product provides an Applications Programming Interface (API) or similar interface for interaction with external actors, but the interface includes a dangerous method or function that is not properly restricted.

[Architecture and Design] If you must expose a method, make sure to perform input validation on all arguments, limit access to authorized parties, and protect against all possible vulnerabilities.
[Architecture and Design, Implementation] Identify all exposed functionality. Explicitly list all functionality that must be exposed to some user or set of users. Identify which functionality may be: Ensure that the implemented code follows these expectations. This includes setting the appropriate access modifiers where applicable (public, private, protected, etc.) or not marking ActiveX controls safe-for-scripting. accessible to all users restricted to a small set of privileged users prevented from being directly accessible at all

Source: MITRE CWE corpus.