CVE-2025-59528 – Immediate steps for Flowise remote code execution

What breaks and who should care

If your monitoring tool just flagged CVE-2025-59528, the thing that could break is the ability of an attacker to run arbitrary code on any machine that is hosting Flowise. Anyone who has deployed Flowise in production – whether on a single‑node VM, a Docker container, or a Kubernetes pod – should be on high alert. The flaw gives a remote user the chance to execute JavaScript inside the Node.js runtime with the same privileges as the Flowise process. That means they could read or delete files, spawn new processes, or pivot to other services on the host. If you rely on Flowise for any part of your AI workflow, you need to verify exposure now and apply the fix before an attacker can take advantage.

CISA’s confirmed actively-exploited flaws are tracked on our Known Exploited Vulnerabilities tracker, refreshed daily.

Vulnerability overview

Class of flaw

The vulnerability is a classic case of unsafe code evaluation. In JavaScript, the Function() constructor turns a string into executable code at runtime. When user‑supplied data is fed straight into that constructor, the runtime loses any chance to validate or sanitise the input. This pattern is recognised as a remote code execution (RCE) risk because the attacker can supply a payload that the server will run as if it were part of its own source. The problem is not unique to Flowise – any web‑oriented JavaScript platform that evaluates strings without a sandbox is vulnerable to the same class of attack.

Specific mechanism in Flowise

Flowise provides a drag‑and‑drop interface for building large language model pipelines. One of the nodes – called CustomMCP – lets a user supply a configuration string that tells Flowise how to talk to an external MCP server. Internally, Flowise calls a helper called convertToValidJSONString. That helper takes the raw mcpServerConfig string and hands it to the Function() constructor to turn it into a JavaScript object. No validation, no sanitisation, just a direct evaluation.

Because the code runs inside the Node.js process that hosts Flowise, the attacker’s payload inherits all the privileges of that process. In a typical deployment the Flowise process runs as root or as a user with read/write access to the application’s directory and, often, to the host’s file system. From there the payload can require('child_process') and spawn a shell, or require('fs') and read or overwrite any file the process can touch. The NVD entry confirms that the issue has been patched in a later release, but it does not publish the exact version numbers that are safe or unsafe.

Assessing whether you are affected

First step: confirm that Flowise is installed on the host you are checking. The simplest way is to look for the main executable or the Docker image name. On a Linux host you can run:

• ps -ef | grep flowise
• docker ps --filter "ancestor=flowise"
• kubectl get pods -A | grep flowise

If any of those commands return a running process or container, you have Flowise somewhere in your environment. The next question is whether the instance is using the vulnerable code path. The vulnerability lives in the CustomMCP node, so any flow that includes that node is potentially exploitable. Look at the JSON definition of your flows – they are stored in a file called flows.json by default, or in a database if you have configured one. Search for the string “CustomMCP”:

• grep -R "CustomMCP" /path/to/flowise

If the search returns results, you have at least one flow that could trigger the unsafe evaluation. Even if you do not see the node, an attacker could still create one via the web UI if the endpoint is exposed, so the presence of the node is not the only factor – the mere ability to submit a configuration string to that endpoint is enough.

Finally, check the runtime privileges of the Flowise process. Run:

• ps -o pid,user,group,cmd -p $(pgrep -f flowise)

If the user column shows a privileged account (for example, root or a system‑level user with sudo rights), the impact of a successful exploit is higher. If the process runs as an unprivileged user with a very limited file system view, the attacker’s reach is reduced, but the risk is still unacceptable for a critical vulnerability.

Mitigation and remediation

The definitive fix is to move to the patched release that removes the unsafe Function() call. The NVD entry notes that the issue is resolved in a newer version, and the table below lists the affected and fixed releases for each branch. In plain language: upgrade Flowise to the latest release for the branch you are using. Do not try to guess the version number – let your package manager pull the most recent build.

For a typical installation you can apply the upgrade with one of the following commands, depending on how Flowise was installed:

• If you installed via npm globally: npm install -g flowise@latest
• If you are using Docker: pull the newest image and redeploy, e.g. docker pull flowiseai/flowise:latest && docker compose up -d
• If you are on Kubernetes and use a Helm chart: helm upgrade flowise flowise/flowise --set image.tag=latest

After the upgrade, restart the service to make sure the new code is loaded. Verify the version you are now running by asking the application itself – most Flowise instances expose a /api/version endpoint. A quick curl will confirm you are on the patched build:

• curl -s http://localhost:3000/api/version

Once you see the version string that matches the patched release, you can consider the direct code execution vector closed.

What to do if a patched release is not yet available for your environment

In some cases you may be locked to an older branch because of custom integrations or because you run Flowise on a platform that does not yet carry the newest image. If that happens, you have three practical options:

• Isolate the service. Move the Flowise container or process to a network segment that is not reachable from the internet. Block inbound traffic to the UI and API ports at the firewall level, allowing only trusted internal IPs.
• Disable the CustomMCP node. Edit the flow definitions and remove any occurrence of that node. If you cannot edit the UI because it is already vulnerable, do it directly in the stored JSON files and reload the service.
• Apply a local code change. If you have access to the source code, replace the Function() call with a safe JSON parser. For example, change the line that reads new Function('return ' + userInput)() to JSON.parse(userInput). Rebuild the package and redeploy.

All three mitigations reduce the attack surface until you can move to the official patched release. Remember that any mitigation that involves network restriction should be documented and tested – you do not want to lock yourself out of a critical AI pipeline.

Verification after remediation

After you have upgraded or applied a mitigation, run a quick sanity check. The NVD does not publish a public proof‑of‑concept, but you can verify that the unsafe evaluation path no longer exists by attempting to submit a deliberately malformed configuration string. For example, send a request to the CustomMCP endpoint with the payload:

• {"mcpServerConfig":"return process.exit(1);"}

If the server returns a normal error about malformed JSON rather than terminating the process, the vulnerable code path is no longer reachable. If the request still triggers a crash or executes code, you are still on an unsafe build and must repeat the upgrade steps.

Conclusion

CVE-2025-59528 is a critical remote code execution flaw that lives in a single node of Flowise. The risk is real for any deployment that accepts user‑supplied configuration strings, especially when the Flowise process runs with elevated privileges. The fix is straightforward: move to the patched release for your branch. Until you can do that, isolate the service, disable the offending node, or patch the source locally. Use the commands provided to locate the installation, check the version, and verify that the vulnerability is gone. Act now – the longer the vulnerable build stays online, the larger the window for an attacker to exploit it.

Affected versions

NVD has not published machine-readable version ranges for CVE-2025-59528 yet. Check the vendor advisory for the exact affected and fixed releases before you plan an upgrade.