Flowise CVE-2025-59528: CVSS 10.0 RCE Flaw Hits 15K AI Platforms

A single HTTP request. That’s all it takes to achieve full remote code execution on thousands of Flowise AI agent builder instances currently exposed to the internet. CVE-2025-59528, a maximum-severity CVSS 10.0 vulnerability in Flowise’s CustomMCP node, is now under active exploitation — and the gap between disclosure and patching has left an uncomfortably large attack surface wide open.

The Flowise Vulnerability Explained

#

Flowise is an open-source platform that lets teams build LLM-powered workflows and AI agents through a visual drag-and-drop interface. It’s popular with startups and enterprise teams alike for prototyping and deploying everything from customer support bots to data analysis pipelines. That popularity is exactly what makes this flaw so dangerous.

The vulnerability sits in the CustomMCP node, a component that handles Model Context Protocol server configurations. When a user submits configuration data through the mcpServerConfig parameter, Flowise’s convertToValidJSONString function passes that input directly into JavaScript’s Function() constructor. No sanitization. No validation. No sandbox. The input goes straight into executable code.

This is roughly equivalent to handing every API caller an eval() prompt with full Node.js runtime privileges. An attacker who can reach the API endpoint — which only requires a valid API token — gains access to child_process for arbitrary shell commands and fs for filesystem read/write operations. From there, it’s game over: data exfiltration, lateral movement, cryptominer deployment, or persistent backdoors.

The flaw was disclosed by researcher Kim SooHyun in September 2025 and patched in Flowise v3.0.6. Seven months passed before VulnCheck’s Canary network detected the first active exploitation attempts on April 6, 2026.

Why Seven Months of Silence Ended Badly

#

That seven-month window between patch availability and exploitation isn’t unusual, but it’s deeply frustrating. The pattern repeats across open-source security: a patch ships quietly, adoption lags because there’s no forcing function, and attackers eventually get around to weaponizing a public vulnerability.

What’s different here is the target. Flowise instances aren’t just web servers — they’re AI orchestration platforms that often hold API keys for OpenAI, Anthropic, vector databases, and internal company systems. Compromising one Flowise instance can cascade into access to every service it connects to. The blast radius of this Flowise RCE exploit extends far beyond the host machine itself.

According to VulnCheck’s analysis, between 12,000 and 15,000 Flowise instances are publicly accessible on the internet. The initial exploitation wave was traced to a single Starlink IP address, which suggests either a lone operator testing the waters or early-stage scanning before broader campaigns ramp up. Either way, the window for “patch before it gets worse” is closing fast.

Security teams who’ve been tracking AI supply chain threats will recognize the pattern: open-source AI tooling adopted faster than it’s secured.

A Pattern of Exploited Flaws in Flowise

#

CVE-2025-59528 isn’t Flowise’s first trip through the exploitation cycle. It’s the third. Two prior CVEs have already been exploited in the wild:

• CVE-2025-8943 (CVSS 9.8) — A missing authentication flaw that allowed unauthenticated access to sensitive endpoints, leading to OS command injection and RCE.
• CVE-2025-26319 (CVSS 8.9) — An arbitrary file upload vulnerability that could be chained with other flaws for code execution.

Three exploited vulnerabilities in a single open-source project should be a wake-up call. The issue isn’t just individual bugs — it’s an architectural pattern where user input reaches dangerous runtime functions without adequate guardrails. The Function() constructor abuse in CVE-2025-59528 is a textbook example of CWE-94 (Improper Control of Generation of Code), and the fact that similar classes of flaws keep appearing suggests the codebase needs a broader security audit, not just point fixes.

For organizations running Flowise in production, the question isn’t whether the next vulnerability will appear. It’s whether your deployment will survive it when it does.

Who’s at Risk and How Exploitation Works

#

The AI agent builder remote code execution attack path is straightforward enough that a skilled attacker doesn’t need custom tooling. Here’s the practical chain:

1. Discover a publicly exposed Flowise instance (Shodan, Censys, or simple port scanning on common Flowise ports).
2. Obtain a valid API token. In many deployments, default tokens aren’t rotated, or the authentication layer is misconfigured per CVE-2025-8943.
3. Send a crafted HTTP request to the CustomMCP node’s configuration endpoint with malicious JavaScript embedded in the mcpServerConfig parameter.
4. Execute arbitrary code on the host — spawn reverse shells, read environment variables (which often contain API keys for connected services), or write persistent access mechanisms.

The attack doesn’t require local network access, phishing, or social engineering. It’s a straight network-to-RCE chain against internet-facing infrastructure.

Organizations most at risk include:

• AI startups running Flowise on cloud VMs with default configurations
• Enterprise teams that deployed Flowise for internal prototyping but exposed it through misconfigured load balancers or VPNs
• Managed AI service providers offering Flowise-based workflow building to their customers
• Research labs running Flowise instances with connections to sensitive datasets

This echoes concerns raised about AI agent security more broadly — the rush to deploy autonomous AI systems has outpaced the security tooling and practices needed to protect them.

Immediate Response and Mitigation Steps

#

If you’re running Flowise anywhere in your environment, here’s what to do right now — not next sprint, now.

Patch Immediately

#

