Flytohub - CraftedSignal Threat Feed

flyto-core Unauthenticated Command Execution via HTTP MCP `execute_module`

hello@craftedsignal.io — Mon, 06 Jul 2026 17:45:25 +0000

flyto-core, an application leveraging FastAPI, is susceptible to an unauthenticated command execution vulnerability. This flaw exists within its HTTP MCP endpoint (POST /mcp), which lacks proper authentication and authorization checks. Discovered on 2026-07-06, the vulnerability allows unauthenticated attackers to send JSON-RPC tools/call requests that are then dispatched to arbitrary internal modules, including sandbox.execute_shell. This specific module executes attacker-controlled input directly via asyncio.create_subprocess_shell with shell=True, bypassing security controls. By default, flyto-core binds to 127.0.0.1, making it a high-severity local vulnerability (CVSS 8.4); however, if configured to bind to --host 0.0.0.0, it becomes remotely exploitable, enabling full system compromise with root privileges as demonstrated in dynamic reproductions.

Attack Chain

Attacker sends an unauthenticated HTTP POST request to the /mcp endpoint of a vulnerable flyto-core server.
The mcp_router (mounted at src/core/api/server.py:75-78) receives the request without requiring authentication.
The mcp_post function (src/core/api/routes/mcp.py:65-66) processes the request body, which is an attacker-controlled JSON-RPC payload.
The handle_jsonrpc_request function (src/core/api/routes/mcp.py:103-104) forwards the JSON-RPC item containing a tools/call method with name: execute_module and module_id: sandbox.execute_shell to the module dispatcher.
The module registry (src/core/mcp_handler.py:180) resolves sandbox.execute_shell and invokes it with attacker-supplied params, including a command argument.
The sandbox.execute_shell module (src/core/modules/atomic/sandbox/execute_shell.py:137-139) extracts the command directly from params without sanitization.
The command is passed to asyncio.create_subprocess_shell with shell=True (src/core/modules/atomic/sandbox/execute_shell.py:163-169).
The flyto-core server process executes the arbitrary OS command supplied by the attacker, with the privileges of the server.

Impact

This unauthenticated command execution vulnerability carries critical impact. Any local process can exploit the vulnerability if flyto serve is running on a workstation, leading to arbitrary file operations, credential exfiltration, or lateral movement. More severely, if flyto-core is exposed externally (e.g., bound to 0.0.0.0), unauthenticated remote attackers can achieve full system compromise with root privileges, as confirmed by dynamic reproduction. The vulnerability affects developers and local users running the service, as well as infrastructure operators who expose the API without proper network-level access controls. Consequences include complete host takeover.

Recommendation

Deploy the provided Sigma rule to detect unauthenticated POST requests to /mcp.
Inspect webserver logs for HTTP POST requests to the /mcp URI as an indicator of attempted exploitation.
Patch affected flyto-core instances immediately by applying the recommended code changes from the source, specifically ensuring require_auth dependency for /mcp routes and adding sandbox.* to the _DEFAULT_DENYLIST.

flyto-core SSRF Bypass via IPv6 Transition Addresses (CWE-918)

hello@craftedsignal.io — Mon, 06 Jul 2026 17:36:55 +0000

The flyto-core application, developed by flytohub, contains a critical Server-Side Request Forgery (SSRF) vulnerability, identified as CWE-918, in its validate_url_ssrf function, specifically within the is_private_ip helper in src/core/utils.py. This vulnerability, published on 2026-07-06, allows an authenticated workflow author to bypass the intended SSRF protection by utilizing IPv6 transition addresses. The application's guard, designed to block access to private and cloud metadata services, fails to correctly identify private IP addresses embedded within IPv4-mapped, 6to4, or NAT64 IPv6 formats. This oversight enables attackers to craft URLs using these unblocked IPv6 forms to access internal resources like cloud instance metadata services (e.g., 169.254.169.254) or internal loopback services. The response body from these internal services is then returned to the attacker, resulting in a read SSRF that can lead to the exfiltration of sensitive information, such as IAM credentials. This bypass directly undermines the project's documented security controls.

Attack Chain

A workflow author, possessing valid authentication credentials for flyto-core's Execution API (POST /v1/execute), prepares to execute a module.
The attacker crafts a malicious URL containing an IPv6 transition-form host, such as http://[::ffff:127.0.0.1]:8080/ for loopback access or http://[64:ff9b::a9fe:a9fe]/latest/meta-data/ for cloud instance metadata.
The attacker sends a POST request to http://127.0.0.1:8333/v1/execute with a JSON payload including {"module_id":"http.get", "params":{"url":"[malicious_url]"}}.
The flyto-core application invokes validate_url_ssrf, which calls is_private_ip() on the IPv6 transition address. Due to the vulnerability, is_private_ip() incorrectly returns False.
The http.get atomic module proceeds to initiate an outbound HTTP GET request using aiohttp to the internal destination specified by the crafted URL.
The internal service (e.g., cloud metadata service or a local web server) processes the request and returns its sensitive response body.
flyto-core receives the internal service's response and, as part of the http.get module's functionality, returns the full response body to the attacker in the /v1/execute API response.
The attacker successfully exfiltrates sensitive data, such as IAM credentials or internal service information, via a read Server-Side Request Forgery.

Impact

The vulnerability allows an authenticated workflow author to bypass flyto-core's security controls and perform read Server-Side Request Forgery (SSRF). This directly enables data exfiltration from internal services that are typically isolated from external access. Specifically, attackers can access cloud instance metadata services (e.g., 169.254.169.254) to steal highly sensitive IAM credentials and instance identity information. Additionally, the bypass permits access to internal loopback and RFC 1918 services, potentially exposing other sensitive internal applications or data. The success of this attack directly undermines the intended security model of flyto-core, which explicitly documents these checks as critical security controls. While the source does not provide victim numbers, any organization using flyto-core is susceptible, especially those deployed in cloud environments.

Recommendation

Immediately apply the patch provided by flytohub, which modifies src/core/utils.py to correctly identify and block private IP addresses embedded within IPv6 transition forms, as demonstrated in the "Suggested fix" section of this brief.
Review all flyto-core deployments, especially those in cloud environments, to ensure proper network segmentation and defense-in-depth measures limit the impact of potential SSRF vulnerabilities.
Monitor network egress logs for connections originating from flyto-core instances to unusual or internal-only IPv6 addresses, particularly those resembling the IPv4-mapped ::ffff:169.254.169.254, NAT64 64:ff9b::/96, or 6to4 2002::/16 prefixes.
Ensure that cloud metadata services and other sensitive internal endpoints are configured with least privilege access and minimal exposed information, assuming they might eventually be accessed by an SSRF attack.