12,000 AI Agent Builders at Risk: Flowise CVSS 10 RCE

Hackers actively exploiting CVSS 10 RCE in Flowise AI agent builders since April 6. 12,000+ instances exposed. What every CIO running low-code AI must do now.

By Rajesh Beri·April 26, 2026·10 min read
Share:

THE DAILY BRIEF

AI SecurityAgentic AIVulnerabilityEnterprise RiskLow-Code AICISO

12,000 AI Agent Builders at Risk: Flowise CVSS 10 RCE

Hackers actively exploiting CVSS 10 RCE in Flowise AI agent builders since April 6. 12,000+ instances exposed. What every CIO running low-code AI must do now.

By Rajesh Beri·April 26, 2026·10 min read

There is a quiet pattern emerging in enterprise AI security incidents in 2026, and the latest one — Flowise CVE-2025-59528 — captures it precisely. The agent builder you let your business teams self-serve, the low-code orchestrator running quietly behind a Slack channel, the "experiment" that became a production dependency last quarter — that is now a remote-code-execution surface that an attacker with a single API token can fully compromise.

Active exploitation of CVE-2025-59528 — a CVSS 10.0 code-injection flaw in Flowise's CustomMCP node — began on April 6, 2026, and was confirmed in the wild by VulnCheck on April 7. By the time the OWASP GenAI Q1 2026 Exploit Round-up Report formally documented it on April 14, between 12,000 and 15,000 internet-facing Flowise instances were exposed, with patches available but adoption incomplete.

This is the third Flowise vulnerability with documented wild exploitation in the past nine months. It will not be the last, and it will not be limited to Flowise.

For CIOs, CTOs, and CISOs, the lesson is no longer "patch this CVE." It is the low-code AI agent layer is now part of your enterprise attack surface, and you need an inventory, a patching SLA, and an authorization model for it the same way you have for every other software stack you run in production.

What Actually Happened

Flowise is an open-source low-code platform used by enterprises and developers to assemble LLM and agentic AI workflows visually — a drag-and-drop tool for stitching together prompts, RAG pipelines, tools, memory, and Model Context Protocol (MCP) servers. It is popular precisely because it lowers the barrier to building agents.

The vulnerability sits in Flowise's CustomMCP node, which connects agents to external MCP servers. The node accepts a user-supplied mcpServerConfig string and uses it to construct the MCP server configuration at runtime. According to Flowise's own advisory:

"This node parses the user-provided mcpServerConfig string to build the MCP server configuration. However, during this process, it executes JavaScript code without any security validation."

Mechanically, the flaw lives in convertToValidJSONString, which passes user input directly to JavaScript's Function() constructor. That constructor evaluates and executes whatever string it receives — with full Node.js runtime privileges. From there an attacker reaches child_process and fs, which means arbitrary command execution and file-system manipulation on the host.

Detail Value
CVE CVE-2025-59528
CVSS 10.0 (maximum)
Component CustomMCP node, convertToValidJSONString
Patched in Flowise v3.0.6 (current: v3.1.1)
Exploitation began April 6, 2026
Confirmed in-wild April 7, 2026 (VulnCheck)
Exposed instances 12,000–15,000
Auth required API token only
Discoverer Kim SooHyun

The attack barrier is low: an attacker needs only a valid API token — not admin privileges, not internal access. Initial exploitation was traced to a single Starlink IP, suggesting opportunistic mass scanning followed by selective compromise.

Why This Is Bigger Than One CVE

Three contextual data points reframe this from "another patch Tuesday" into a structural enterprise risk.

One, this is the third Flowise RCE under active exploitation in nine months. CVE-2025-8943 (missing authentication, CVSS 9.8) and CVE-2025-26319 (arbitrary file upload, CVSS 8.9) preceded it. Three high-severity wild-exploit events on a single platform in under a year is a pattern, not an outlier.

Two, Gravitee's State of AI Agent Security 2026 report, released this month, found that 88% of organizations confirmed or suspected AI agent security incidents in the past year, while only 21.9% treat AI agents as identity-bearing entities with their own access controls. The defensive posture has not caught up with the attack surface.

