CVE-2026-67428: Server-Side Request Forgery in Flyto2 Core HTTP-Emitting Modules

Flyto2 Core (flyto-core) is an execution engine designed for AI-agent operations and task automations. To carry out its operational steps, it frequently issues outbound HTTP requests on behalf of its users. Prior to version 2.26.7, the framework suffered from multiple decentralized Server-Side Request Forgery (SSRF) vulnerabilities due to inconsistent security posture across its outbound modules.\n\nSeveral modules emitted raw outbound requests directly to caller-provided URLs without passing them through the internal URL sanitation gateway. Because this component serves as the central hub for running dynamic workflow automation steps, the lack of centralized enforcement allowed authenticated users with low privileges to instruct the server to fetch localized configurations, interrogate adjacent intranet APIs, or compromise platform integrity.

The core vulnerability resides in the application's decentralized approach to verifying outbound HTTP destinations. The architecture relied on individual modules to explicitly opt-in to validation via the validate_url_with_env_config utility, rather than deploying an egress-level firewall or a secure-by-default wrapped client interface.\n\nMultiple modules processing third-party webhook integrations, AI vision workflows, GraphQL queries, and proxy configurations executed direct, raw requests using standard networking clients such as aiohttp or httpx without checking the targets. This architectural choice bypassed validation policies designed to blacklist private subnets (such as 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and cloud metadata API addresses (such as 169.254.169.254). Consequently, an attacker capable of configuring tasks could direct the server to communicate with internal resources that are isolated from external internet access.\n\nmermaid\ngraph LR\n A["Low-Privilege User"] -->|"1. Injects internal target URL"| B["Flyto2 Core Executor"]\n B -->|"2. Skips validate_url_with_env_config"| C["Internal Subnet / Cloud Metadata"]\n

The implementation of the fix in commit 0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9 standardized validation across all vulnerable modules. It introduced enforce_outbound_url within src/core/utils.py to route all external URLs through validate_url_with_env_config before issuing requests.\n\nFor example, the AI Vision analyzer was patched to check user-submitted image URLs:\n\npython\n# Before patch\nasync with session.get(image_url) as img_resp:\n if img_resp.status != 200:\n raise ModuleError(f"Failed to download image")\n\n# After patch\ntry:\n enforce_outbound_url(image_url)\nexcept SSRFError as e:\n raise ModuleError(f"SSRF protection blocked request: {e}")\nasync with session.get(image_url) as img_resp:\n pass\n\n\nAdditionally, the patch addressed a redirect bypass (GHSA-c9hr-64h3-gxpc) where an initially validated URL redirected to an internal resource. To block this, a custom guarded_aiohttp_request function disables automatic redirect processing (allow_redirects=False) and manually evaluates the destination host on every redirection hop.\n\nWhile this validation reduces the direct attack surface, the resolution remains susceptible to DNS rebinding. Since the framework resolves hostnames inside validate_url_with_env_config and then triggers a second, independent DNS resolution during the subsequent aiohttp request, a fast-flux DNS response can still redirect the active TCP connection to an internal interface.

Exploitation requires low-privileged user credentials or access to a workspace where workflows can be configured. An attacker can use two primary vectors to compromise isolated systems or access cloud environments.\n\nIn the first vector, an attacker sets up an AI vision workflow using the ai.vision_analyze step. By supplying the EC2 Instance Metadata Service (IMDSv1) endpoint (http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role) in the image_url field, the worker agent attempts to retrieve the file. Even though the system fails to parse the resulting text as an image, the raw response or debug logs of the execution state can reveal temporary IAM credentials.\n\nIn the second vector, an attacker maps local networks using the webhook modules. By submitting internal IP addresses to communication.slack_send or notification.discord.send_message, the attacker monitors execution latency and error codes. A connection timeout versus an immediate refusal allows the attacker to map active network services across internal IP subnets.

The impact of this vulnerability is classified as High, with a CVSS base score of 8.5. Because the application scope changes (Scope: Changed) from the application container to the host or private local area networks, successful exploitation compromises the confidentiality of separate systems.\n\nAccessing internal endpoints enables attackers to retrieve sensitive configurations, bypass firewalls, and extract credentials. If the execution environment resides on AWS, GCP, or Azure, unauthenticated access to the metadata server compromises IAM service credentials, facilitating lateral movement within the cloud infrastructure.\n\nFurthermore, when chained with the related unauthenticated execution endpoint vulnerability (GHSA-jx74-cqjv-2c67), this flaw allows external actors on the same network to leak the internal execution secret (FLYTO_RUNNER_SECRET), yielding full administrator access over the workflow runner cluster.

To completely resolve the vulnerability, administrators must upgrade the flyto-core application to version 2.26.7 or newer. This update integrates standardized outbound request gating and blocks the HTTP redirect bypass.\n\nIf immediate upgrading is not possible, implement the following network-level mitigations:\n\n* Deploy egress firewall rules on host machines to block the workflow runner containers from reaching the private subnet ranges 10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 unless explicitly required.\n\n* Enforce AWS IMDSv2 and set the HTTP hop limit to 1. This stops containers from accessing host instance metadata.\n\n* Run workflow executors within isolated, sandboxed virtual private networks (VPCs) without physical routes to active production microservices or administrative databases.