Summary
Flyto2 Core exposes an HTTP MCP route that can accept unauthenticated JSON-RPC tool calls and pass attacker-controlled command arguments to a shell-executing module. An attacker who can reach the route may execute operating-system commands with the privileges of the Flyto2 server process, with network exposure depending on the server binding.
Flyto2 Core exposes an HTTP MCP route that can accept unauthenticated JSON-RPC tool calls and pass attacker-controlled command arguments to a shell-executing module. An attacker who can reach the route may execute operating-system commands with the privileges of the Flyto2 server process, with network exposure depending on the server binding.
Affected context
The vulnerability occurs in Flyto2 Core deployments from the affected release range when:
- The HTTP MCP
/mcproute is enabled - JSON-RPC
tools/callrequests are accepted without authentication - The execution path permits selection of
sandbox.execute_shell - The server is reachable by an attacker, either locally through the default loopback binding or remotely when bound to a non-loopback interface
The resulting commands run with the privileges assigned to the Flyto2 Core server process.
The vulnerability occurs in Flyto2 Core deployments from the affected release range when:
- The HTTP MCP
/mcproute is enabled - JSON-RPC
tools/callrequests are accepted without authentication - The execution path permits selection of
sandbox.execute_shell - The server is reachable by an attacker, either locally through the default loopback binding or remotely when bound to a non-loopback interface
The resulting commands run with the privileges assigned to the Flyto2 Core server process.
Exploit preconditions
- Attack surface: HTTP MCP POST
/mcpendpoint - Required access: Network or local access to the exposed endpoint; no application authentication is required on the affected route
- Trigger point: An unauthenticated JSON-RPC
tools/callrequest selecting the shell-execution module - Why exploitation is possible: The route forwards attacker-controlled execution arguments to a shell subprocess without applying the authentication dependency used by other execution routes
- Attack surface: HTTP MCP POST
/mcpendpoint - Required access: Network or local access to the exposed endpoint; no application authentication is required on the affected route
- Trigger point: An unauthenticated JSON-RPC
tools/callrequest selecting the shell-execution module - Why exploitation is possible: The route forwards attacker-controlled execution arguments to a shell subprocess without applying the authentication dependency used by other execution routes
Why this happens
The underlying issue is a command-injection path combined with missing access control.
The MCP route permits unauthenticated selection of an execution-capable module and forwards its command parameter to a shell subprocess API. Passing externally controlled data into shell command execution without a trusted boundary or strict command model maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command. The absent authentication control also relates to CWE-306: Missing Authentication for Critical Function.
The underlying issue is a command-injection path combined with missing access control.
The MCP route permits unauthenticated selection of an execution-capable module and forwards its command parameter to a shell subprocess API. Passing externally controlled data into shell command execution without a trusted boundary or strict command model maps to CWE-78: Improper Neutralization of Special Elements used in an OS Command. The absent authentication control also relates to CWE-306: Missing Authentication for Critical Function.
Potential impact
- An attacker may execute arbitrary operating-system commands
- The attacker could access or modify files available to the server process
- Application secrets, credentials, or workflow data may be exposed
- The Flyto2 runtime could be disrupted or modified
- Host compromise or lateral movement could occur, depending on process privileges and isolation
- An attacker may execute arbitrary operating-system commands
- The attacker could access or modify files available to the server process
- Application secrets, credentials, or workflow data may be exposed
- The Flyto2 runtime could be disrupted or modified
- Host compromise or lateral movement could occur, depending on process privileges and isolation
General mitigation guidance
Mitigation generally focuses on enforcing authorization at every execution-capable entry point and removing unnecessary shell interpretation.
Common defensive patterns include:
- Require authentication and authorization for MCP tool calls that can execute workflows or commands
- Apply the same access-control dependency consistently across REST, MCP, and other execution routes
- Prefer structured, allowlisted operations over arbitrary shell command strings
- Avoid shell-based subprocess APIs when a direct executable-and-argument interface is sufficient
- Treat tool arguments as untrusted input and validate them against strict schemas and permitted values
- Bind administrative execution services to loopback or a protected network by default
- Run the server with least-privilege operating-system permissions and appropriate isolation
- Restrict filesystem, network, and credential access available to execution workers
Mitigation generally focuses on enforcing authorization at every execution-capable entry point and removing unnecessary shell interpretation.
Common defensive patterns include:
- Require authentication and authorization for MCP tool calls that can execute workflows or commands
- Apply the same access-control dependency consistently across REST, MCP, and other execution routes
- Prefer structured, allowlisted operations over arbitrary shell command strings
- Avoid shell-based subprocess APIs when a direct executable-and-argument interface is sufficient
- Treat tool arguments as untrusted input and validate them against strict schemas and permitted values
- Bind administrative execution services to loopback or a protected network by default
- Run the server with least-privilege operating-system permissions and appropriate isolation
- Restrict filesystem, network, and credential access available to execution workers
How teams detect issues like this
Detection can combine code review, static analysis, endpoint testing, and runtime monitoring.
Useful checks include:
- Searching for MCP or JSON-RPC routes that dispatch tools without authentication or authorization middleware
- Reviewing data flows from request parameters into shell subprocess APIs
- Flagging uses of shell execution with externally controlled strings
- Verifying that authorization policies cover every protocol and route exposing execution-capable tools
- Testing deployments to confirm unauthenticated
tools/callrequests cannot invoke privileged modules - Monitoring logs for unexpected MCP tool selections, shell execution events, and unusual child-process creation
- Enforcing CI or automated review rules for missing authentication dependencies and unsafe subprocess patterns
Detection can combine code review, static analysis, endpoint testing, and runtime monitoring.
Useful checks include:
- Searching for MCP or JSON-RPC routes that dispatch tools without authentication or authorization middleware
- Reviewing data flows from request parameters into shell subprocess APIs
- Flagging uses of shell execution with externally controlled strings
- Verifying that authorization policies cover every protocol and route exposing execution-capable tools
- Testing deployments to confirm unauthenticated
tools/callrequests cannot invoke privileged modules - Monitoring logs for unexpected MCP tool selections, shell execution events, and unusual child-process creation
- Enforcing CI or automated review rules for missing authentication dependencies and unsafe subprocess patterns