Three, the OWASP GenAI Q1 2026 report identifies the architectural source of the problem: the dominant attack vectors in agentic AI are not novel zero-days. They are excessive agent autonomy, prompt injection, supply-chain vulnerabilities in AI tooling, identity and privilege abuse through service accounts, and sensitive-data disclosure from misconfiguration. The Flowise CVE maps cleanly to OWASP's ASI05 (Unexpected Code Execution), ASI02 (Tool Misuse), and ASI04 (Agentic Supply Chain).

The Q1 report's harder observation: most AI security incidents in production today never receive a CVE because they stem from design flaws and misconfiguration rather than discrete code vulnerabilities. Flowise CVE-2025-59528 is, by that measure, the visible 5% of the iceberg.

The Technical Read for CISOs and Platform Engineering

Strip away the headline and three engineering realities matter most.

First, AI agent platforms are full Node.js / Python runtimes that you have shipped to production with developer-grade trust assumptions. Flowise is not a "tool" — it is a JavaScript execution engine that happens to render a graph UI. Any node that accepts user-supplied configuration is a candidate for the same class of bug. CustomMCP is one node; there are dozens of others across LangChain, n8n, Activepieces, Dify, and similar platforms. The hardening playbook for these is closer to how you run a Jenkins or GitHub Actions runner than how you run a SaaS dashboard.

Second, MCP itself widens the blast radius. Model Context Protocol gives agents a standard way to connect to external tools, data sources, and services. That is also why CustomMCP's parser is a high-value target — a successful exploit doesn't just compromise one agent. It compromises everything that agent can reach through MCP: databases, file shares, third-party APIs, internal services. Any organization running Flowise behind their corporate network with MCP endpoints to internal systems should treat a single compromised instance as a probable lateral-movement event, not a contained one.

Third, "API token only" is doing a lot of work in the threat model. In practice, Flowise API tokens leak the way any developer credential leaks: hardcoded in repos, pasted in Slack, embedded in CI logs, stored in unencrypted .env files, exfiltrated by an info-stealer on a developer laptop. The exploit pre-conditions are realistic, not theoretical.

The architectural pattern emerging across these incidents:

User-supplied config → validated as data → executed as code
              ↓
       Node.js runtime privileges
              ↓
   child_process / fs / network access
              ↓
   MCP-connected internal systems

If your AI agent platform meets two of those four conditions (config-as-code, runtime privileges, broad outbound network, MCP/tool access), you have a Flowise-class risk regardless of which platform you actually run.

The Business Read for CIOs and CFOs

Three financial implications deserve immediate attention.

One, your low-code AI footprint is almost certainly larger than your inventory says. Flowise, n8n, Dify, LangFlow, Activepieces, Make, and similar platforms have been quietly self-served by business and engineering teams across most enterprises since 2024. The CVSS 10 here matters less than the question: do you know how many instances of low-code AI orchestration are running across your environment, who owns them, and which ones have outbound access to internal systems? If you do not have an answer, the CFO ROI math on your AI program is incomplete — you have unmeasured contingent liability.

Two, the cost of a low-code AI breach is the cost of an internal-systems breach, not a SaaS breach. Because these platforms typically run with credentials to your databases, document repositories, ticketing systems, and email, a successful compromise looks like an insider-threat incident in IR forensics. The 2026 IBM Cost of a Data Breach numbers for that profile sit well above $4.8M average. Procurement teams approving Flowise/n8n usage on a cost-of-license basis are mispricing the operational risk by an order of magnitude.

Three, vendor due diligence on AI platforms now needs the same rigor as core infrastructure. Three RCEs in nine months on a single platform is a vendor-stability signal. The CFO question is no longer "is the license cheap" — it is "what is this vendor's security track record, patching SLA, and architectural separation between user input and code execution paths?" That question applies equally to commercial vendors (Salesforce Agentforce, Microsoft Copilot Studio, Google Gemini Enterprise) and open-source low-code platforms.

Competitive Landscape: The Whole Category Is Exposed

Flowise is not unique in this risk class. Every low-code AI orchestrator that lets users supply configuration which is then evaluated by a runtime is a candidate for the same architectural flaw.

LangChain / LangGraph ship as developer libraries; the risk surface is in the apps built on top, not the framework itself. Mitigating responsibility shifts to the application owner.

