With the plethora of LLMs and AI products available today, it is not uncommon for developers to be subscribed to multiple services at once. Although these services can be very powerful individually, stringing them together into a single, coherent workflow is often anything but straightforward. So it came as no surprise to us that Flowise has become one of the top GitHub repositories in this space.
Flowise advertises itself as a "generative AI development platform for building AI Agents and LLM workflows".It offers a self-hosted option, as well as a cloud/enterprise plan where users can pay for support and additional enterprise features such as multiple workspaces.
Imagine our surprise when we navigated to Flowise's security advisories on GitHub and saw that it was full of high and critical vulnerabilities.
As we reviewed these advisories, our curiosity was piqued even further, and we decided to spend some time reviewing the codebase as well.
Most of the patched issues were of high or critical severity, and the technical details behind them were alarming.
For example, CVE-2025-58434 described how the password reset flow allowed account takeovers.This was due to its original implementation sending the password reset token in the response when requesting a password reset token for an email address of a registered user. Then there are also multiple instances where user input was executed as pure JavaScript, as seen in: CVE-2025-59434, CVE-2025-59528, GHSA-7944-7c6r-55vv, and many more.
There were also account-related issues, which can be used as part of an exploit chain. For example, the password change feature did not require the user to re-enter their password.The email change feature also had a similar issue.
Flowise's custom Model Context Protocol (MCP) node has also been associated with multiple prior Remote Code Execution (RCE) vulnerabilities, including CVE-2026-40933, CVE-2026-41268, CVE-2025-59528, and GHSA-6933-jpx5-q87q. These issues reflect a broader, systemic problem across the AI industry involving the insecure use of stdio MCP servers, as discussed in
Having reviewed all the low-hanging fruit covered thus far, we were determined to sweep the codebase for further vulnerabilities, with a particular focus on identifying Remote Code Execution (RCE) issues. After diving into this massive codebase, we were able to identify 6 more ways to achieve RCE in Flowise ** v3.1.1** and
v3.1.2
As we were writing up this post after having our submissions accepted, Flowise published a batch of vulnerabilities that were reported by ZDI and other researchers. These were vulnerabilities that affected versions prior to 3.1.0
. Interestingly, CVE-2026-41264 was an RCE vulnerability in the CSVAgent
node, which was what we reported as well. This meant that the patch was insufficient, and we were able to find additional vectors to exploit the issue in the patched version.
CVE-2025-26319 describes a sandbox escape vulnerability regarding the use of Flowise's nodevm, a fork of the insecure
vm2
sandboxpuppeteer
and playwright
modules that were permitted within the sandbox. node-fetch
, axios
, and moment
by defaultmoment
vulnerability `CVE-2022-24785`
[CVE-2026-41268](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-cvrr-qhgw-2mm6) exploited the configuration of a Flowise Custom MCP node to inject a `NODE_OPTIONS`
environment variable for a spawned node
process. A part of Flowise's patch was to include NODE_OPTIONS in a denylist validation check, but from our
The other three RCE vulnerabilities we reported were novel and did not have previously documented variants. We identified multiple instances where Flowise permitted users to supply arbitrary options when initialising the TypeORM DataSource class, enabling exploitation of parameters such as
entities
to load and execute arbitrary JavaScript code. The SQL Database Chain and SQLite Record Manager nodes also allowed users to write a SQLite database to an arbitrary file path. We exploited this capability to create a polyglot shell script that was subsequently executed by chromium
when launched via puppeteer
.The following sections provide a technical analysis of all RCE vulnerabilities that we identified in Flowise.
You might be wondering what pandas has to do with this Node.js codebase.
As it turns out, there were a few occurrences where pyodide was used to run Python code. This is because Flowise allows users to write their own pandas
code to process CSV files, if they choose to.
One example is the CSVAgent
node, which can be added to a Chatflow:
We observed that when creating a CSVAgent
node in Flowise, there are 2 sources that we can influence:
csvFileBase64
-
the uploaded CSV file that gets processed.
customReadCSVFunc -
the
pandas
Python code.The first source is csvFileBase64
, which comes from the uploaded CSV file:
The second source is customReadCSVFunc
, which is entered through the Additional Parameters
window:
The maintainers know how dangerous allowing users to execute Python code is, so in order to mitigate against RCEs, the validatePythonCodeForDataFrame()
function was used to validate user input:
Eventually, both sources end up in this Python code that gets executed via pyodide.runPythonAsync()
:
The base64String
variable was not useful to us as the input was base64-encoded before it reached this sink. This encoded string then gets decoded by the Python code.
Since this was a dead-end, we explored customReadCSVFunc
instead.
One way to exploit this sink would be to look for a bypass in the denylist. The good thing is, if we find a bypass, exploitation should be straightforward since the code is run directly on the server.
Alternatively, we can go for a clean exploit by leveraging pandas
itself.pd.read_pickle()
is a prime candidate since we can control the functions called from pd
.read_pickle()
is somewhat of a wrapper that calls pickle.load()
, so in theory we can achieve RCE since we can specify what gets unpickled.
First, we generate the base64-encoded pickled RCE payload that sends a reverse shell to our specified host and port:
We are using a base64-encoded payload because the raw byte string contains null bytes, which will break the exploit later.
Before using the payload directly in the customReadCSVFunc
variable to perform pd.read_pickle()
, we need to take care of a few constraints:
`read_pickle()`
only `pickle.load()`
expects a file handler as well.import
or other related reserved words to use BytesIO
for feeding an object into `read_pickle()`
.`open()`
or other related functions to write the payload to disk to obtain a file handler either.pyodide
sandbox does not have raw socket capabilities.pyodide.http.pyfetch
, which we are unable to due to the need for import
.So, one way to overcome this is to create a custom class that simulates BytesIO
.The main functions called by read_pickle()
are `read()`
and `readline()`
, so we just need to make sure they exist:
Combining this MiniBytesIO
class with the read_pickle()
payload gives us the final PoC.
PoC
Over at Flowise, authenticate and create a new Chatflow:
Drag a CSV Agent
node onto the canvas:
Click on Additional Parameters and fill the PoC in:
Close the window and click the Save
icon on the top right. Then, note the UUID in the current URL, which will be used to trigger the Chatflow later.
Start a listening shell, then, in another terminal, send a curl
command to the following URL (replacing <UUID>
with your UUID) to start the Chatflow and trigger the RCE:
After discovering this vulnerability through manual analysis, we fed this information into Claude to look for variants. It flagged another source (AirtableAgent
) that also utilised Pyodide to execute Python code, but in that case, user input was passed as an encoded base64 string (similar to the base64String
variable we previously saw): Unfortunately, as we determined earlier, this source is not exploitable, since we would not be able to break out of the quotes.
Besides looking for variants, Claude also pointed us to an alternative PoC that can be used to exploit the CSVAgent
sink. Instead of using read_pickle()
, we can simply "import" the os
module from pandas.io.common.os
and this will let us execute os.system()
without hitting the denylist:
The first patch implemented by the developers was flawed, as it only added to the denylist:
Also ensuring that the input starts with read_csv()
:
The new constraints were thus:
read_csv(
read_pickle
However, this patch was bypassed by using the following payload:
This payload satisfied the constraints, and also did not violate the os.
checks.
Subsequently, the developers pushed a separate patch which heavily restricted the input to ensure that read_csv
is the only call the user is allowed to invoke.
Eventually, the entire CSVAgent and AirtableAgent files were removed, as there was an issue with NFKC normalization.
As mentioned earlier in this article, Flowise supports the execution of custom JavaScript code using the POST /api/v1/node-custom-function
endpoint, as demonstrated in the following request and response.
Response for the above request
This custom JavaScript code was executed in a sandbox environment, defaulting to a fork of . The
patriksimek/vm2
version 3.9.25
patriksimek/vm2
The library contains critical security issues and should not be used in production. Maintenance has been discontinued. Consider migrating to ``isolated-vm
.
Flowise's fork of vm2
was outdated and vulnerable to [ CVE-2026-22709](https://github.com/patriksimek/vm2/security/advisories/GHSA-99p7-6v5w-7xg8). The following proof-of-concept demonstrates exploiting
`CVE-2026-22709`
to achieve RCE on Flowise version 3.1.1
.However, we decided to try and identify a sandbox escape specific to Flowise to demonstrate the inherent risk of using the vm2
sandbox in a production context. Early into our investigation, we discovered the axios
, moment
and node-fetch
modules were allowed by default within the vm2
sandbox.
https://github.com/FlowiseAI/Flowise/blob/flowise%403.1.1/packages/components/src/utils.ts#L124
<1> Allows custom JavaScript code to use the axios
, moment
and node-fetch
dependencies by default inside the vm2
sandbox.
<2> If `useSandbox=false`
or the [E2B api key](https://e2b.dev/docs/api-key) were not set, then it defaults to using the `vm2`
sandbox.
Including these external dependencies introduces a potential bypass of the vm2
sandbox. The vm2
sandbox relies on JavaScript proxies to intercept interactions between the sandbox and the host environment. However, built-in functions within imported external dependencies are not proxied, which could allow code execution outside the vm2
sandbox if a code execution sink exists.
Notably, the moment
dependency had a previously reported path traversal vulnerability ( CVE-2022-24785) that could lead to RCE when user input is passed to the
locale
function. The patch for CVE-2022-24785
implemented a regex check to disallow /
or \
characters within a locale name, as shown in the code snippet below.The vulnerable snippet and patch for CVE-2022-24785 in moment
<1> Performs a regex check to disallow /
or \
characters within the provided locale name.
<2> The vulnerable sink that introduced CVE-2022-24785
.
Flowise used moment
version v2.29.3
, which had the CVE-2022-24785
patch applied. However, the patch is ineffective in preventing directory traversal in a sandbox context. The validation function uses the match
function from the provided object, so an object with a `match`
function that always returns `true`
would bypass the validation check, as shown in the following proof-of-concept script.
<1> Bypasses the validation check for CVE-2022-24785
.
Since we had achieved access to a require
sink within the vm2
sandbox, the next goal was to discover a method to save our payload to the local file system. Of note was the File Up for a Datastore, where we found that the uploaded file was saved to /root/.flowise/storage/{organisation_id}/docustore/{store_id}/{filename}
on our Docker deployment using the default STORAGE_TYPE=local
storage type, as shown below along with the uploaded JavaScript payload.
<1> The uploaded JavaScript file using the File Up.
The contents of rce.js that contained a reverse shell payload (nc is installed by default on the Docker deployment).
We could retrieve the organisation ID after authentication and viewing the response from the POST /api/v1/auth/login
endpoint and the store ID after up the file from the POST /api/v1/document-store//process/{_id}
endpoint, as shown in the responses below.
The response from POST /api/v1/auth/login after a successful authentication attempt.
<1> The organisation ID.
The response from POST /api/v1/document-store//process/{_id} after up the rce.js payload using the File Up on the UI
<1> The store ID.
The GIF below demonstrates exploiting this sandbox escape by creating a Custom Function node in an Agentflow, which calls the vulnerable POST /api/v1/node-custom-function
endpoin
The sandbox escape vulnerability was initially reported to Flowise on 10 April 2026. The Flowise team originally attributed the root cause to the outdated vm2
sandbox and believed that updating to the latest version resolved it, as shown in the screenshot below.
As demonstrated in the previous section, the root cause was allowing the moment
dependency in the sandboxed environment. We updated Flowise to commit dddfb3c90eec900d747790a439bd362a764039cd (the latest commit on the
main
branch at the time) to verify the sandbox escape and discovered that the vm2
sandbox was disabled by default due to changes in This breaking change complicated the process of reconfirming the sandbox escape vulnerability. However, we identified that the following files invoke the executeJavaScriptCode
function with the useSandbox=false
option that executed code using the vm2
sandbox:
During the investigation of the above files, an injection issue into the sandboxed code was identified. This was caused by insufficient URL validation of the baseURL
input, as demonstrated in the following code snippets.
<1> Use of the broken isValidURL
validation function, which is shown below.
<2> Injection via the baseURL
setting into the sandboxed code.
<3> Uses the insecure vm2
sandbox.
<1> The JavaScript URL
class does not validate characters in the URL hash fragment. We exploited this insufficient URL validation to inject our original sandbox escape code (as shown below), confirming that the sandbox escape vulnerability persisted in commit dddfb3c90eec900d747790a439bd362a764039cd, which the following GIF confirms.
This alternative method for exploiting the sandbox escape vulnerability was reported to Flowise on 11 April 2026.
We recommended that Flowise migrate to a more secure JavaScript sandbox, such as isolated-vm, which the
vm2
maintainers themselves recommend as a more robust alternativevm2
and moment
from the list of allowed sandbox dependenciesaxios
and node-fetch
dependencies, we continue to discourage reliance on vm2
, given how Flowise supports connecting to custom Model Context Protocol (MCP) servers via the "Custom MCP" node, which leverages the @modelcontextprotocol/sdk dependency. By default, the
CUSTOM_MCP_PROTOCOL=stdio
environment variable enables the use of the StdioClientTransport
MCP client<1> Disallows absolute UNIX paths for the input script file.
<2> Inadequate denylist of dangerous environment variables.
<3> Allows the use of the node
and python3
commands.
From our previous research on exploiting environment variables, it was evident that the environment variable denylist was insufficient to prevent remote execution of arbitrary code. However, perl
— our original method for achieving RCE when users could control python
environment variables — was not installed on the flowiseai/flowise:3.1.2 Docker image. Since our prior research,
@joern
improved upon our findings, identifying a method that does not require perl
We utilised @joern
's method in the following MCP configuration payload; the GIF below demonstrates achieving RCE.
Alternatively, we observed that the spawned MCP server process on the flowiseai/flowise:3.1.2 Docker image did not set the
WORKDIR
and defaulted to /
as the working directory, allowing the use of relative paths to access arbitrary files on the filesystem and bypass Flowise’s absolute path validation checks. We exploited this by setting the input script for the node
command to proc/self/environ
and overwriting the HOME
environment variable, transforming /proc/self/environ
into a valid JavaScript file. This technique is demonstrated in the MCP configuration and GIF below.This issue was patched in PR #6471, which introduced an allowlist for permitted environment variables and changed the default transport mode from the insecure stdio
to sse
. We consider this sufficient to resolve the issue, as users must now explicitly opt into the insecure transport by setting CUSTOM_MCP_PROTOCOL=stdio
.
However, we found a way to bypass the new environment variable allowlist when CUSTOM_MCP_PROTOCOL=stdio
was set.
As noted earlier, the Dockerfile published to Flowise's Docker registry does not set a WORKDIR
, leaving it at the default of /
. This let us bypass the allowlist by reusing the file upload technique from the vm2
sandbox escape section to execute an uploaded JavaScript file, as shown in the following payload.
The following nodes permitted users to specify arbitrary options for the TypeORM DataSource class via the
additionalConfig
node input:Reviewing the documentation for DataSource options revealed that the
entities
, subscribers
, and migrations
options could be exploited to achieve RCE by reading a local JavaScript file. We then applied the same local file-saving technique described in our vm2
sandbox escape vulnerability to exploit the insecure usage of the DataSource
classadditionalConfig
payload and GIF.This issue was resolved in PR #6464, which introduced a denylist blocking dangerous TypeORM DataSource
options such as entities
, subscribers
, and migrations
. While this mitigation prevents our reported payloads, the RCE could resurface if a future TypeORM release introduces a new dangerous option not covered by the denylist.
Flowise enables the creation of database agents by leveraging LangChain's SqlDatabaseChain through its
<1> Allows connecting to a local SQLite database.
<2> Allows the user to provide a file path without validation.
<3> Initialises an instance of LangChain's SqlDatabaseChain.
Allowing connections to a local SQLite database without path validation introduced a critical security risk, as an attacker could write a malicious SQLite database to arbitrary file system locations. Furthermore, the flowiseai/flowise:3.1.2 Docker image runs as
root
, as shown in the Dockerfile
below, granting write access to the entire file system.https://github.com/FlowiseAI/Flowise/blob/flowise-components@3.1.2/docker/Dockerfile
<1> Default user for the node:20-alpine
image was root
and the current user was not changed to a low-privileged user.
However, the following caveats made exploiting the arbitrary file write of SQLite databases more complex:
BaseLanguageModel
input to analyse user prompts and generate SQL queries for execution on the connected database. While Large Language Models (LLMs) could potentially generate malicious SQL queries, most include built-in moderation controls that complicate exploitation.writefile
and load_extension
SQLite functions were not enabled, which could have been leveraged to achieve RCE.SQLite format 3
magic byte header, which can corrupt most other file types.PATH
environment variable.To bypass LLM moderation controls and execute arbitrary SQL queries on the connected SQLite database, we leveraged the basepath
input on an OpenAI node to connect to a web server hosting the below Python code that echoed the SQL query from the input prompt.
Our initial method to demonstrate impact involved directly connecting to /root/.flowise/database.sqlite
, but this only applied to default Docker deployments that had not modified the DATABASE_TYPE environment variable. Alternatively, we demonstrated stored Cross-Site Scripting by writing the SQLite database as a
.html
file to /usr/local/lib/node_modules/flowise/node_modules/flowise-ui/build/
Our next approach focused on writing a malicious Embedded JavaScript ( ejs) template, as
ejs
templates are not affected by the SQLite format 3
magic byte header and the ejs
module was included as a transitive dependency@bull-board/express
MODE=queue
and ENABLE_BULLMQ_DASHBOARD=true
are set. It used the ejs
template engine@bull-board/ui/index.ejs
viewSince the ejs
attack vector was not viable, we shifted our investigation to identify directories in the Flowise container that loaded shell scripts via source
, which does not require execute file permissions. This led to the discovery of the /etc/chromium/chromium.conf
file that is shown below, which is sourced when the Chromium browser is launched.
Further review of the /usr/bin/chromium-browser
executable revealed it was a symbolic link to /usr/lib/chromium/chromium-launcher.sh
(shown below), which sourced all /etc/chromium/*.conf
files.
<1> Uses source
to load all .conf
files in the /etc/chromium/
folder.
We then discovered there was a Puppeteer Web Scraper node on Flowise, where Puppeteer was configured to launch /usr/bin/chromium-browser
via the PUPPETEER_EXECUTABLE_PATH
environment variable.
The next challenge was identifying a method to craft a SQLite database containing a reverse shell payload that would execute when sourced by chromium-launcher.sh
. We addressed this by embedding command substitution within a SQLite table name, ensuring the payload executes before sh
encounters syntax errors while parsing the remaining database content. The following SQL demonstrates how to create the SQLite database and shell script polyglot file.
To chain the full exploit together, we first created a Chatflow that leveraged the SQL Database Chain node to write a crafted SQLite database to /etc/chromium/exploit.conf
. The RCE payload was subsequently triggered when /usr/bin/chromium-browser
was executed by a Puppeteer Web Scraper node in a separate Chatflow, as demonstrated in the following GIF.
We were able to bypass Flowise's patch (PR #6464) for this RCE vulnerability. Unfortunately, Flowise had opted to defer patching the bypass, and no fix had been deployed at the time of publishing.
As this bypass remains unpatched, we have withheld the technical details from this article and left it as an exercise for the reader.
After demonstrating the RCE impact in the SQL Database Chain node, we observed that the SQLite Record Manager node contained a similar weakness: the database
property could be overwritten via the additionalConfig
input, as shown in the following code snippet.
<1> The additionalConfig
input was user controllable.
<2> The intended SQLite database path.
<3> Keyword argument expansion of the additionalConfiguration
variable was performed after the database
variable, which allows overwriting the preceding database
setting.
Once again, we were able to write a SQLite database file to an arbitrary location on the file system. However, the payload used for the SQL Database Chain node could not be applied to the SQLite Record Manager node, as we did not have direct control over the executed SQL statements and the tableName
input was restricted by the /^[a-zA-Z0-9_]+$/
validation pattern, as shown in the code snippet below.
<1> Validates the tableName
input matches the regex pattern /^[a-zA-Z0-9_]+$/
.
<2> The SQL command creating the database table, which is not user controllable.
<3> The this.namespace
is a user controllable input for the node.
This presents a challenge, as the CREATE
SQL statement embedded within the SQLite database includes ()
characters, which result in syntax errors when the file is interpreted as a shell script. The hexdump output below shows this for a SQLite database created using the default upsertion_records
table name for the SQLite Record Manager node.
The original SQLite payload mitigated this by constructing the CREATE
statement as a single line and embedding a #
comment within the table name to neutralize the problematic ()
characters. However, this technique is not viable for the SQLite Record Manager node due to regex table name validation.
We further investigated the raw structure of SQLite database files and used Claude to summarise the cell structure of the doc_id_index
entry containing the problematic ()
characters that is shown below.
<1> \x2f
serial type corresponds to a TEXT
value that is 17 bytes long.
Of particular interest was the length of the header for the table name, where \x2f
is a varint that decodes to the integer 47
. In SQLite, these varints are referred to as serial types, which encode both the data type and, for TEXT
and BLOB
values, the byte length. Since 47
is odd and greater than 13, it is a TEXT
type with a decoded byte length of 47−132=17\frac{47 - 13}{2} = 17247−13=17 (the length of upsertion_records
). We identified that the character '
(\x27
) decodes to a valid TEXT
serial type with a corresponding length of 13 bytes, as demonstrated by the following script.
By setting the tableName
input to a 13-byte string, we are able to inject a '
character into the record header, effectively wrapping the problematic section containing the ()
characters. The quote is then closed using the namespace
input. This allows a reverse shell payload to be injected via namespace
after the closing quote, enabling arbitrary command execution when the SQLite database is interpreted as a shell script during Puppeteer startup, as described in the previous section. The following GIF demonstrates this full exploit chain.
This vulnerability was resolved by the following validateSQLitePath
function, introduced in PR #6464 to mitigate arbitrary file write against SQLite databases.
<1> Always allow writing the database to the $HOME/.flowise
folder.
While we were unable to find a bypass, we remain concerned about allowing users to write SQLite databases to the $HOME/.flowise
folder, and we still recommend that SQLite operations be disabled by default in Flowise.
In this post, we walked through six RCE vulnerabilities we identified in Flowise, along with several bypasses of existing patches for previously disclosed issues. A recurring theme throughout this research was that fixes relying on denylists, module allowlists, or narrow input validation were repeatedly insufficient. As Flowise and similar AI workflow platforms continue to expand their feature sets, we expect this pattern of incomplete remediation to keep surfacing, particularly around sandboxing, environment configuration, and file handling primitives.
As part of this research, we also used Claude's publicly available AI security review capabilities to compare its results against our own human-led analysis. Claude identified some genuine security concerns, but the only RCE vulnerability it raised was the outdated vm2
dependency, rather than the Flowise-specific sandbox escape we discovered. That said, Claude proved valuable in assisting our testing: it identified variants and explained complex concepts quickly, which helped us uncover alternative exploit methods, as shown in the RCE via pandas (CSVAgent) and RCE via the SQLite Record Manager Node sections above. This underscores a broader distinction between AI-driven and AI-assisted discovery: in our experience, the latter consistently surfaced the more nuanced security issues.
Thanks for reading, and we hope you enjoyed the post.