Unauthenticated takeover flaw in AI builder Flowise (CVE-2024-58351): Update to 2.1.4

A critical flaw that lets an attacker take over a server with no login required has been found in Flowise, the popular tool for building AI chatbots and AI agents without writing code. It is tracked as CVE-2024-58351, rated CVSS 9.8 out of 10. The U.S. vulnerability database NVD formally published it on June 20, 2026. Every Flowise version before 2.1.4 is affected, and you should update to the fixed 2.1.4 or later.

The problem lives in a Flowise feature called overrideConfig. It is a convenience that lets you swap in runtime settings when you call a flow from the outside. The trouble is that this swap was open to anyone by default, with no allow list and no opt-out. By pushing a malicious config, an attacker can break out of the lightweight execution box (sandbox) that Flowise relies on and run arbitrary programs on the server. No login, no user click needed.

The flaw itself is old: the vendor warned about it in November 2024 and patched it in 2.1.4. It made the news again because NVD reassigned it a formal CVE number and a top-tier score. And Flowise, starting from this same overrideConfig root, has had takeover holes surface again and again, with real-world attacks observed in 2026. Don't write it off as an old bug. Treat it as the prompt to check whether your own Flowise is safe right now.

What Flowise actually does

Flowise is an open-source tool that lets you build AI chatbots, AI agents, and "let an AI answer from your internal documents" setups (RAG) just by connecting blocks on a canvas. Because you can assemble an AI app without programming knowledge, it is widely used as a "no-code / low-code way to build AI." Its GitHub star count is over 53,000, making it one of the most popular tools in the space.

There are two main ways to use it. One is to rent the official cloud; the other is to run it on your own server, known as self-hosting. The flaw bites in the second case. Flowise can be stood up on AWS, Azure, GCP, or an internal Linux box with a few commands like npm install -g flowise. That ease is exactly why huge numbers of instances sit around the world: left running after a quick test, or exposed to the internet with default settings.

By its nature, Flowise tends to become a collection point for sensitive credentials: API keys that power the AI (the OpenAI or Anthropic keys tied directly to your bill), connection details for internal databases, the internal documents and manuals loaded into RAG, and customer chat histories. All of it gathers on a single Flowise box. Understanding that makes it clear what flows out when a takeover happens.

One config swap, and whoever holds the AI's backend walks off with what

A score of CVSS 9.8 is hard to connect to your own losses, so let's first describe concretely who reaches for that Flowise config swap, and what they are after. Flowise sits where the AI's faucet and the data reservoir are joined into one place. What pours out when that joint is pried open is the real danger of this flaw.

First to swarm in are the people who profit on someone else's AI budget. They take leaked API keys, run massive volumes of requests, resell the access on underground markets, or quietly use it to power their own service for free. The classic outcome is noticing only when the invoice has ballooned. Next come the data thieves who siphon off the internal databases wired behind Flowise, or the contracts, HR files, and customer-support manuals fed into RAG. Then come botnet operators who want to repurpose your always-on cloud server for crypto mining or as a relay. What they want is not abstract "data" but concrete goods: the OpenAI key, the internal DB password, the customer chat logs, the server's compute. The moment a single malicious config lands in overrideConfig, all of that passes straight into their hands, and the server itself is taken over.

In security terms, an AI app platform is an ideal launch pad for both "reconnaissance" and "lateral movement." Flowise is often placed inside an internal network, so attackers can use it as a foothold to spread to other servers. And because this flaw needs no authentication, they don't even have to steal a valid account to stand at the entrance. In fact, with a later takeover hole of the same kind in Flowise (covered below), reporting indicates that somewhere between 12,000 and 15,000 internet-exposed instances became targets. One self-hosted box falling means the door opens to every system behind it.

CVSS 9.8 is only a gauge of technical severity. For a company or solo developer who built Flowise into their work, the real pain isn't a server briefly going down. It is that your AI spend gets burned through by someone else, your internal documents and customer conversations turn into a stranger's stored data, and your own server gets rebuilt into a tool for attacks. The price of convenience can turn out to be handing over the AI faucet and the data reservoir together.

CVE-2024-58351: how overrideConfig becomes a takeover path

CVE-2024-58351: unauthenticated code execution via the config-override feature (CVSS 9.8)

CVE-2024-58351 is rooted in the design of Flowise's overrideConfig feature. NVD classifies it as CWE-94 (Improper Control of Generation of Code). The CVSS score is 9.8 under version 3.1 and 9.3 under the newer version 4.0, both in the top tier.

overrideConfig is meant as a developer convenience. When you call a Flowise AI flow from the outside, you can inject "run it with this config for now" into the request. The problem is that this injection was almost unrestricted by default. The vendor's own advisory (GHSA-5cph-wvm9-45gj) states that "overrideConfig should have an explicit allow list," pointing to the absence of that allow list as the core problem. The flaw was reported by ryanhalliday.

What can be swapped is not just the prompt text handed to the AI. Some Flowise blocks execute code passed in as config inside a so-called sandbox, an isolated environment. A sandbox is supposed to be a "safe box you can't escape from," but the vm2 library Flowise used has a known weakness that lets you break the box and reach the host server outside it. The attacker sends crafted code into that box via overrideConfig, breaks out (a sandbox escape), and runs arbitrary programs on the server.

From this single design problem, the vendor lists seven possible impacts: remote code execution (RCE), sandbox escape, denial of service that crashes the server, SSRF (making the server reach other servers, used to pivot inside a network), prompt injection (slipping malicious instructions into the AI), data exfiltration, and tampering with the conversation flow. One convenience feature opened all of these attack surfaces at once.