n8n / Activepieces / Make offer broader integration libraries and are widely used for AI workflows. They have their own history of code-execution and SSRF issues; treat them with the same hardening discipline.

Dify / LangFlow / FlowGPT are direct Flowise alternatives with similar architectural patterns. CustomMCP-class flaws are plausible across all of them.

Commercial enterprise platforms (Salesforce Agentforce, ServiceNow AI Agents, Microsoft Copilot Studio, Google Gemini Enterprise Agent Platform, Adobe CX Enterprise, IBM watsonx Orchestrate) ship with stronger sandboxing and managed runtime, but they are not immune. EchoLeak (Microsoft 365 Copilot) and CVE-2025-53773 (GitHub Copilot, CVSS 9.6) demonstrate the same class of issue is reachable in commercial offerings, just through different paths.

The competitive reality: there is no AI agent platform that is "safe by default" in 2026. The differentiator is the security posture you operate it under.

Decision Framework: What CIOs and CISOs Should Do This Quarter

Four moves are worth making in the next 30 days.

1. Inventory every low-code AI platform running in your environment. Run an EDR / network-flow audit for Flowise, n8n, Dify, LangFlow, Activepieces, and Make instances. Include developer laptops, internal-network VMs, container clusters, and SaaS-hosted deployments. The first finding is almost always: there are more instances than security knew about.

2. Patch Flowise to v3.1.1, then assume your auth tokens are compromised. Rotate all Flowise API tokens, audit which MCP servers and tools each instance is connected to, and review outbound connection logs for anomalies since April 6. If an instance running v3.0.5 or earlier was internet-facing, treat it as a probable compromise pending forensic confirmation, not a possible one.

3. Establish a low-code AI authorization model. Adopt the principle from Gravitee's report: agents are identity-bearing entities. Each agent platform instance gets its own service identity, scoped credentials, network egress allowlists, and an explicit owner. No more shared admin credentials connecting to production databases.

4. Update your AI procurement checklist. Three additions: (a) require evidence of secure-coding review for any node that accepts user configuration, (b) require a documented patching SLA and security advisory channel, (c) require sandboxed execution as a configurable default. Apply this to both open-source platforms and commercial vendors.

The deeper shift the OWASP Q1 report is naming: enterprise AI security is no longer a model-layer problem. Frontier-model alignment, jailbreak resistance, and prompt safety dominated 2024–2025 discussion. The 2026 incident data says the actual breaches are happening in the boring layers — auth, config parsing, supply chain, MCP scope, identity. Those are the layers your existing security program already knows how to handle. The work is to remember that your AI platforms count as software, and to put them on the same security cadence as everything else you run in production.

Want to calculate your own AI ROI? Try our AI ROI Calculator — takes 60 seconds and shows projected savings, payback period, and 3-year ROI.

Continue Reading

Sources

THE DAILY BRIEF

Enterprise AI insights for technology and business leaders, twice weekly.

thedailybrief.com

Subscribe at thedailybrief.com/subscribe for weekly AI insights delivered to your inbox.

LinkedIn: linkedin.com/in/rberi  |  X: x.com/rajeshberi

© 2026 Rajesh Beri. All rights reserved.

12,000 AI Agent Builders at Risk: Flowise CVSS 10 RCE

Photo by Tima Miroshnichenko on Pexels

There is a quiet pattern emerging in enterprise AI security incidents in 2026, and the latest one — Flowise CVE-2025-59528 — captures it precisely. The agent builder you let your business teams self-serve, the low-code orchestrator running quietly behind a Slack channel, the "experiment" that became a production dependency last quarter — that is now a remote-code-execution surface that an attacker with a single API token can fully compromise.

Active exploitation of CVE-2025-59528 — a CVSS 10.0 code-injection flaw in Flowise's CustomMCP node — began on April 6, 2026, and was confirmed in the wild by VulnCheck on April 7. By the time the OWASP GenAI Q1 2026 Exploit Round-up Report formally documented it on April 14, between 12,000 and 15,000 internet-facing Flowise instances were exposed, with patches available but adoption incomplete.

This is the third Flowise vulnerability with documented wild exploitation in the past nine months. It will not be the last, and it will not be limited to Flowise.

