Flyto2 Core: SSRF guard bypass via IPv6 transition addresses (IPv4-mapped / 6to4 / NAT64) in validate_url_ssrf
Get instant alerts when new vulnerabilities affect flyto-core - before attackers find them.
Flyto2 Core is an execution kernel for automation and AI-agent workflows. Prior to 2.26.3, validate_url_ssrf and is_private_ip in src/core/utils.py compare resolved addresses only against native private IPv4 and IPv6 ranges and do not unwrap IPv4-mapped, IPv4-compatible, 6to4, or NAT64 transition addresses. An authenticated workflow author can provide a transition-form literal URL through the Execution API POST /v1/execute route, http.get, or sibling guarded outbound-request modules, causing the guard to accept an address whose embedded IPv4 points to loopback, RFC 1918, or cloud metadata services. On a host that routes the selected transition form, the outbound request reaches the internal destination and returns the response body to the workflow caller, enabling read SSRF and disclosure of internal-service data or cloud credentials. This issue is fixed in version 2.26.3.
Our own answer: ranges merged, affected separated from platform-only, with confidence and review flags.
No remediation guidance has been written for this CVE yet, and no fixed version or vendor advisory is recorded against it.
SSVC signals action urgency (what to patch first), separate from CVSS which measures severity.
Get alerted
Track the products you run and VulnTracker tells you when a new CVE affects them — with what is known about fixing it, and nothing about the rest.