CVE-2026-119978 in Flowiseinfo

Summary

by MITRE • 10/30/2026

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.

VulDB is the best source for vulnerability data and more expert information about this specific topic.

Analysis

by VulDB Data Team • 10/30/2026

Flowise versions prior to 3.1.4 are susceptible to a critical sandbox escape vulnerability within its custom function execution environment. This flaw allows authenticated users to bypass security restrictions and achieve arbitrary operating system command execution on the host server. The root cause of this issue lies in the interaction between Flowise's use of the vm2 library for isolating user-supplied JavaScript code and the configuration setting ALLOW_BUILTIN_DEP which, when enabled, permits access to specific Node.js modules such as langchain and mammoth. While these modules are intended to be allowlisted for legitimate functionality, their inclusion creates a pathway for attackers to escape the virtual machine sandbox if they can manipulate how these libraries interact with the file system through local storage mechanisms.

The technical exploitation of this vulnerability centers on the /api/v1/node-custom-function endpoint, which accepts JavaScript code from authenticated users and executes it within an isolated context. An attacker can craft a malicious payload that abuses the LocalFileStore feature associated with the mammoth package. By submitting carefully constructed JavaScript, the attacker forces the application to write arbitrary content into files located within the mammoth node_modules directory or related local storage paths. Because the execution environment retains access to these allowlisted modules and their underlying file system operations, writing a malicious module file allows the attacker to subsequently require it. This action effectively breaks out of the vm2 sandbox because the required module executes in the context of the Flowise process user rather than within the restricted virtual machine scope.

This escape mechanism is particularly dangerous as it leverages standard Node.js functionality that is often permitted for legitimate application features, such as document processing via mammoth or AI integration via langchain. The vulnerability highlights a common architectural weakness where allowlisting specific modules does not guarantee isolation if those modules have side effects like file system access. When ALLOW_BUILTIN_DEP is set to true, the security boundary provided by vm2 becomes porous because the attacker can use the trusted libraries as a bridge to execute untrusted code with elevated privileges. The result is that an authenticated user gains the ability to run operating system commands under the identity of the Flowise application process, which often runs with significant permissions depending on deployment configurations.

The operational impact of this vulnerability is severe, potentially leading to full server compromise if the Flowise service is running as a privileged user or has access to sensitive internal resources. Attackers can exfiltrate data, install backdoors, pivot into other network segments, or disrupt services by modifying system files and executing arbitrary commands. The requirement for authentication means that any valid account on the platform can be exploited, making it accessible to malicious insiders or users who have obtained credentials through phishing or credential stuffing attacks. Furthermore, because the exploit relies on standard library interactions, it may evade signature-based detection systems that do not monitor specific file system writes within node_modules directories during custom function execution.

To mitigate this risk, organizations should immediately update Flowise to version 3.1.4 or later where these sandbox escape vectors have been addressed. If updating is not feasible in the short term, administrators should set ALLOW_BUILTIN_DEP to false unless absolutely necessary for specific workflows that require direct access to built-in dependencies. Additionally, implementing strict input validation on custom function endpoints and restricting file system write permissions within the execution environment can reduce the attack surface. It is also recommended to run Flowise with minimal privileges using a dedicated service account with limited file system access to contain potential damage in case of exploitation. Monitoring logs for unusual activity involving node_modules directories or unexpected process executions can aid in early detection of such attacks.

This vulnerability aligns with CWE-250, which describes execution with unnecessary privileges, and CWE-94, concerning code injection flaws that lead to remote code execution. From a tactical perspective, the exploitation technique maps to MITRE ATT&CK techniques related to command and script interpretation as well as defense evasion through sandbox escape mechanisms. Understanding these mappings helps security teams prioritize patching efforts and enhance monitoring rules to detect similar patterns in other applications that rely on virtual machine isolation for user input processing.

Responsible

VulnCheck

Reservation

10/30/2026

Disclosure

10/30/2026

Moderation

accepted

EPSS

0.00000

KEV

no

Activities

low

Sources

Want to know what is going to be exploited?

We predict KEV entries!