For CIOs, CTOs, and CISOs, the lesson is no longer "patch this CVE." It is the low-code AI agent layer is now part of your enterprise attack surface, and you need an inventory, a patching SLA, and an authorization model for it the same way you have for every other software stack you run in production.

What Actually Happened

Flowise is an open-source low-code platform used by enterprises and developers to assemble LLM and agentic AI workflows visually — a drag-and-drop tool for stitching together prompts, RAG pipelines, tools, memory, and Model Context Protocol (MCP) servers. It is popular precisely because it lowers the barrier to building agents.

The vulnerability sits in Flowise's CustomMCP node, which connects agents to external MCP servers. The node accepts a user-supplied mcpServerConfig string and uses it to construct the MCP server configuration at runtime. According to Flowise's own advisory:

"This node parses the user-provided mcpServerConfig string to build the MCP server configuration. However, during this process, it executes JavaScript code without any security validation."

Mechanically, the flaw lives in convertToValidJSONString, which passes user input directly to JavaScript's Function() constructor. That constructor evaluates and executes whatever string it receives — with full Node.js runtime privileges. From there an attacker reaches child_process and fs, which means arbitrary command execution and file-system manipulation on the host.

Detail Value
CVE CVE-2025-59528
CVSS 10.0 (maximum)
Component CustomMCP node, convertToValidJSONString
Patched in Flowise v3.0.6 (current: v3.1.1)
Exploitation began April 6, 2026
Confirmed in-wild April 7, 2026 (VulnCheck)
Exposed instances 12,000–15,000
Auth required API token only
Discoverer Kim SooHyun

The attack barrier is low: an attacker needs only a valid API token — not admin privileges, not internal access. Initial exploitation was traced to a single Starlink IP, suggesting opportunistic mass scanning followed by selective compromise.

Why This Is Bigger Than One CVE

Three contextual data points reframe this from "another patch Tuesday" into a structural enterprise risk.

One, this is the third Flowise RCE under active exploitation in nine months. CVE-2025-8943 (missing authentication, CVSS 9.8) and CVE-2025-26319 (arbitrary file upload, CVSS 8.9) preceded it. Three high-severity wild-exploit events on a single platform in under a year is a pattern, not an outlier.

Two, Gravitee's State of AI Agent Security 2026 report, released this month, found that 88% of organizations confirmed or suspected AI agent security incidents in the past year, while only 21.9% treat AI agents as identity-bearing entities with their own access controls. The defensive posture has not caught up with the attack surface.

Three, the OWASP GenAI Q1 2026 report identifies the architectural source of the problem: the dominant attack vectors in agentic AI are not novel zero-days. They are excessive agent autonomy, prompt injection, supply-chain vulnerabilities in AI tooling, identity and privilege abuse through service accounts, and sensitive-data disclosure from misconfiguration. The Flowise CVE maps cleanly to OWASP's ASI05 (Unexpected Code Execution), ASI02 (Tool Misuse), and ASI04 (Agentic Supply Chain).

The Q1 report's harder observation: most AI security incidents in production today never receive a CVE because they stem from design flaws and misconfiguration rather than discrete code vulnerabilities. Flowise CVE-2025-59528 is, by that measure, the visible 5% of the iceberg.

The Technical Read for CISOs and Platform Engineering

Strip away the headline and three engineering realities matter most.

First, AI agent platforms are full Node.js / Python runtimes that you have shipped to production with developer-grade trust assumptions. Flowise is not a "tool" — it is a JavaScript execution engine that happens to render a graph UI. Any node that accepts user-supplied configuration is a candidate for the same class of bug. CustomMCP is one node; there are dozens of others across LangChain, n8n, Activepieces, Dify, and similar platforms. The hardening playbook for these is closer to how you run a Jenkins or GitHub Actions runner than how you run a SaaS dashboard.

Second, MCP itself widens the blast radius. Model Context Protocol gives agents a standard way to connect to external tools, data sources, and services. That is also why CustomMCP's parser is a high-value target — a successful exploit doesn't just compromise one agent. It compromises everything that agent can reach through MCP: databases, file shares, third-party APIs, internal services. Any organization running Flowise behind their corporate network with MCP endpoints to internal systems should treat a single compromised instance as a probable lateral-movement event, not a contained one.

