Six Remote Code Execution Flaws Discovered in Flowise AI Workflow Platform
Six critical remote code execution vulnerabilities have been found in Flowise, an open-source AI workflow server platform, potentially exposing sensitive data and connected systems.
Six newly disclosed remote code execution (RCE) vulnerabilities have been identified in the Flowise AI workflow server platform, versions 3.1.1 and 3.1.2. These flaws, discovered by researchers at Elttam, could allow authenticated attackers to execute arbitrary commands on the underlying server, posing a significant risk to data, credentials, and integrated business systems.
The vulnerabilities stem from issues within several Flowise components, including its CSV processing capabilities, custom JavaScript functions, database nodes, and record management features. Elttam noted that previous security patches were incomplete, enabling them to discover new attack vectors. Flowise's common integration with sensitive business tools, files, and external services means a successful compromise could grant attackers a substantial foothold within an organization's network.
One of the identified flaws resides in the CSVAgent feature, which allows users to process uploaded CSV files using custom pandas code. Despite Flowise's use of a denylist to prevent risky Python functions, attackers could exploit pandas functionality to execute commands outside the intended data-processing scope. Although an initial patch attempted to mitigate unsafe deserialization, researchers found a bypass that could still leverage pandas to interact with the operating system. Following this discovery, the developers removed the affected CSVAgent and AirtableAgent files due to normalization concerns.
Another critical vulnerability was found in Flowise's implementation of the vm2 JavaScript sandbox. By default, the sandbox allowed certain external modules, such as 'moment.' Researchers leveraged this access to escape the sandbox environment and execute code directly on the host server. This finding echoes previous concerns about insecure integrations within Flowise's Managed Compute Platform (MCP) that could undermine assumed security protections.
Further issues include an environment-variable injection flaw within Custom MCP configurations, where attackers could abuse settings passed to spawned processes, including Python-related variables, to trigger code execution. While Flowise had implemented checks for dangerous values, a bypass was reportedly still unpatched at the time of the report. Three additional vulnerabilities were discovered in the TypeORM DataSource options, the SQL Database Chain node, and the SQLite Record Manager node, each allowing for unsafe loading or writing of attacker-controlled content, potentially leading to code execution when combined with other Flowise functionalities.
These findings underscore the critical need for robust security measures in AI workflow infrastructure, treating it with the same diligence as any other internet-facing application. MCP integrations, while powerful, can introduce dangerous trust paths if not properly secured. Administrators are strongly advised to update Flowise to the latest versions, review all deployed nodes, and disable or remove any unnecessary components.
To mitigate these risks, organizations should avoid exposing administrative interfaces and APIs directly to the public internet, especially in environments where users can submit code or sensitive configuration data. Treating MCP server settings as untrusted input and limiting the permissions granted to AI workflow processes are crucial steps. Running Flowise with a non-root account, isolating it within a restricted environment, and closely controlling file-system access can significantly reduce the potential damage from a successful exploit.
Security teams should actively monitor for unusual activity, such as unexpected child processes, suspicious outbound network connections, unauthorized changes to workflow configurations, and anomalous file uploads. Elttam also recommended moving away from denylist-based validation towards more secure models like allowlists and ensuring a strong separation between untrusted code and the host environment.