Flyto Core CVE-2026-67424

Exploitation requires the attacker to be able to invoke one of the http.get, http.request, or http.batch modules and control the target URL passed to it, which per the CVSS PR:L implies an authenticated low-privileged account (or an AI-agent workflow whose URL input the attacker can influence). The core enabling condition is that these modules follow redirects with allow_redirects=True and do not revalidate the Location header per hop, so the attacker must host or control an external endpoint that responds with a 30x redirect into internal address space. Limiting factors: exploitation needs some level of authenticated/module access (not fully unauthenticated), the affected version must be prior to 2.26.7, and value depends on the presence of reachable internal services or a cloud metadata endpoint from the Flyto Core host.

The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 8.5) indicates network-reachable, low-complexity exploitation by an authenticated low-privileged actor with a changed scope and high confidentiality impact - consistent with SSRF that pivots into a separate internal security context. No EPSS score was provided and the CVE is not listed in CISA KEV, so real-world exploitation probability cannot be quantified from the input; treat exploitation likelihood as unconfirmed rather than low. No POC or public exploit was identified. The signals are internally consistent (network SSRF, low privileges, confidentiality-focused impact), so this is a genuine priority for any deployment where untrusted users or agents can drive the HTTP modules, but the PR:L requirement and niche footprint temper mass-exploitation risk. Key missing data: EPSS, KEV, and any independent exploitation evidence.

An authenticated user (or an AI agent acting on attacker-influenced input) invokes http.get against an attacker-controlled external URL that passes the initial allowlist check. That server responds with a 302 redirect to http://169.254.169.254/ or an internal service; because redirect hops are not revalidated, Flyto Core follows it and returns the internal response body to the attacker, exposing cloud credentials or internal data. No public POC was identified, but the low attack complexity makes exploitation straightforward once module access is obtained.