Third, "API token only" is doing a lot of work in the threat model. In practice, Flowise API tokens leak the way any developer credential leaks: hardcoded in repos, pasted in Slack, embedded in CI logs, stored in unencrypted .env files, exfiltrated by an info-stealer on a developer laptop. The exploit pre-conditions are realistic, not theoretical.

The architectural pattern emerging across these incidents:

User-supplied config → validated as data → executed as code
              ↓
       Node.js runtime privileges
              ↓
   child_process / fs / network access
              ↓
   MCP-connected internal systems

If your AI agent platform meets two of those four conditions (config-as-code, runtime privileges, broad outbound network, MCP/tool access), you have a Flowise-class risk regardless of which platform you actually run.

The Business Read for CIOs and CFOs

Three financial implications deserve immediate attention.

One, your low-code AI footprint is almost certainly larger than your inventory says. Flowise, n8n, Dify, LangFlow, Activepieces, Make, and similar platforms have been quietly self-served by business and engineering teams across most enterprises since 2024. The CVSS 10 here matters less than the question: do you know how many instances of low-code AI orchestration are running across your environment, who owns them, and which ones have outbound access to internal systems? If you do not have an answer, the CFO ROI math on your AI program is incomplete — you have unmeasured contingent liability.

Two, the cost of a low-code AI breach is the cost of an internal-systems breach, not a SaaS breach. Because these platforms typically run with credentials to your databases, document repositories, ticketing systems, and email, a successful compromise looks like an insider-threat incident in IR forensics. The 2026 IBM Cost of a Data Breach numbers for that profile sit well above $4.8M average. Procurement teams approving Flowise/n8n usage on a cost-of-license basis are mispricing the operational risk by an order of magnitude.

Three, vendor due diligence on AI platforms now needs the same rigor as core infrastructure. Three RCEs in nine months on a single platform is a vendor-stability signal. The CFO question is no longer "is the license cheap" — it is "what is this vendor's security track record, patching SLA, and architectural separation between user input and code execution paths?" That question applies equally to commercial vendors (Salesforce Agentforce, Microsoft Copilot Studio, Google Gemini Enterprise) and open-source low-code platforms.

Competitive Landscape: The Whole Category Is Exposed

Flowise is not unique in this risk class. Every low-code AI orchestrator that lets users supply configuration which is then evaluated by a runtime is a candidate for the same architectural flaw.

LangChain / LangGraph ship as developer libraries; the risk surface is in the apps built on top, not the framework itself. Mitigating responsibility shifts to the application owner.

n8n / Activepieces / Make offer broader integration libraries and are widely used for AI workflows. They have their own history of code-execution and SSRF issues; treat them with the same hardening discipline.

Dify / LangFlow / FlowGPT are direct Flowise alternatives with similar architectural patterns. CustomMCP-class flaws are plausible across all of them.

Commercial enterprise platforms (Salesforce Agentforce, ServiceNow AI Agents, Microsoft Copilot Studio, Google Gemini Enterprise Agent Platform, Adobe CX Enterprise, IBM watsonx Orchestrate) ship with stronger sandboxing and managed runtime, but they are not immune. EchoLeak (Microsoft 365 Copilot) and CVE-2025-53773 (GitHub Copilot, CVSS 9.6) demonstrate the same class of issue is reachable in commercial offerings, just through different paths.

The competitive reality: there is no AI agent platform that is "safe by default" in 2026. The differentiator is the security posture you operate it under.

Decision Framework: What CIOs and CISOs Should Do This Quarter

Four moves are worth making in the next 30 days.

1. Inventory every low-code AI platform running in your environment. Run an EDR / network-flow audit for Flowise, n8n, Dify, LangFlow, Activepieces, and Make instances. Include developer laptops, internal-network VMs, container clusters, and SaaS-hosted deployments. The first finding is almost always: there are more instances than security knew about.

2. Patch Flowise to v3.1.1, then assume your auth tokens are compromised. Rotate all Flowise API tokens, audit which MCP servers and tools each instance is connected to, and review outbound connection logs for anomalies since April 6. If an instance running v3.0.5 or earlier was internet-facing, treat it as a probable compromise pending forensic confirmation, not a possible one.

