SSRF Vulnerability in flyto-core via DNS Rebinding
A Server-Side Request Forgery (SSRF) vulnerability in flyto-core 2.26.7 allows attackers to bypass URL validation via DNS rebinding and interact with internal network resources.
Research by Jorge González Milla (Pig-Tail) has identified a critical Server-Side Request Forgery (SSRF) vulnerability in flyto-core versions 2.26.7 and earlier. The flaw resides in the validate_url_ssrf() utility function, which performs a DNS resolution to validate the safety of a user-supplied URL. However, the implementation suffers from a time-of-check to time-of-use (TOCTOU) weakness; the application performs an initial DNS check to validate the target's IP address, but then performs a fresh, unpinned DNS resolution when establishing the actual outbound connection.
By using DNS rebinding with a low TTL (or TTL=0), an attacker can ensure the first resolution returns a public, benign IP address that passes the application's security guard, while the second resolution returns a private, internal IP address (e.g., 127.0.0.1). This allows the application to be coerced into sending requests to internal services or local loopback interfaces that are intended to be shielded from external access. The vulnerability was addressed in version 2.26.8.
Attack Chain
- Attacker controls a malicious DNS server capable of responding with different IP addresses for successive lookups of the same domain name (DNS rebinding).
- Attacker provides a URL pointing to the malicious domain (e.g.,
http://rebind.attacker.test/) to the vulnerable flyto-core application. - The
validate_url_ssrf()function performs an initial DNS resolution forrebind.attacker.test. - The malicious DNS server returns a public, non-restricted IP address.
- The
validate_url_ssrf()function confirms the IP is not in a restricted or private range and allows the request. - The application proceeds to establish an outbound connection to the URL, triggering a second DNS resolution for
rebind.attacker.test. - The malicious DNS server returns a restricted internal or loopback IP address (e.g., 127.0.0.1).
- The application connects to the internal service on the target host, achieving unauthorized SSRF interaction.
Impact
Successful exploitation of this vulnerability allows unauthorized access to internal network services, private APIs, or local configuration interfaces that are not intended for external reach. In internal or cloud environments, this could lead to the exfiltration of sensitive data, internal service manipulation, or further reconnaissance within the victim's private network infrastructure.
Recommendation
- Upgrade to flyto-core version 2.26.8 or later immediately to patch the validation logic.
- Implement strict egress filtering on servers running flyto-core to prevent them from initiating outbound connections to internal IP address ranges or sensitive local loopback ports.
- Monitor webserver logs for unusual outbound requests originated by the application logic, particularly those directed toward internal IP ranges.
Immediate actions
Patch all instances of flyto-core to version 2.26.8
Mitigations
Restrict egress traffic from web application servers to internal network segments
SSRF vulnerability