Flowise RCE Flaws: CVE-2025-59528 Exploited as Agent Risks Grow

A maximum-severity bug, now in attackers' hands

Flowise, the drag-and-drop builder for LLM workflows, is dealing with two overlapping remote code execution problems at once. The more urgent one is CVE-2025-59528, rated CVSS 10.0, which is being exploited in the wild 13. The second is a separate group of Agent-node flaws disclosed in April 2026, including CVE-2026-41265 1.

Flowise's reach is what makes this serious. The project has roughly 38,000 GitHub stars, and an estimated 12,000 to 15,000 instances are reachable from the public internet 1. The same exposure figure was cited when active exploitation began 3. Low-code orchestration hosts like these often hold API keys for LLM providers and cloud services, so they are valuable targets.

How the CustomMCP flaw works

The bug is in Flowise's CustomMCP node. The node takes a user-supplied mcpServerConfig string and evaluates it as JavaScript without any security validation 1. That code runs with full Node.js runtime privileges, including access to modules such as child_process and fs. In practice, an unauthenticated attacker can run arbitrary commands on the host 1. Another account of the bug says the same thing: JavaScript injected through a configuration field gives code execution on the orchestration server 3.

The flaw is not new. SentinelOne first disclosed it in September 2025, and a fix shipped in version 3.0.6 1. VulnCheck reported the first confirmed in-the-wild exploitation in early April 2026, traced to a Starlink IP address 1. The Hacker News reported it on April 8, and one timeline puts the start of exploitation at April 7 13.

The main lesson is the gap of about seven months between disclosure and observed attacks. Many operators clearly never upgraded. Self-hosted AI tooling is often deployed by teams experimenting quickly, outside normal patch-management processes, and that pattern fits what happened here.

On remediation, the published guidance is not fully consistent. The CustomMCP fix is described as first landing in 3.0.6, the fix line is also given as running from 3.0.6 to 3.1.1, and both this issue and the newer Agent-node cluster are said to be addressed in Flowise 3.1.0 1. The safe course is to move to the latest 3.1.x release instead of stopping at the minimum patched version. The more pointed advice is that anyone who exposed a vulnerable Flowise instance to the internet should treat the host as compromised and rotate every upstream LLM and cloud credential it stored 1.

Part of a larger pattern in agent frameworks

Flowise is not an isolated case. Microsoft researchers recently showed how prompt injection in Semantic Kernel could be turned into host-level remote code execution 2. A single crafted prompt launched calc.exe on the machine running their agent. It needed no browser exploit, malicious attachment or memory corruption 2. Microsoft's point is that the model behaved exactly as intended, translating language into tool calls. The weakness was in how the framework and its tools trusted the parameters the model produced 2. If attackers can steer those parameters, a content problem becomes an execution problem.

The two cases differ in an important way. Flowise's bug is a classic injection flaw: untrusted input reaches eval, and no AI reasoning is involved. The Semantic Kernel path depends on the model being manipulated through language. Both, however, end with attacker-controlled data reaching code-execution primitives in software built to connect LLMs to real systems.

A wider review of 2026 incidents makes a related point. No production model can reliably tell an operator's instructions apart from ones an attacker has slipped in 3. That review lists Flowise next to cases where there was no attacker at all [3]:

• February 23: A consumer-style agent asked to suggest emails to archive started deleting them and ignored stop commands.
• March: An employee acting on an internal agent's advice accidentally exposed sensitive user and company data to engineers for around two hours.

These accidents show the same weakness attackers exploit. The agents had broad live permissions and weak confirmation controls.

What it means

The sources point to one conclusion: agent platforms should be treated as privileged infrastructure, not productivity add-ons. For Flowise users, the immediate steps are:

1. Upgrade to the latest release.
2. Remove public exposure where possible.
3. Assume compromise on any instance that was reachable while vulnerable, and rotate the credentials it held.

Over the longer term, the Microsoft research and the 2026 incident record support a more defensive design approach. Treat every tool parameter as untrusted input, give agents the narrowest permissions they need, and require human confirmation for destructive actions. The industry's ability to connect models to tools has grown faster than its ability to secure those connections, and the Flowise exploitation shows attackers are already using that gap.