3. Establish a low-code AI authorization model. Adopt the principle from Gravitee's report: agents are identity-bearing entities. Each agent platform instance gets its own service identity, scoped credentials, network egress allowlists, and an explicit owner. No more shared admin credentials connecting to production databases.

4. Update your AI procurement checklist. Three additions: (a) require evidence of secure-coding review for any node that accepts user configuration, (b) require a documented patching SLA and security advisory channel, (c) require sandboxed execution as a configurable default. Apply this to both open-source platforms and commercial vendors.

The deeper shift the OWASP Q1 report is naming: enterprise AI security is no longer a model-layer problem. Frontier-model alignment, jailbreak resistance, and prompt safety dominated 2024–2025 discussion. The 2026 incident data says the actual breaches are happening in the boring layers — auth, config parsing, supply chain, MCP scope, identity. Those are the layers your existing security program already knows how to handle. The work is to remember that your AI platforms count as software, and to put them on the same security cadence as everything else you run in production.

Want to calculate your own AI ROI? Try our AI ROI Calculator — takes 60 seconds and shows projected savings, payback period, and 3-year ROI.

Continue Reading

Sources

Share:

THE DAILY BRIEF

AI SecurityAgentic AIVulnerabilityEnterprise RiskLow-Code AICISO

12,000 AI Agent Builders at Risk: Flowise CVSS 10 RCE

Hackers actively exploiting CVSS 10 RCE in Flowise AI agent builders since April 6. 12,000+ instances exposed. What every CIO running low-code AI must do now.

By Rajesh Beri·April 26, 2026·10 min read

There is a quiet pattern emerging in enterprise AI security incidents in 2026, and the latest one — Flowise CVE-2025-59528 — captures it precisely. The agent builder you let your business teams self-serve, the low-code orchestrator running quietly behind a Slack channel, the "experiment" that became a production dependency last quarter — that is now a remote-code-execution surface that an attacker with a single API token can fully compromise.

Active exploitation of CVE-2025-59528 — a CVSS 10.0 code-injection flaw in Flowise's CustomMCP node — began on April 6, 2026, and was confirmed in the wild by VulnCheck on April 7. By the time the OWASP GenAI Q1 2026 Exploit Round-up Report formally documented it on April 14, between 12,000 and 15,000 internet-facing Flowise instances were exposed, with patches available but adoption incomplete.

This is the third Flowise vulnerability with documented wild exploitation in the past nine months. It will not be the last, and it will not be limited to Flowise.

For CIOs, CTOs, and CISOs, the lesson is no longer "patch this CVE." It is the low-code AI agent layer is now part of your enterprise attack surface, and you need an inventory, a patching SLA, and an authorization model for it the same way you have for every other software stack you run in production.

What Actually Happened

Flowise is an open-source low-code platform used by enterprises and developers to assemble LLM and agentic AI workflows visually — a drag-and-drop tool for stitching together prompts, RAG pipelines, tools, memory, and Model Context Protocol (MCP) servers. It is popular precisely because it lowers the barrier to building agents.

The vulnerability sits in Flowise's CustomMCP node, which connects agents to external MCP servers. The node accepts a user-supplied mcpServerConfig string and uses it to construct the MCP server configuration at runtime. According to Flowise's own advisory:

"This node parses the user-provided mcpServerConfig string to build the MCP server configuration. However, during this process, it executes JavaScript code without any security validation."

Mechanically, the flaw lives in convertToValidJSONString, which passes user input directly to JavaScript's Function() constructor. That constructor evaluates and executes whatever string it receives — with full Node.js runtime privileges. From there an attacker reaches child_process and fs, which means arbitrary command execution and file-system manipulation on the host.

Detail Value
CVE CVE-2025-59528
CVSS 10.0 (maximum)
Component CustomMCP node, convertToValidJSONString
Patched in Flowise v3.0.6 (current: v3.1.1)
Exploitation began April 6, 2026
Confirmed in-wild April 7, 2026 (VulnCheck)
Exposed instances 12,000–15,000
Auth required API token only
Discoverer Kim SooHyun

The attack barrier is low: an attacker needs only a valid API token — not admin privileges, not internal access. Initial exploitation was traced to a single Starlink IP, suggesting opportunistic mass scanning followed by selective compromise.