Update to Flowise v3.1.1 (the latest stable release). The vulnerability was patched in v3.0.6, but v3.1.1 includes additional security hardening. Use npm:

npm update flowise@latest

Verify the installed version afterward:

npx flowise --version

Reduce Attack Surface

#

No AI workflow builder should be directly exposed to the public internet without a compelling reason. Place Flowise behind:

• A reverse proxy with IP allowlisting (Nginx, Caddy, or Cloudflare Access)
• A VPN or zero-trust network (Tailscale, WireGuard, Zscaler)
• Web Application Firewall rules that block suspicious payloads targeting configuration endpoints

Rotate Credentials

#

Assume compromise if your instance was publicly accessible and unpatched. Rotate:

• Flowise API tokens
• All API keys stored in Flowise’s credential manager (OpenAI, Anthropic, Pinecone, database connections, etc.)
• Any cloud provider credentials the Flowise host has access to via IAM roles or environment variables

Audit Logs

#

Check for unusual outbound connections from the Flowise host, unexpected process spawning (especially sh, bash, curl, wget), and filesystem modifications outside normal Flowise directories. If your instance connects to external AI services, verify those downstream systems weren’t accessed with exfiltrated credentials.

Bigger Picture: AI Tooling’s Security Debt

#

The Flowise situation illustrates a tension that’s only getting worse. Organizations want to move fast with AI — build agents, ship workflows, connect LLMs to production data. The tooling that enables this speed is often open-source, community-maintained, and adopted without the same security scrutiny applied to traditional enterprise software.

Caitlin Condon, VP of Security Research at VulnCheck, has pointed out that the gap between vulnerability disclosure and exploitation is compressing across the AI tooling ecosystem. Attackers are paying attention to the same GitHub repositories that developers are. When a security advisory drops for a tool with 15,000 exposed instances and a straightforward exploitation path, it’s not a question of if but when.

This isn’t an argument against open-source AI tools. It’s an argument for treating them with the same operational rigor as any other internet-facing production service. That means patch management, network segmentation, credential rotation policies, and incident response runbooks that account for AI-specific blast radius — like cascading API key compromise across multiple connected services.

The broader AI security community needs to push for secure-by-default configurations in these tools. Flowise shipping with the Function() constructor exposed to user input is a design flaw, not just a code bug. Until AI platform developers internalize that their tools will be exposed to the internet by users who don’t read security advisories, these incidents will keep repeating.

Key Takeaways

#

1. CVE-2025-59528 is a maximum-severity RCE flaw in Flowise that’s trivially exploitable via a single HTTP request to the CustomMCP node — patch to v3.1.1 immediately.
2. 12,000 to 15,000 Flowise instances are publicly exposed, and active exploitation began in early April 2026 from a Starlink IP address.
3. This is Flowise’s third exploited vulnerability, following CVE-2025-8943 and CVE-2025-26319, indicating systemic security issues in the codebase.
4. Compromised Flowise instances cascade — attackers gain access not just to the host but to every API key, database credential, and connected service stored in the platform.
5. AI development tools need production-grade security posture: network segmentation, credential rotation, WAF protection, and aggressive patch cycles — not “we’ll get to it” timelines.
6. Assume compromise for any unpatched, internet-facing Flowise instance and rotate all connected credentials immediately.

Frequently Asked Questions

#

What is CVE-2025-59528 and why is it rated CVSS 10.0?

#

CVE-2025-59528 is a code injection vulnerability in Flowise’s CustomMCP node that allows unauthenticated remote code execution. It received a maximum CVSS 10.0 score because exploitation requires only a single HTTP request, grants full system access, and affects a large number of publicly exposed instances.

How many Flowise instances are affected by this vulnerability?

#

Between 12,000 and 15,000 Flowise instances are publicly accessible on the internet. Any instance running version 3.0.5 or earlier is vulnerable to CVE-2025-59528, and active exploitation was detected in early April 2026.

How do I patch Flowise against CVE-2025-59528?

#

Update Flowise to version 3.1.1 or later immediately. The vulnerability was first patched in v3.0.6, but the latest stable release (v3.1.1) includes additional fixes. Organizations should also restrict public internet exposure of their Flowise instances.

Can CVE-2025-59528 be exploited without authentication?

#

The exploit requires a valid Flowise API token, but the barrier is low. Many deployments use default or weak tokens, and the related CVE-2025-8943 (a missing authentication flaw) may allow attackers to bypass token requirements entirely on unpatched instances.

Sources & References

#

• The Hacker News — Flowise AI Agent Builder Under Active Attack — Primary reporting on CVE-2025-59528 exploitation timeline, researcher attribution, and VulnCheck detection details
• BleepingComputer — Max Severity Flowise RCE Vulnerability Now Exploited in Attacks — Technical details on the attack vector, Starlink IP origin, and patching guidance
• Security Affairs — Attackers Exploit Critical Flowise Flaw for Remote Code Execution — Technical breakdown of the convertToValidJSONString function and Function() constructor abuse
• CSO Online — Hackers Exploit a Critical Flowise Flaw Affecting Thousands of AI Workflows — Context on related CVEs and Caitlin Condon’s analysis
• GBHackers — Attackers Exploit Flowise Injection Vulnerability — Details on the 15,000+ exposed instance count and single-request exploitation chain