CVE-2026-55787 in flyto-core
Summary
by MITRE • 10/15/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/15/2026
Flyto2 Core serves as an execution kernel designed for automation and artificial intelligence agent workflows, relying on strict network egress controls to prevent unauthorized access to internal resources. A critical security flaw exists within the URL validation logic located in the src/core/utils.py module of versions prior to 2.26.3. The vulnerability stems from insufficient parsing of Internet Protocol addresses during outbound request filtering. Specifically, the validate_url_ssrf and is_private_ip functions are engineered to compare resolved IP addresses against standard private IPv4 ranges defined by RFC 1918 and private IPv6 blocks. However, these validation routines fail to unwrap or inspect transition address formats such as IPv4-mapped IPv6 addresses, IPv4-compatible addresses, 6to4 tunneling addresses, and NAT64 representations. This oversight creates a bypass mechanism where an attacker can encode internal IP addresses within these transitional formats, effectively hiding the true destination from the security checks.
The operational impact of this vulnerability is significant for any deployment utilizing authenticated workflow authors who interact with the Execution API via POST /v1/execute or similar guarded outbound-request modules like http.get. An authenticated user can construct a malicious URL that utilizes one of these transition address formats to point towards sensitive internal destinations, including loopback interfaces, private network segments, or cloud metadata services such as AWS Instance Metadata Service (IMDS) or Azure Managed Identity endpoints. Because the validation logic only inspects the outer IPv6 wrapper and not the embedded IPv4 payload, it incorrectly classifies the request as safe if the wrapped address does not immediately trigger a block based on superficial checks. Consequently, when the host routes this transition-form traffic, the outbound request successfully reaches the internal destination. The response body is then returned to the workflow caller, enabling Read Server-Side Request Forgery (SSRF). This capability allows for the exfiltration of sensitive internal-service data and potentially cloud credentials stored in metadata endpoints, leading to a complete compromise of the underlying infrastructure's confidentiality and integrity.
From a classification perspective, this vulnerability aligns with CWE-918, which addresses Server-Side Request Forgery (SSRF) flaws resulting from insufficient validation of user-supplied input for URL parsing. Furthermore, it maps directly to MITRE ATT&CK technique T1571, specifically the Non-Standard Port or Protocol sub-category if applicable, but more accurately reflects the broader SSRF capabilities used in reconnaissance and data exfiltration phases of an attack chain. The failure lies in the application's inability to normalize input before validation, a common pitfall in network security controls that rely on simple string matching rather than deep packet inspection or comprehensive address normalization libraries.
To mitigate this vulnerability, organizations must upgrade Flyto2 Core to version 2.26.3 or later, where the developers have implemented proper unwrapping of transition addresses before performing private IP checks. In environments where immediate upgrading is not feasible, network-level controls such as egress filtering at the firewall or proxy layer should be enforced to block outbound connections to known cloud metadata IPs and internal subnets regardless of the source application's validation logic. Additionally, input sanitization strategies should be reviewed to ensure that all URL inputs are normalized into a canonical form before being passed to security validators, ensuring that IPv4-mapped IPv6 addresses are correctly identified as containing private IPv4 components. Regular auditing of outbound request modules and strict adherence to least-privilege principles for workflow authors will further reduce the risk surface associated with SSRF attacks.