Why This Is Bigger Than One CVE

Three contextual data points reframe this from "another patch Tuesday" into a structural enterprise risk.

One, this is the third Flowise RCE under active exploitation in nine months. CVE-2025-8943 (missing authentication, CVSS 9.8) and CVE-2025-26319 (arbitrary file upload, CVSS 8.9) preceded it. Three high-severity wild-exploit events on a single platform in under a year is a pattern, not an outlier.

Two, Gravitee's State of AI Agent Security 2026 report, released this month, found that 88% of organizations confirmed or suspected AI agent security incidents in the past year, while only 21.9% treat AI agents as identity-bearing entities with their own access controls. The defensive posture has not caught up with the attack surface.

Three, the OWASP GenAI Q1 2026 report identifies the architectural source of the problem: the dominant attack vectors in agentic AI are not novel zero-days. They are excessive agent autonomy, prompt injection, supply-chain vulnerabilities in AI tooling, identity and privilege abuse through service accounts, and sensitive-data disclosure from misconfiguration. The Flowise CVE maps cleanly to OWASP's ASI05 (Unexpected Code Execution), ASI02 (Tool Misuse), and ASI04 (Agentic Supply Chain).

The Q1 report's harder observation: most AI security incidents in production today never receive a CVE because they stem from design flaws and misconfiguration rather than discrete code vulnerabilities. Flowise CVE-2025-59528 is, by that measure, the visible 5% of the iceberg.

The Technical Read for CISOs and Platform Engineering

Strip away the headline and three engineering realities matter most.

First, AI agent platforms are full Node.js / Python runtimes that you have shipped to production with developer-grade trust assumptions. Flowise is not a "tool" — it is a JavaScript execution engine that happens to render a graph UI. Any node that accepts user-supplied configuration is a candidate for the same class of bug. CustomMCP is one node; there are dozens of others across LangChain, n8n, Activepieces, Dify, and similar platforms. The hardening playbook for these is closer to how you run a Jenkins or GitHub Actions runner than how you run a SaaS dashboard.

Second, MCP itself widens the blast radius. Model Context Protocol gives agents a standard way to connect to external tools, data sources, and services. That is also why CustomMCP's parser is a high-value target — a successful exploit doesn't just compromise one agent. It compromises everything that agent can reach through MCP: databases, file shares, third-party APIs, internal services. Any organization running Flowise behind their corporate network with MCP endpoints to internal systems should treat a single compromised instance as a probable lateral-movement event, not a contained one.

Third, "API token only" is doing a lot of work in the threat model. In practice, Flowise API tokens leak the way any developer credential leaks: hardcoded in repos, pasted in Slack, embedded in CI logs, stored in unencrypted .env files, exfiltrated by an info-stealer on a developer laptop. The exploit pre-conditions are realistic, not theoretical.

The architectural pattern emerging across these incidents:

User-supplied config → validated as data → executed as code
              ↓
       Node.js runtime privileges
              ↓
   child_process / fs / network access
              ↓
   MCP-connected internal systems

If your AI agent platform meets two of those four conditions (config-as-code, runtime privileges, broad outbound network, MCP/tool access), you have a Flowise-class risk regardless of which platform you actually run.

The Business Read for CIOs and CFOs

Three financial implications deserve immediate attention.

One, your low-code AI footprint is almost certainly larger than your inventory says. Flowise, n8n, Dify, LangFlow, Activepieces, Make, and similar platforms have been quietly self-served by business and engineering teams across most enterprises since 2024. The CVSS 10 here matters less than the question: do you know how many instances of low-code AI orchestration are running across your environment, who owns them, and which ones have outbound access to internal systems? If you do not have an answer, the CFO ROI math on your AI program is incomplete — you have unmeasured contingent liability.

Two, the cost of a low-code AI breach is the cost of an internal-systems breach, not a SaaS breach. Because these platforms typically run with credentials to your databases, document repositories, ticketing systems, and email, a successful compromise looks like an insider-threat incident in IR forensics. The 2026 IBM Cost of a Data Breach numbers for that profile sit well above $4.8M average. Procurement teams approving Flowise/n8n usage on a cost-of-license basis are mispricing the operational risk by an order of magnitude.

