# Cruising for Shells in Flowise – 6 RCEs That Rode Flowise Low and Slow > Source: > Published: 2026-08-04 01:21:41+00:00 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](https://flowiseai.com/) 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](https://github.com/FlowiseAI/Flowise/security) 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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-wgpv-6j63-x5ph) 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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-435c-mg9p-fv22), [CVE-2025-59528](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3gcm-f6qx-ff7p), [GHSA-7944-7c6r-55vv](https://github.com/FlowiseAI/Flowise/security/advisories/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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-fjh6-8679-9pch) did not require the user to re-enter their password.The [email change feature](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-x39m-3393-3qp4) 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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-c9gw-hvqq-f33r), [CVE-2026-41268](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-cvrr-qhgw-2mm6), [CVE-2025-59528](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3gcm-f6qx-ff7p), and [GHSA-6933-jpx5-q87q](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-6933-jpx5-q87q). These issues reflect a broader, systemic problem across the AI industry involving the insecure use of [ stdio MCP servers](https://modelcontextprotocol.io/specification/2025-06-18/basic/transports#stdio), 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](https://github.com/FlowiseAI/Flowise/security/advisories?state=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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-3hjv-c53m-58jj) 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](https://github.com/FlowiseAI/Flowise/security/advisories/GHSA-5w3r-f6gm-c25w) describes a sandbox escape vulnerability regarding the use of [Flowise's nodevm](https://github.com/FlowiseAI/nodevm), a fork of the insecure `vm2` sandbox`puppeteer` and `playwright` modules that were permitted within the sandbox. `node-fetch` , `axios` , and `moment` by default`moment` 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](https://github.com/FlowiseAI/Flowise/pull/5667), 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](https://typeorm.io/docs/data-source/data-source), 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](https://pandas.pydata.org/) has to do with this Node.js codebase. As it turns out, there were a few occurrences where [pyodide](https://pyodide.org/en/stable/) 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 `` 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](https://github.com/FlowiseAI/Flowise/pull/6257/changes) 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](https://github.com/FlowiseAI/Flowise/pull/6313) 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](https://github.com/FlowiseAI/Flowise/pull/6499), as there was an [issue](https://github.com/FlowiseAI/Flowise/pull/6476) 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 ](https://github.com/FlowiseAI/nodevm). 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](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy) 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](https://github.com/moment/moment/security/advisories/GHSA-8hfj-j24r-96c4)) 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 Uploader 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 Uploader. *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 uploading the file from the `POST /api/v1/document-store/loader/process/{loader_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/loader/process/{loader_id} after uploading the rce.js payload using the File Uploader 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](https://github.com/FlowiseAI/Flowise/tree/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](https://github.com/FlowiseAI/Flowise/tree/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](https://github.com/laverdet/isolated-vm), which the `vm2` maintainers themselves recommend as a more robust alternative`vm2` and `moment` from the list of allowed sandbox dependencies`axios` 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](https://github.com/modelcontextprotocol/typescript-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](https://www.elttam.com/blog/env), 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](https://hub.docker.com/layers/flowiseai/flowise/3.1.2/images/sha256-ddba104d8e50fbc1e72c6fe021d012be83e66d78d26816e1a6a3fddab4212eff). 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](https://hub.docker.com/layers/flowiseai/flowise/3.1.2/images/sha256-ddba104d8e50fbc1e72c6fe021d012be83e66d78d26816e1a6a3fddab4212eff) 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](https://github.com/FlowiseAI/Flowise/pull/6471), which introduced an allowlist for permitted environment variables and [changed the default transport mode](https://github.com/FlowiseAI/Flowise/pull/6471/changes#diff-82430a299b44908325143d6e577e38f2505f6a7ceccb57e41e68eaad98850b21R186) 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](https://github.com/FlowiseAI/Flowise/blob/ba6a089d2bac19f5c07e8378e78bfd1af5d66019/docker/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](https://typeorm.io/docs/data-source/data-source) class via the `additionalConfig` node input:[Reviewing the documentation for DataSource options](https://typeorm.io/docs/data-source/data-source-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` class`additionalConfig` payload and GIF.This issue was resolved in [PR #6464](https://github.com/FlowiseAI/Flowise/pull/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](https://github.com/langchain-ai/langchainjs/blob/589f29ce844eb252c2d5e6b0f8d26de37763a0d7/libs/langchain-classic/src/chains/sql_db/sql_db_chain.ts#L68) 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](https://github.com/langchain-ai/langchainjs/blob/589f29ce844eb252c2d5e6b0f8d26de37763a0d7/libs/langchain-classic/src/chains/sql_db/sql_db_chain.ts#L68). 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](https://hub.docker.com/layers/flowiseai/flowise/3.1.2/images/sha256-ddba104d8e50fbc1e72c6fe021d012be83e66d78d26816e1a6a3fddab4212eff) 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](https://github.com/FlowiseAI/Flowise/blob/flowise-components%403.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](https://docs.flowiseai.com/configuration/databases). 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](https://ejs.co/), 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](https://github.com/FlowiseAI/Flowise/blob/0c6924bb08a2156513b447d0e600651f29ea5aa8/packages/components/nodes/documentloaders/Puppeteer/Puppeteer.ts), where [Puppeteer](https://pptr.dev/) 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](https://github.com/FlowiseAI/Flowise/pull/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](https://sqlite.org/fileformat2.html#varint) that decodes to the integer `47` . In SQLite, these varints are referred to as [serial types](https://sqlite.org/fileformat2.html#serialtype), 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](https://github.com/FlowiseAI/Flowise/pull/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.