Flowise MCP RCE is not just another patch note. It is a warning about how agent builders handle Model Context Protocol servers, especially STDIO-based tools.
The full TokenMix.ai version is here: Flowise MCP RCE: 10 Fixes for CVE-2026-40933 and Upsonic.
Short version:
- Patch Flowise to 3.1.0 or later.
- Patch Upsonic to 0.72.0 or later.
- Do not treat MCP STDIO as harmless configuration.
- Do not rely on input sanitization as the main control.
- Treat any user-configurable STDIO MCP server like a process execution surface.
That last point is the real lesson.
What Happened
Flowise CVE-2026-40933 affects Flowise and flowise-components versions up to 3.0.13, according to the GitHub Advisory Database. The patched version is 3.1.0.
Upsonic CVE-2026-30625 affects versions before 0.72.0, according to Snyk. The fixed version is 0.72.0.
OX Security's analysis connects both issues to a broader MCP supply-chain pattern: products allowed users to configure MCP STDIO servers, and that configuration could reach OS-level process execution paths.
This is the part that matters for developers building agent systems:
MCP STDIO is not just a connector. It can be a process launcher.
If a user can control the command, arguments, package, or runtime behavior of a STDIO MCP server, then the application is not only managing plugins. It is giving users a path toward execution.
Affected Versions
| Product | CVE | Affected versions | Fixed version |
|---|---|---|---|
| Flowise | CVE-2026-40933 | Up to 3.0.13 | 3.1.0 or later |
| flowise-components | CVE-2026-40933 | Up to 3.0.13 | 3.1.0 or later |
| Upsonic | CVE-2026-30625 | Before 0.72.0 | 0.72.0 or later |
| LiteLLM | CVE-2026-30623 | 1.74.2 to before 1.83.7 | 1.83.7 or later |
Version data above reflects public advisories available on April 29, 2026. Check vendor advisories before making a production exception.
Why Sanitization Was Not Enough
Many teams hear "RCE" and assume the failure was a missing regex. That is usually too shallow.
The OX write-up says the projects attempted to reduce risk through command filtering and special-character restrictions. But allowed command arguments could still create execution behavior.
That is the common trap.
| Control | What it blocks | Why it can still fail |
|---|---|---|
| UI authentication | Random unauthenticated access | Authenticated users can be compromised or malicious |
| Special-character filtering | Obvious shell chaining | Execution can happen through normal arguments |
| Command allowlists | Unknown binaries | Known binaries can still be dangerous with unsafe args |
| Input sanitization | Simple injection strings | The process boundary remains exposed |
| Admin-only configuration | Normal users | Admin accounts can be phished or reused |
The better model is simpler:
If a feature can start a process, it needs process-execution controls.
Not form validation.
The Practical Fix List
Here is the patch and hardening checklist I would use for a production agent stack.
| Priority | Control | Why it matters |
|---|---|---|
| P0 | Upgrade Flowise to 3.1.0+ | Removes the known vulnerable Flowise code path |
| P0 | Upgrade Upsonic to 0.72.0+ | Removes the known vulnerable Upsonic code path |
| P0 | Disable Custom MCP STDIO where not needed | Removes the riskiest transport path |
| P0 | Put admin UIs behind SSO, VPN, or allowlists | Reduces exposure before a bug is found |
| P0 | Deny arbitrary command and args fields | Prevents user-controlled process launch |
| P1 | Restrict MCP tool creation with RBAC | Keeps normal users away from privileged tool setup |
| P1 | Isolate MCP runtimes in containers or sandboxes | Reduces blast radius after compromise |
| P1 | Separate agent runtime secrets from admin secrets | Limits what attackers can steal |
| P1 | Log MCP server creation and edits | Makes incident review possible |
| P1 | Add outbound network controls | Blocks easy data exfiltration paths |
Patching is only step one. If a user can still create a STDIO MCP server that starts arbitrary local commands, the same class of issue can return through another package, another adapter, or another "safe" argument path.
How I Would Triage This In Production
Start with exposure, not theory.
| Environment | First question | First action |
|---|---|---|
| Public Flowise instance | Is the admin UI reachable from the internet? | Remove public access and patch immediately |
| Internal Flowise instance | Who can create MCP tools? | Restrict creation to trusted admins |
| Upsonic deployment | Are MCP tasks enabled? | Patch to 0.72.0+ and review tasks |
| LiteLLM deployment | Are MCP management endpoints enabled? | Patch and disable unused preview features |
| Local developer machine | Are untrusted MCP configs installed? | Remove unknown configs and rotate exposed keys |
| Enterprise agent platform | How many MCP runtimes can launch processes? | Inventory and sandbox those runtimes |
"Internal only" is not enough. Agent servers often hold API keys, cloud credentials, repository access, database tokens, vector database credentials, and observability tokens.
That makes an internal agent server a high-value target.
A Simple Risk Formula
You do not need fake breach math to decide whether this is serious. Use a fast operational estimate:
| Question | Simple formula |
|---|---|
| How much patch work is likely? | (MCP hosts x 2 hours) + (workspaces x 0.5 hours) |
| How much secret rotation could be needed? | runtime secrets + provider keys + database tokens |
| How wide is the blast radius? | public admin UIs + writable repos + reachable secret stores + outbound internet |
| How much isolation is missing? | MCP tools with process execution - sandboxed MCP tools |
For a small team with two MCP-enabled hosts and one shared workspace, this can be a half-day hardening job.
For an agency with 20 client workspaces and shared agent infrastructure, one compromised runtime can become a cross-client incident.
For an enterprise platform with 50 internal MCP tools, the problem is no longer one CVE. It is governance around tool creation, runtime isolation, package trust, and secret boundaries.
Safe Hardening Tests
Do not validate this by running public exploit payloads. Test the controls.
| Test | Expected safe result |
|---|---|
| Can a normal user create a Custom MCP STDIO server? | No |
| Can an MCP config include arbitrary command fields? | No |
| Can an MCP config include arbitrary args fields? | No |
| Can the runtime read production API keys by default? | No |
| Can the runtime reach the public internet freely? | No |
| Are MCP config changes logged with user identity? | Yes |
| Are approved MCP tools pinned by source and version? | Yes |
| Can you rotate agent runtime credentials quickly? | Yes |
If the first five answers are wrong, a patch alone is not enough.
The Bigger MCP Lesson
MCP is useful. It gives agents a common way to reach tools, data, and workflows.
But the security model changes when tools can touch local processes, package managers, terminals, files, credentials, and outbound networks.
The right default is:
MCP HTTP tools need API security.
MCP STDIO tools need process security.
That means sandboxing, RBAC, audit logs, egress controls, private registries, version pinning, secret isolation, and fast revocation.
If your team is building an agent platform, this is the durable lesson from Flowise CVE-2026-40933 and Upsonic CVE-2026-30625. The bug names will age. The boundary mistake will not.