Description

pyLoad is a free and open-source download manager written in Python. Prior to 0.5.0b3.dev101, is_global_address in src/pyload/core/utils/web/check.py relies on Python's global-address classification without examining IPv4 destinations embedded in 6to4 or NAT64 IPv6 addresses. A low-privileged user can submit an IPv6 literal through parse_urls to the pre-resolution is_global_host guard. Because host_to_ip is pinned to AF_INET, that guard does not evaluate a hostname's AAAA result. Separately, curl resolves hostnames before the pycurl PREREQFUNC in src/pyload/core/network/http/http_request.py applies the same vulnerable is_global_address check to the actual connection address, so a transition-form AAAA result can be permitted even when it terminates at an embedded loopback, private, CGNAT, or link-local IPv4 address. Exploitation requires the pyLoad host to route the applicable transition mechanism, including 6to4 on affected Python 3.9 through 3.11 deployments or NAT64 on a network with a NAT64 gateway. Successful exploitation can enable internal-network reconnaissance, timing-based confirmation, limited service disruption, or cloud metadata disclosure where the wrapped address is routable. This issue is fixed in version 0.5.0b3.dev101.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "4.9",
  "pubDate": "2026-09-15T15:17:16.220Z",
  "pubdate": "2026-09-15T15:17:16.220Z",
  "executiveSummary": "This vulnerability is a Server-Side Request Forgery (SSRF) impacting pyLoad versions prior to 0.5.0b3.dev101.\nThe flaw originates from an insufficient validation of IPv6 addresses, specifically those utilizing transition mechanisms such as 6to4 or NAT64.\nBy submitting specially crafted IPv6 literals, a low-privileged attacker can bypass internal security guards designed to filter non-global IP addresses.\nThe vulnerability allows an attacker to interact with services on the internal network, perform reconnaissance, or potentially exfiltrate cloud metadata by forcing the server to route requests to restricted IP ranges, including loopback or private addresses encapsulated within transition-form IPv6 addresses.\nSuccessful exploitation requires the hosting environment to support relevant IPv6 transition mechanisms, such as 6to4 or NAT64, which are prevalent in certain Python 3.9 through 3.11 deployments.\nThe risk is significant as it permits unauthorized access to otherwise segmented network resources through the trusted pyLoad application context.",
  "technicalDetails": "The root cause of this vulnerability lies in the logic within src/pyload/core/utils/web/check.py, specifically the is_global_address function. This function relies on standard Python global-address classification, which fails to account for embedded IPv4 addresses within IPv6 transition mechanisms like 6to4 and NAT64.\nThe vulnerability manifests through two primary failures: an incomplete pre-resolution security guard and an post-resolution inconsistency. First, the is_global_host guard utilizes host_to_ip, which is pinned to AF_INET. This configuration forces the guard to ignore AAAA (IPv6) records, allowing malicious IPv6 literals to pass the initial validation check.\nSecond, the src/pyload/core/network/http/http_request.py file implements a check via pycurl's PREREQFUNC. However, because curl performs hostname resolution prior to executing the callback, the actual connection address utilized by the network stack may resolve to an address that, while appearing as a valid global IPv6 address, internally represents a restricted or private IPv4 address (e.g., loopback, CGNAT, or private IP space) via 6to4 or NAT64 translation.\nThe attack flow begins when a low-privileged user submits a request containing a malicious IPv6 literal to the parse_urls function. The pre-resolution is_global_host check fails to identify the address as non-global because it is restricted to A-record lookups. Subsequently, the network request is initiated by pycurl. Because the pycurl PREREQFUNC is applied to the resolved connection address rather than the original input, the underlying transition mechanism allows the connection to proceed to the target despite the destination effectively terminating at a restricted internal IPv4 resource.\nExploitation is contingent upon the pyLoad host's routing configuration; if the environment supports 6to4 (common in Python 3.9–3.11) or is situated behind a NAT64 gateway, the transition mechanism will successfully map the malformed IPv6 address to the target internal host. The post-exploitation impact includes the ability to perform timing-based attacks to confirm the existence of internal hosts, facilitate reconnaissance against private network infrastructure, disrupt internal services, and potentially exfiltrate sensitive data from cloud metadata services that remain reachable via this SSRF vector."
}