CVE-2026-67424: Flyto2 Core SSRF Vulnerability

CVE-2026-67424 Overview

CVE-2026-67424 is a Server-Side Request Forgery (SSRF) vulnerability [CWE-918] in Flyto2 Core, an execution kernel for automation and AI-agent workflows. The HTTP modules http.get, http.request, and http.batch validate only the initial request URL. They then follow HTTP redirects with allow_redirects=True and skip per-hop Location header revalidation. An attacker can supply a public URL that redirects into internal address space and receive the internal response body back through the module. The issue affects all versions prior to 2.26.7 and is fixed in version 2.26.7.

Critical Impact
Authenticated attackers can pivot from public URLs into internal network resources, cloud metadata endpoints, and other non-routable services, exfiltrating internal response bodies through Flyto2 automation workflows.

Affected Products

Flyto2 Core versions prior to 2.26.7
src/core/modules/atomic/http/get.py (http.get module)
src/core/modules/atomic/http/request.py and src/core/modules/atomic/http/batch.py

Discovery Timeline

2026-07-29 - CVE-2026-67424 published to the National Vulnerability Database
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-67424

Vulnerability Analysis

The Flyto2 Core HTTP atomic modules enforce URL validation only against the caller-supplied URL. Once the outbound request is issued, the underlying HTTP client follows 3xx responses automatically because allow_redirects=True is set. The Location value returned by the remote server is never re-checked against outbound URL policy. An attacker with permission to invoke an HTTP module supplies a public URL under their control. The remote server responds with a redirect to an internal target such as http://169.254.169.254/latest/meta-data/, http://127.0.0.1:8080/admin, or an internal RFC 1918 address. The HTTP client follows the redirect and returns the internal response body to the calling workflow, exposing cloud instance metadata, internal APIs, and dashboards that are otherwise unreachable.

Root Cause

The root cause is a missing per-hop URL guard. The initial URL passes validation, but redirect targets bypass that same check because the modules delegate redirect handling to the HTTP client. The upstream fix introduces a shared enforce_outbound_url helper and a SSRFError exception that must be evaluated on every hop, closing the redirect gap across atomic modules.

Attack Vector

Exploitation requires network access to the Flyto2 API and low-privilege authenticated access to invoke HTTP modules. No user interaction is required. The attacker hosts an HTTP endpoint returning a 302 redirect pointing at an internal service, submits that endpoint through http.get, http.request, or http.batch, and reads the returned body.

python

# Security patch: per-module SSRF guard added in v2.26.7
# Source: https://github.com/flytohub/flyto-core/commit/0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9
 from ...errors import ModuleError, ValidationError
 from ...registry import register_module
 from ...schema import compose, field
+from ....utils import enforce_outbound_url, SSRFError

 logger = logging.getLogger(__name__)

The patch imports a shared enforce_outbound_url helper into each atomic HTTP module so redirect targets are validated on every hop rather than only at request initiation.

Detection Methods for CVE-2026-67424

Indicators of Compromise

Outbound HTTP requests from Flyto2 workers to RFC 1918 addresses, loopback, or link-local ranges such as 169.254.169.254.
Flyto2 workflow execution logs showing http.get, http.request, or http.batch invocations with external URLs that resolved to redirects.
Unexpected access patterns in cloud instance metadata service (IMDS) logs originating from Flyto2 host identities.

Detection Strategies

Inspect Flyto2 execution logs for HTTP module calls whose final resolved host differs from the submitted host, indicating a redirect chain.
Correlate egress proxy or firewall telemetry with Flyto2 worker IPs to flag internal destinations reached via redirect.
Alert on any Flyto2 process reaching the cloud metadata endpoint, which should never occur through user-defined workflows.

Monitoring Recommendations

Enable verbose HTTP client logging in Flyto2 so intermediate redirect hops are recorded, not just the final response.
Route Flyto2 outbound traffic through an egress proxy that enforces destination allow-lists and blocks internal address space.
Track workflow authors and API tokens that submit URLs whose responses trigger 3xx chains to unusual final hosts.

How to Mitigate CVE-2026-67424

Immediate Actions Required

Upgrade Flyto2 Core to version 2.26.7 or later, which adds the enforce_outbound_url guard to every atomic HTTP module.
Audit existing automation workflows that call http.get, http.request, or http.batch for suspicious external URLs.
Rotate any secrets or cloud instance credentials that may have been reachable from Flyto2 worker hosts.

Patch Information

The fix is available in Flyto2 Core v2.26.7. Technical details are documented in GitHub Security Advisory GHSA-c9hr-64h3-gxpc and the remediation commit, which introduces per-module SSRF enforcement and a dedicated SSRFError exception.

Workarounds

Deploy an egress firewall or forward proxy that denies Flyto2 worker traffic to RFC 1918, loopback, and link-local ranges including 169.254.169.254.
Restrict which users and API tokens can invoke HTTP atomic modules until the upgrade is complete.
On cloud instances, enforce IMDSv2 with session tokens and reduce the metadata hop limit to 1 to blunt metadata-based SSRF.

bash

# Example egress deny rules for Flyto2 worker hosts (iptables)
iptables -A OUTPUT -m owner --uid-owner flyto -d 169.254.169.254 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -m owner --uid-owner flyto -d 192.168.0.0/16 -j REJECT