CVE-2026-40933 - Flowise MCP adapter command execution
Flowise versions 3.0.13 and earlier allow authenticated command execution
through Custom MCP adapter configuration. The vulnerable path accepts stdio MCP
server settings, including command and argument fields, from an authenticated
user and serializes them into a server-side MCP launch request.
For agentic AI platforms, this is a secure-context failure: an MCP server definition is treated like ordinary configuration even though stdio transport is a local process launch boundary. A low-privilege tenant, workspace user, or chatflow author who can configure Custom MCP servers may be able to make the Flowise host execute a command in the Flowise runtime context.
When to use it
Use this recipe when a repository, Flowise deployment, or agent platform allows users to configure Custom MCP stdio adapters. It supports source-code remediation, MCP process-launch boundary review, tenant isolation, and audit evidence that server-side MCP definitions cannot spawn arbitrary commands.
Inputs
- Flowise and component versions, Custom MCP settings, tenant/workspace model, enabled transports, and deployment manifest.
- Source paths that persist MCP server definitions, validate stdio command fields, launch adapters, check workspace permissions, or serialize errors.
- Regression fixtures for arbitrary executables, absolute paths, package manager commands, allowed registry entries, and low-privilege users.
- Runtime boundary evidence: server filesystem, environment variables, credentials, package manager access, Docker/socket access, and network egress.
Affected versions
- Vulnerable:
flowise <=3.0.13 - Vulnerable:
flowise-components <=3.0.13 - Minimum CVE fix:
flowise 3.1.0+andflowise-components 3.1.0+ - Reviewer-preferred target:
flowise 3.1.2+andflowise-components 3.1.2+when Custom MCP remains enabled, because follow-up GHSA-m99r-2hxc-cp3q documents bypasses in earlier Custom MCP command filtering. - Affected surface: Custom MCP configuration using stdio transport.
Indicator-of-exposure
- The repository deploys, builds, vendors, or documents Flowise
<=3.0.13. - Authenticated users, tenants, workspace members, automation accounts, or imported chatflows can create or edit Custom MCP server definitions.
- MCP stdio transport is enabled or not explicitly blocked by policy.
- Flowise runs with access to model provider keys, workflow secrets, source repositories, cloud metadata, internal services, mounted volumes, or writable deployment storage.
- The deployment treats “authenticated user” as a broad role rather than a tightly controlled administrator role.
Quick checks:
rg -n "flowise|flowise-components|Custom MCP|MCP|stdio|mcpServers|validateCommandInjection|validateArgsForLocalFileAccess|FLOWISE" .
npm ls flowise flowise-components
pnpm why flowise flowise-components
yarn why flowise flowise-components
rg -n "custom.*mcp|mcp.*custom|stdio|command.*args|chatflow|FLOWISE_USERNAME|FLOWISE_PASSWORD" Dockerfile* docker-compose*.yml charts deploy k8s .github .
Remediation strategy
- Upgrade
flowiseandflowise-componentsto at least3.1.0everywhere this repository controls manifests, lockfiles, images, or deployment manifests. If Custom MCP stdio remains enabled, target3.1.2+to include the follow-up security hardening for GHSA-m99r-2hxc-cp3q. - Disable creation and execution of Custom MCP stdio servers until every runtime is patched.
- Require explicit administrator approval for MCP stdio definitions. Treat stdio MCP configuration as local code execution, not as tenant data.
- Replace raw command/argument entry with an approved MCP server registry, pinned packages or binaries, command allow-lists, environment redaction, and per-server least-privilege runtime policy.
- Isolate Flowise workers from cloud metadata, deployment credentials, package publishing tokens, source checkout credentials, and broad filesystem mounts.
- Rotate Flowise, model provider, MCP environment, and runtime credentials if untrusted users could create Custom MCP definitions during the exposure window.
The prompt
You are remediating CVE-2026-40933 / GHSA-c9gw-hvqq-f33r, a critical Flowise
authenticated command-execution issue in Custom MCP stdio adapter configuration.
Produce exactly one output:
- A reviewer-ready PR/change request that upgrades Flowise, blocks unsafe MCP
stdio configuration, adds safe regression coverage, and documents operator
cleanup, or
- TRIAGE.md if this repository does not own an affected Flowise deployment or
cannot make a safe change.
## Rules
- Scope only CVE-2026-40933 / GHSA-c9gw-hvqq-f33r.
- Treat Flowise credentials, model provider keys, MCP environment values,
chatflow exports, tenant prompts, server logs, source code, and deployment
secrets as sensitive.
- Do not run exploit commands, arbitrary subprocesses, reverse shells, package
installers, network beacons, or attacker-controlled MCP stdio definitions to
prove exposure.
- Do not preserve broad tenant or low-privilege access to Custom MCP stdio
server creation.
- Do not rely on string deny-lists, prompt instructions, or UI-only validation
as the sole security control.
- Do not auto-merge.
## Steps
1. Inventory every Flowise runtime controlled by this repository:
`package.json`, lockfiles, Dockerfiles, compose files, Helm charts,
Kubernetes manifests, Terraform, Ansible, CI images, SBOMs, seed chatflows,
exported chatflow JSON, environment templates, and runbooks.
2. Determine every resolved `flowise` and `flowise-components` version. A target
is vulnerable if either package resolves to `<=3.0.13`.
3. Search for Custom MCP and stdio exposure:
- Custom MCP node definitions;
- exported chatflows containing MCP server config;
- admin UI or API routes that save MCP server definitions;
- tenant/workspace roles that can edit chatflows;
- any config path containing `command`, `args`, `env`, `stdio`, or local
executable references.
4. If this repository does not deploy Flowise or only contains unrelated client
code, stop with `TRIAGE.md` listing files checked, runtime owner, and the
required fixed version `Flowise 3.1.0+` for this CVE, or `Flowise 3.1.2+`
when Custom MCP stdio remains enabled.
5. Upgrade all controlled Flowise packages and images to at least `3.1.0`.
If Custom MCP stdio remains enabled, target `3.1.2+` because follow-up
advisory GHSA-m99r-2hxc-cp3q documents bypasses in the earlier command
filtering. Regenerate lockfiles, image digests, SBOMs, deployment render
output, and dependency reports.
6. Add containment for non-atomic rollouts:
- disable Custom MCP stdio creation until patched;
- block API routes that create or test stdio MCP definitions unless the
caller is an approved administrator;
- fail closed when the Flowise version, node type, or transport type cannot
be determined;
- reject imported chatflows that contain stdio MCP definitions on vulnerable
versions.
7. Replace unsafe configuration patterns where this repo controls product code:
- do not accept raw command strings from users;
- do not pass user-controlled args or env directly to child-process launch;
- require an approved MCP server registry entry with pinned package or binary
identity;
- map approved product options to a finite command allow-list;
- redact environment values from logs, reports, and browser-visible errors.
8. Add regression tests or policy checks that do not execute commands:
- vulnerable Flowise versions are rejected by dependency policy;
- non-admin roles cannot create, test, import, or enable stdio MCP servers;
- imported chatflows containing stdio MCP config fail closed until reviewed;
- command, argument, and environment fields are ignored or rejected unless
they reference an approved registry entry;
- route/gateway render output contains the temporary deny or admin-only rule.
9. Harden the Flowise runtime where this repository controls deployment:
- run with a least-privilege service identity;
- remove cloud metadata and deployment-admin access from the Flowise process;
- restrict egress from Flowise workers;
- mount only required paths read-only where possible;
- ensure logs never contain provider keys, MCP env values, tenant prompts, or
full chatflow secrets.
10. Add a PR body section named `CVE-2026-40933 operator actions` that states:
- Flowise versions before and after the change;
- whether Custom MCP stdio was enabled;
- which roles could create or test MCP server definitions before the patch;
- whether any exported/imported chatflows contain stdio MCP config;
- which Flowise, model provider, MCP environment, and runtime credentials
should be rotated;
- which Flowise audit, application, gateway, and process logs should be
reviewed for suspicious MCP server definitions or unexpected child
processes;
- any temporary feature block still in place.
11. Run relevant validation: package install, lockfile integrity, unit/API
tests, role/authorization tests, chatflow import checks, gateway policy
tests, image build, deployment diff, SBOM refresh, and dependency/security
scans available in this repository.
12. Use PR title:
`fix(sec): remediate CVE-2026-40933 in Flowise MCP adapters`.
## Stop conditions
- No affected Flowise runtime is controlled by this repository.
- A fixed Flowise version cannot be consumed without a broader migration.
- Product requirements intentionally allow non-admin tenants to define local
MCP stdio commands; document the risk and require a product/security decision.
- Verification would require executing attacker-controlled commands or MCP
server definitions.
- Validation fails for unrelated pre-existing reasons; document those failures
instead of broadening scope.
Output contract
- A reviewer-ready PR or change request that upgrades Flowise, disables or governs Custom MCP stdio launch, adds allow-list/registry tests, and documents operator cleanup.
- Or a
TRIAGE.mdfile that lists inspected files, owner, observed versions, Custom MCP exposure, process-launch boundary, required fix, and residual risk. - The output must include exact validation commands and must not run package installers, arbitrary commands, local Node files, or production Flowise tests.
Verification - what the reviewer looks for
- No controlled package, lockfile, image, SBOM, or deployment target resolves
flowiseorflowise-componentsto<=3.0.13; if Custom MCP remains enabled, reviewers should require3.1.2+. - Non-admin users cannot create, test, import, or enable Custom MCP stdio definitions.
- Any remaining stdio MCP launch path is backed by an approved registry, command allow-list, environment redaction, and least-privilege execution.
- Tests prove vulnerable versions and unapproved stdio definitions fail closed without executing subprocesses.
- Operator actions cover credential rotation and log review when exposure was possible.
Watch for
- Upgrading the Flowise package while an image layer, global npm install, Helm
chart, or managed deployment still runs
flowise-components <=3.0.13. - Stopping at
3.1.0or3.1.1while Custom MCP stdio remains enabled and the follow-up GHSA-m99r-2hxc-cp3q bypass class is still in scope. - Treating authenticated workspace users as trusted administrators.
- Blocking the UI while leaving import, API, or test routes able to save stdio MCP definitions.
- Logging command arguments, MCP environment values, prompt content, or provider credentials while adding validation.
- Accepting “safe command” deny-lists that can be bypassed through argument serialization, package-manager flags, shell wrappers, or alternate binary names.
Related recipes
- Source code injection sink audit
- Source code authz tenant boundary audit
- Source code attack surface map
- SAST finding triage and fix
References
- GitHub Advisory: https://github.com/advisories/GHSA-c9gw-hvqq-f33r
- Follow-up Flowise MCP bypass: https://github.com/advisories/GHSA-m99r-2hxc-cp3q
- Flowise project: https://github.com/FlowiseAI/Flowise
- OX Security MCP advisory: https://www.ox.security/blog/mcp-supply-chain-advisory-rce-vulnerabilities-across-the-ai-ecosystem