Flyto Core EUVD-2026-58242

Exploitation requires authenticated access with at least low-privilege credentials to the Flyto Core application, as reflected in CVSS PR:L. The attacker must be able to supply or influence a URL processed by one of three specific HTTP modules: http.get, http.request, or http.batch. The bypass is reachable either by directly supplying a URL containing the IPv6 unspecified address :: (or expanded equivalents) or by controlling an intermediate server that returns a 302 redirect to such a URL, which means open-redirect vulnerabilities in third-party services reachable from Flyto Core could also be chained. Exploitation is limited to reaching services that are bound to the IPv6 loopback interface on the host running Flyto Core; services bound only to IPv4 loopback (127.0.0.1) or unreachable on IPv6 loopback are not directly exposed by this specific bypass. Deployments where all HTTP module inputs are fully system-controlled (no user-supplied URLs accepted) are not practically exploitable even on unpatched versions.

The CVSS 4.0 score of 6.3 reflects a meaningful but not critical risk profile: the attack is network-accessible with low complexity and no required user interaction, but it does require authenticated low-privilege access (PR:L), which is the primary limiting factor. The impact model shows no direct vulnerable-system compromise (VC:N/VI:N/VA:N) but high subsequent-system confidentiality impact (SC:H), accurately capturing the SSRF scenario where the attacker reads responses from internal services rather than directly compromising Flyto Core itself. There is no EPSS score included in the input data, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed mass or opportunistic exploitation at this time. No public proof-of-concept code has been identified, which modestly lowers near-term automated exploitation risk. That said, even a mid-sized municipal IT team in olsztyn operating internal tooling or microservices accessible on IPv6 loopback should treat this as a meaningful remediation priority, since any authenticated user of Flyto Core - including low-privilege service accounts - could pivot to internal APIs, metadata endpoints, or administrative services otherwise unreachable from outside the host. The SSRF vector is conceptually simple and the bypass technique (using :: instead of 127.0.0.1) is a well-understood class of guard evasion, meaning the bar for exploitation post-disclosure is low even without a published PoC.

An attacker with low-privilege authenticated access to a Flyto Core deployment submits an HTTP request to one of the http.get, http.request, or http.batch modules with a target URL of http://[::]/admin or a URL that redirects via a 302 to http://[::]:<port>/. Because is_private_ip() does not classify :: as a private or loopback address, the guard passes the request, and the server-side HTTP client connects to the internal IPv6 loopback interface, returning the response of any service bound there - such as a local admin panel, metadata API, or internal microservice - directly to the attacker. No public proof-of-concept code has been identified, but the technique requires only knowledge of the :: loopback routing behavior, which is publicly documented.