Flyto2 Core versions prior to 2.28.0 contain a server-side request forgery (SSRF) vulnerability. This flaw allows attackers to bypass SSRF protections by using the IPv6 address ::, which the kernel routes to the loopback interface similarly to 0.0.0.0. By exploiting this, attackers can reach internal services that should be protected by private IP and hostname checks in the is_private_ip() function. The vulnerability affects the http.get, http.request, and http.batch modules. The issue is identified with a CVSS 4.0 score of 6.3, indicating medium severity.
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, image.download and related file-writing modules use caller-controlled output_dir instead of validate_path_with_env_config and its FLYTO_SANDBOX_DIR confinement, allowing attacker-controlled response bytes to be written to arbitrary filesystem paths the process can access. This issue is fixed in version 2.26.6.
CVE-2026-67428 is a Server-Side Request Forgery (SSRF) vulnerability in flytohub's flyto-core execution kernel for automation and AI-agent workflows. Versions prior to 2.26.7 allow HTTP-emitting modules to fetch URLs controlled by an attacker without proper validation, enabling SSRF attacks against internal or metadata endpoints. This vulnerability affects multiple modules including HTTP request handlers and notification senders. The issue is fixed in version 2.26.7.
Flytohub flyto-core versions prior to 2.26.6 contain a vulnerability where the workflow engine variable resolver expands environment variables without an allowlist or capability policy check. This allows workflow parameters to bypass default denylist policies and potentially exfiltrate secrets through allowed modules. The issue is fixed in version 2.26.6.
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the standalone flyto-verification service in src/core/verification_service.py exposes unauthenticated POST /run on 0.0.0.0:8344 and uses client-supplied callback_url for an outbound POST with X-Internal-Key: $FLYTO_RUNNER_SECRET while bypassing target_allowed, allowing unauthenticated SSRF and runner secret exfiltration. This issue is fixed in version 2.26.7.
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.6, llm.chat reads provider keys such as OPENAI_API_KEY and ANTHROPIC_API_KEY from the environment and sends them in the Authorization: Bearer header to caller-controlled base_url, allowing an attacker to receive the operator's key on a public host that passes the SSRF guard. This issue is fixed in version 2.26.6.
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.7, the HTTP modules http.get, http.request, and http.batch in src/core/modules/atomic/http/get.py, src/core/modules/atomic/http/request.py, and src/core/modules/atomic/http/batch.py validate only the initial URL, then follow redirects with allow_redirects=True and without per-hop Location revalidation, allowing a public URL to redirect into internal address space and return the internal response body. This issue is fixed in version 2.26.7.