What Happened
Obsidian Security disclosed CVE-2026-40933, a critical remote code execution vulnerability in Flowise's Model Context Protocol (MCP) stdio server implementation. The vulnerability has a CVSS score of 9.9 and affects self-hosted deployments. An attacker with access to Flowise's interface can execute arbitrary commands on the host system with the privileges of the Flowise process—often root in containerized deployments.
The core issue is that Flowise allows users to configure MCP stdio servers that spawn child processes. The implementation trusts user-supplied input to construct command strings, creating a direct path from the web interface to shell execution.
Flowise released patches, but Obsidian Security demonstrated these protections are easily bypassed. The vendor's fix relies on input validation—checking for shell metacharacters and dangerous patterns—which attackers can circumvent using standard encoding techniques and command substitution.
Timeline
Initial Discovery: Obsidian Security identified the vulnerability during a routine assessment of AI platform security controls.
Disclosure: Researchers contacted Flowise maintainers through responsible disclosure channels.
First Patch: Flowise released input validation controls to block obvious command injection patterns.
Bypass Published: Obsidian Security shared proof-of-concept code demonstrating the validation could be bypassed, rendering the patch ineffective.
Current Status: The vulnerability remains exploitable in default configurations. Obsidian Security recommends disabling MCP stdio entirely or implementing strict allowlisting at the infrastructure level.
Which Controls Failed or Were Missing
Least Privilege Execution: Flowise processes often run with elevated privileges, particularly in Docker deployments where the container runs as root. When the RCE executes, it inherits these privileges.
Input Validation as Primary Defense: The patch attempted to sanitize user input before passing it to shell commands. This approach fails because:
- Blacklisting dangerous characters misses encoding variations.
- Command substitution (
$(cmd)) bypasses string filters. - Shell parsing happens after validation, creating race conditions.
- Validation logic cannot anticipate all shell interpreter behaviors.
Process Isolation: MCP stdio servers spawn as child processes of the main Flowise application without sandboxing. No seccomp profiles, no capability dropping, no namespace isolation.
Secure Defaults: MCP stdio functionality ships enabled by default. Users must actively disable it, and many don't know it exists until they're compromised.
Architectural Separation: The same process that serves the web interface also spawns arbitrary child processes. No separation of concerns, no privilege boundaries between components.
What the Standards Require
OWASP ASVS v4.0.3 Requirement 5.3.3: "Verify that the application validates, sanitizes and escapes output to prevent injection flaws." The key word here is "output"—not just input. Flowise validates input but then passes it to a shell interpreter, which performs its own parsing. The validation happens at the wrong layer.
OWASP Top 10 2021 - A03:Injection: Specifically calls out command injection and recommends using safe APIs that avoid shell interpreters entirely. Instead of validating input before spawn() or exec(), the application should use parameterized APIs that don't invoke a shell.
NIST 800-53 Rev 5 Control AC-6 (Least Privilege): "Each process executes with the least set of privileges necessary." Running AI workloads as root violates this control. Even if the RCE exists, limiting process privileges contains the blast radius.
ISO/IEC 27001:2022 Control 8.22 (Segregation in Networks): While focused on network segregation, the principle applies to process architecture. Critical functions like arbitrary code execution should be isolated from user-facing components.
PCI DSS v4.0.1 Requirement 6.2.4: "Software engineering techniques or other methods are defined and in use by software development personnel to prevent or mitigate common software attacks and related vulnerabilities." This includes architectural reviews to identify dangerous patterns like passing user input to shell commands.
Lessons and Action Items for Your Team
Stop treating input validation as a security boundary. If your application passes user input to a shell, command interpreter, or eval-like function, validation will eventually fail. Attackers have decades of encoding tricks. Use parameterized APIs that bypass the shell entirely. In Node.js, that means spawn() with array arguments, not string concatenation.
Audit your AI toolchain for similar patterns. Flowise isn't unique. Many AI platforms allow users to configure external tools, run scripts, or chain LLM outputs to system commands. Search your codebase for:
child_process.exec()with user-controlled arguments.- Template strings that include user input passed to shells.
- Configuration files that specify command paths without validation.
Implement defense in depth for AI workloads:
- Run AI services in containers with read-only root filesystems.
- Drop all capabilities except those explicitly required (CAP_NET_BIND_SERVICE if you need port 80, nothing else).
- Use seccomp profiles to block dangerous syscalls like
execve()for processes that don't need them. - Set resource limits (CPU, memory, file descriptors) to contain runaway processes.
Disable features you don't use. If you're running Flowise, disable MCP stdio unless you have a specific, documented use case. Apply this principle broadly: every enabled feature is attack surface.
Test your patches. Flowise released a fix that didn't work. Before you mark a vulnerability as remediated, verify the control actually prevents exploitation. Run the proof-of-concept. Try to bypass your own validation. If you can't test safely in production, spin up a staging environment that mirrors your production architecture.
Plan for privilege escalation. Assume every RCE will eventually succeed. Design your infrastructure so that compromising one component doesn't grant access to everything else. Network segmentation, separate credentials for each service, monitoring for lateral movement.
The Flowise incident demonstrates why "shift left" isn't enough. You also need to shift down—into the infrastructure layer where you can enforce controls that survive application-level bypasses. Input validation is hygiene, not a security boundary. Your architecture must assume it will fail.