Three, vendor due diligence on AI platforms now needs the same rigor as core infrastructure. Three RCEs in nine months on a single platform is a vendor-stability signal. The CFO question is no longer "is the license cheap" — it is "what is this vendor's security track record, patching SLA, and architectural separation between user input and code execution paths?" That question applies equally to commercial vendors (Salesforce Agentforce, Microsoft Copilot Studio, Google Gemini Enterprise) and open-source low-code platforms.

Competitive Landscape: The Whole Category Is Exposed

Flowise is not unique in this risk class. Every low-code AI orchestrator that lets users supply configuration which is then evaluated by a runtime is a candidate for the same architectural flaw.

LangChain / LangGraph ship as developer libraries; the risk surface is in the apps built on top, not the framework itself. Mitigating responsibility shifts to the application owner.

n8n / Activepieces / Make offer broader integration libraries and are widely used for AI workflows. They have their own history of code-execution and SSRF issues; treat them with the same hardening discipline.

Dify / LangFlow / FlowGPT are direct Flowise alternatives with similar architectural patterns. CustomMCP-class flaws are plausible across all of them.

Commercial enterprise platforms (Salesforce Agentforce, ServiceNow AI Agents, Microsoft Copilot Studio, Google Gemini Enterprise Agent Platform, Adobe CX Enterprise, IBM watsonx Orchestrate) ship with stronger sandboxing and managed runtime, but they are not immune. EchoLeak (Microsoft 365 Copilot) and CVE-2025-53773 (GitHub Copilot, CVSS 9.6) demonstrate the same class of issue is reachable in commercial offerings, just through different paths.

The competitive reality: there is no AI agent platform that is "safe by default" in 2026. The differentiator is the security posture you operate it under.

Decision Framework: What CIOs and CISOs Should Do This Quarter

Four moves are worth making in the next 30 days.

1. Inventory every low-code AI platform running in your environment. Run an EDR / network-flow audit for Flowise, n8n, Dify, LangFlow, Activepieces, and Make instances. Include developer laptops, internal-network VMs, container clusters, and SaaS-hosted deployments. The first finding is almost always: there are more instances than security knew about.

2. Patch Flowise to v3.1.1, then assume your auth tokens are compromised. Rotate all Flowise API tokens, audit which MCP servers and tools each instance is connected to, and review outbound connection logs for anomalies since April 6. If an instance running v3.0.5 or earlier was internet-facing, treat it as a probable compromise pending forensic confirmation, not a possible one.

3. Establish a low-code AI authorization model. Adopt the principle from Gravitee's report: agents are identity-bearing entities. Each agent platform instance gets its own service identity, scoped credentials, network egress allowlists, and an explicit owner. No more shared admin credentials connecting to production databases.

4. Update your AI procurement checklist. Three additions: (a) require evidence of secure-coding review for any node that accepts user configuration, (b) require a documented patching SLA and security advisory channel, (c) require sandboxed execution as a configurable default. Apply this to both open-source platforms and commercial vendors.

The deeper shift the OWASP Q1 report is naming: enterprise AI security is no longer a model-layer problem. Frontier-model alignment, jailbreak resistance, and prompt safety dominated 2024–2025 discussion. The 2026 incident data says the actual breaches are happening in the boring layers — auth, config parsing, supply chain, MCP scope, identity. Those are the layers your existing security program already knows how to handle. The work is to remember that your AI platforms count as software, and to put them on the same security cadence as everything else you run in production.

Want to calculate your own AI ROI? Try our AI ROI Calculator — takes 60 seconds and shows projected savings, payback period, and 3-year ROI.

Continue Reading

Sources

THE DAILY BRIEF

Enterprise AI insights for technology and business leaders, twice weekly.

thedailybrief.com

Subscribe at thedailybrief.com/subscribe for weekly AI insights delivered to your inbox.

LinkedIn: linkedin.com/in/rberi  |  X: x.com/rajeshberi

© 2026 Rajesh Beri. All rights reserved.

Newsletter

Stay Ahead of the Curve

Weekly enterprise AI insights for technology leaders. No spam, no vendor pitches—unsubscribe anytime.

Subscribe