Flyto2 Core vulnerabilities

A vulnerability in Flyto2 Core before version 2.26.6 allows an attacker to write files to arbitrary filesystem paths by controlling the output_dir parameter in the image.download module. The lack of path validation against the FLYTO_SANDBOX_DIR configuration enables writing response bytes anywhere.

A vulnerability in Flyto2 Core before version 2.26.7 in the flyto-verification service allows unauthenticated attackers to perform SSRF and steal the runner secret. The server listens on 0.0.0.0:8344 and uses a client-supplied callback_url to send a POST request with the X-Internal-Key header, bypassing target_allowed validation.

Flyto2 Core, an execution kernel for automation and AI-agent workflows, prior to 2.26.3 has validate_url_ssrf and is_private_ip in src/core/utils.py that compare resolved addresses only against native private IPv4 and IPv6 ranges and do not unwrap IPv4-mapped, IPv4-compatible, 6to4, or NAT64 transition addresses. An authenticated workflow author can provide a transition-form literal URL through the Execution API POST /v1/execute route, http.get, or sibling guarded outbound-request modules, causing the guard to accept an address whose embedded IPv4 points to loopback, RFC 1918, or cloud metadata services. On a host that routes the selected transition form, the outbound request reaches the internal destination and returns the response body to the workflow caller, enabling read SSRF and disclosure of internal-service data or cloud credentials.

Flyto2 Core, an execution kernel for automation and AI-agent workflows, from 2.26.2 until 2.26.4 has an HTTP MCP POST /mcp route that accepts unauthenticated JSON-RPC tools/call requests and forwards execute_module arguments to the module registry without the require_auth dependency used by the REST execution routes. An unauthenticated caller can select sandbox.execute_shell and supply its command parameter, which reaches asyncio.create_subprocess_shell with the privileges of the flyto-core server process. The endpoint is reachable locally under the default loopback binding and becomes network reachable when an operator binds the server to a non-loopback interface, allowing arbitrary OS command execution and potential full host compromise.

Flyto2 Core before version 2.28.0 contains a server-side request forgery guard bypass vulnerability that allows attackers to reach internal services by supplying URLs using the unblocked IPv6 address `::` which the kernel routes to loopback identically to `0.0.0.0`. Attackers can submit requests or trigger 302 redirects to bypass the private IP range and blocked hostname checks in is_private_ip(), reaching services bound to IPv6 loopback across the http.get, http.request, and http.batch modules.

Vulnerability in Flyto2 Core before version 2.26.7 allows an attacker to perform SSRF requests to internal or metadata endpoints via HTTP modules that fetch attacker-controlled URLs without validation.

Vulnerability in Flyto2 Core before version 2.26.6 allows environment variable expansion ${env.VAR} without an allowlist, bypassing the default denylist policy and exfiltrating secrets through allowed modules.

Vulnerability in Flyto2 Core before version 2.26.6 allows the llm.chat module to read provider keys (e.g., OPENAI_API_KEY) from the environment and send them in the Authorization header to an attacker-controlled server, leading to key leakage.

In Flyto2 Core prior to version 2.26.7, HTTP modules validate only the initial URL and then follow redirects without per-hop Location revalidation. This allows a public URL to redirect into internal address space and return the internal response body.