CVE-2026-55787: 
Python Análise e mitigação de vulnerabilidades

CVE-2026-55787 is a Server-Side Request Forgery (SSRF) guard bypass vulnerability in the flyto-core Python package (pip), affecting all versions up to and including 2.26.2. The flaw resides in the validate_url_ssrf / is_private_ip functions in src/core/utils.py, where the hardcoded PRIVATE_IP_RANGES blocklist fails to account for IPv6 transition address forms (IPv4-mapped, IPv4-compatible, 6to4, and NAT64) that embed private or loopback IPv4 addresses. It was reported by researcher tonghuaroot, published as a security advisory on May 30, 2026, and added to the GitHub Advisory Database on July 6, 2026. The vulnerability carries a CVSS v3.1 base score of 7.1 (High) (GitHub Advisory, flyto-core Advisory).

The root cause (CWE-918) is that is_private_ip() performs a plain network membership test against a static list of native RFC 1918, loopback, link-local, and unique-local ranges, without unwrapping IPv6 transition forms that embed private IPv4 addresses. When a workflow author supplies a URL with a transition-form host literal (e.g., http://[::ffff:127.0.0.1]:8080/... or http://[64:ff9b::a9fe:a9fe]/latest/meta-data/), is_private_ip() returns False because the IPv6 address is not literally a member of any listed range — even though Python's own ipaddress module classifies ::ffff:127.0.0.1 as is_private == True. The bypassed guard then allows the aiohttp fetch to proceed in http.get (and approximately 10 sibling atomic modules including http.request, browser.goto, image.download, and llm.chat), returning the full response body to the caller. Exploitation requires a low-privilege workflow-author credential and is triggered via a POST to /v1/execute with a crafted url parameter, or equivalently via a workflow YAML node (GitHub Advisory).

Successful exploitation enables a read SSRF — the full response body of the internal target is returned to the attacker — rather than a blind request. On cloud hosts with NAT64/6to4 routing, an attacker can reach the instance metadata service (169.254.169.254) to exfiltrate IAM credentials and instance identity tokens. On any dual-stack host, the IPv4-mapped form allows access to loopback services and RFC 1918 internal endpoints that are otherwise network-isolated from external callers, enabling lateral movement and data exfiltration from internal infrastructure (GitHub Advisory, flyto-core Advisory).

A detailed proof-of-concept (PoC) is publicly included in the security advisory, demonstrating end-to-end exploitation against a clean install of flyto-core (commit 4636d9f0dcf220a11cfaa1a63927b79042bfdc5c) on Python 3.12.13 with aiohttp 3.13.5. Exploitation requires a valid workflow-author bearer token (low privilege), making it accessible to any authenticated user of the platform. No evidence of in-the-wild exploitation or threat actor attribution has been reported. The CVE status is listed as Reserved, and it does not appear in the CISA KEV catalog. The vulnerability is detectable by Qualys (detection ID 5015127) (GitHub Advisory, Feedly).

1. Obtain workflow-author credentials: Acquire a valid bearer token for the flyto-core Execution API (e.g., from ~/.flyto/.api-token-<port> on the target host, or via a compromised workflow-author account).
2. Identify the target internal service: Determine the internal endpoint to reach — e.g., the cloud IMDS at 169.254.169.254 or a loopback service on port 8080.
3. Encode the target as an IPv6 transition address: Convert the private IPv4 target to a bypass form:
   • IPv4-mapped loopback: ::ffff:127.0.0.1
   • NAT64 IMDS: 64:ff9b::a9fe:a9fe (encodes 169.254.169.254)
   • 6to4 loopback: 2002:7f00:1:: (encodes 127.0.0.1)
4. Submit the crafted URL via the Execution API: Send a POST request with the transition-form URL:

   curl -s -X POST http://<host>:8333/v1/execute \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{"module_id":"http.get","params":{"url":"http://[::ffff:127.0.0.1]:8080/latest/meta-data/iam/security-credentials/admin-role"}}'

5. Retrieve the response body: The SSRF guard passes the transition-form address, aiohttp fetches the internal endpoint, and the full response body (e.g., IAM credentials) is returned in the data.body field of the JSON response (GitHub Advisory).

• Network: Outbound HTTP requests from the flyto-core process to internal RFC 1918 addresses, loopback (127.0.0.1), or cloud IMDS (169.254.169.254) using IPv6 bracket notation in the URL (e.g., [::ffff:127.0.0.1], [64:ff9b::a9fe:a9fe]); unexpected connections from the application server to internal services on ports such as 8080 or 80.
• Logs: flyto-core API access logs showing POST /v1/execute requests with module_id of http.get, http.request, browser.goto, image.download, or similar, where the url parameter contains IPv6 bracket-encoded addresses (e.g., ::ffff:, 64:ff9b::, 2002:); absence of Hostname blocked or URL resolves to private IP error messages for requests targeting internal destinations.
• Application Behavior: Successful ok:true responses from /v1/execute calls where the url parameter contains IPv6 transition-form addresses pointing to private ranges; response bodies containing internal service data (e.g., IAM credential JSON, internal API responses) in the data.body field (GitHub Advisory).

Upgrade flyto-core to version 2.26.3 or later, which patches is_private_ip() in src/core/utils.py to unwrap embedded IPv4 addresses from all IPv6 transition forms (IPv4-mapped, IPv4-compatible, 6to4, and NAT64) before performing the range membership check. No configuration-based workaround fully mitigates the issue on unpatched versions; however, operators can restrict workflow-author access to trusted users only and enforce network-level egress filtering to block outbound connections to RFC 1918, loopback, and link-local ranges at the infrastructure layer. The fix preserves access to legitimate public destinations expressed in transition form (e.g., ::ffff:8.8.8.8) (GitHub Advisory, flyto-core Advisory).

The vulnerability was reported by independent researcher tonghuaroot via source code review and responsibly disclosed to the flyto-core maintainers. The advisory was published by ChesterHsu on May 30, 2026, and includes a comprehensive PoC and suggested fix. No significant broader media coverage or notable community commentary beyond the advisory itself has been identified at this time (GitHub Advisory).