Why "vm2" couldn't stop it

At the center of this hole is a library called vm2. It is a mechanism for running JavaScript code in isolation, and many tools adopted it as a "safe box for running externally supplied code." But vm2 had escape vulnerability after escape vulnerability found in it, until the author himself declared that "fixing the vulnerability seems impossible" and ended development.

In other words, Flowise was using a box that structurally cannot be sealed to execute external input. The vendor's advisory recommends moving to a more robust isolation approach such as isolated-vm. The more an AI tool has a feature that "runs the user's code or expressions on the spot," the more this "choice of box" directly decides the safety of the whole product, a textbook case. The same pattern keeps showing up in cases we have covered, such as the Langflow tar-link RCE and the LiteLLM command injection.

Is your Flowise affected? (version quick reference)

Flowise patches actively, but serious takeover holes have appeared in multiple versions across time. Use the table below to check which hole the version you run is exposed to.

What this table shows is not "I'm safe because I'm on the latest version," but that you need to rethink the operation itself: never expose Flowise to the internet, and always require authentication. Regardless of version, apply the measures described below as well.

Why this isn't just an old bug: the chain of Flowise takeovers

CVE-2024-58351 was patched back in 2024. It is still worth knowing today because the lineage of the hole that overrideConfig opened, "executing external input as-is," has recurred in Flowise ever since.

Published in September 2025, CVE-2025-59528 was extremely severe, with a perfect CVSS of 10.0. A config sent to the "CustomMCP" block, used to connect to an external MCP server, was executed as JavaScript without checks, allowing arbitrary code to run without authentication. It was fixed in 3.0.6.

There is no public report at this time that CVE-2024-58351 itself was exploited at scale. But the root, "running settings and external input as-is," is the same, and the follow-up above shows that attackers keep targeting this product's weak point. Rather than skipping it because the number is old, the right reading is to treat it as the starting gun for inspecting how your own Flowise is deployed.

From discovery to formal registration

← Swipe to move

What to do right now

1. Update Flowise to the latest version. First get to 2.1.4 or later, where the overrideConfig flaw is fixed, and ideally all the way to the latest 3.1 line. If installed globally via npm, run npm update -g flowise; with Docker, pull the latest image and recreate the container. If you fall in the range for CVE-2025-59528 (CustomMCP), 3.0.6 or later is mandatory.

2. Stop exposing it directly to the internet. Flowise is not a tool you should ever expose directly. If it runs in the cloud, restrict access to the admin panel and API by firewall or security group, and if you need it on the go, switch to a VPN, an SSH tunnel, or an authenticated reverse proxy. "Just running it on a public URL for now" is the most dangerous state.

3. Always enable authentication. Flowise can be protected with a username and password. Historically authentication was added later, and many instances run defenseless in their default state, which is exactly why over 10,000 were exposed worldwide. Set the environment variables FLOWISE_USERNAME and FLOWISE_PASSWORD, and enable API-key protection as well.

4. Rotate the keys and passwords you've connected. If there's any chance an affected version was exposed, treat every API key (OpenAI, Anthropic, etc.), database credential, and token registered in Flowise as leaked and reissue them. Check your AI usage bills for unexplained spikes too.

5. Inspect for signs of compromise. On the server running Flowise, check ps aux for unfamiliar processes (such as crypto miners), /tmp and /var/tmp for unknown executables, and for suspicious cron entries or outbound connections. If anything looks off, rebuilding from a clean environment is the surest path.

Actively exploited CVEs and related reading

As of June 2026, CVE-2024-58351 is not listed in the U.S. CISA "Known Exploited Vulnerabilities (KEV)" catalog. On the other hand, Flowise's CVE-2025-59528 has confirmed real-world exploitation and is being watched for KEV inclusion. We keep the latest status of confirmed-exploited CVEs updated in our CISA KEV dashboard (Japanese).

Vulnerabilities in npm-distributed OSS like Flowise can spread into unexpected places through dependency chains. To check whether the packages you use carry known holes, see our OSS supply-chain scanner. AI-tool takeovers keep happening as the flip side of the same "let the AI do anything" convenience, as we've covered with Langflow being attacked 20 hours after disclosure, the flaw in Amazon's AI dev tool Kiro, and the AutoGPT vulnerability.

Summary

CVE-2024-58351 is an unauthenticated takeover hole born because Flowise's convenient overrideConfig feature was usable by anyone by default and executed external input inside a broken box (vm2). The flaw itself was fixed in 2.1.4 back in 2024, but NVD's fresh, top-tier CVSS 9.8 registration has brought it back into focus.

And the same root recurred as the CVSS 10.0 CVE-2025-59528 and was actively exploited in 2026. The ease of "building AI without writing code" is a hair's breadth from a design that "runs external input as-is." Which version is your Flowise on, where can it be reached from, and what keys does it connect to? The more conveniently you use it, the more worthwhile it is to take this moment for a full inventory.

References

• ▸ NVD - CVE-2024-58351
• ▸ FlowiseAI Advisory - GHSA-5cph-wvm9-45gj (overrideConfig)
• ▸ VulnCheck - Flowise RCE via overrideConfig parameter
• ▸ FlowiseAI Advisory - GHSA-3gcm-f6qx-ff7p (CVE-2025-59528)
• ▸ The Hacker News - Flowise under active exploitation
• ▸ BleepingComputer - Max severity Flowise RCE exploited
• ▸ Flowise official repository (GitHub)
• ▸ CISA - Known Exploited Vulnerabilities Catalog