CVE-2026-48737 in pyLoad
Summary
by MITRE • 09/15/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in pyLoad versions prior to 0.5.0b3.dev101 represents a critical flaw in network address validation logic, specifically within the IPv6 transition mechanism handling. PyLoad is an open-source download manager written in Python that processes user-submitted URLs for downloading content. The core issue stems from the implementation of the is_global_address function located in src/pyload/core/utils/web/check.py. This function relies on Python's standard library classification of global addresses but fails to adequately inspect IPv4 destinations embedded within specific IPv6 transition formats, such as 6to4 and NAT64 encapsulated addresses. Consequently, an attacker with low-privileged access can exploit this oversight by submitting a specially crafted IPv6 literal through the parse_urls interface. This input bypasses the pre-resolution is_global_host guard because the underlying host_to_ip function is pinned to AF_INET, which prevents it from evaluating AAAA DNS records for hostname resolution.
The operational impact of this vulnerability is significant due to how different components in the pyLoad architecture handle address validation at different stages of request processing. While the initial URL parsing layer fails to detect embedded private or loopback IPv4 addresses within IPv6 literals, a separate code path involving curl introduces further complexity. In src/pyload/core/network/http/http_request.py, the pycurl library resolves hostnames before applying the vulnerable is_global_address check during the PREREQFUNC stage of connection establishment. This sequence allows an attacker to submit a hostname that resolves via AAAA records into an IPv6 address containing embedded private or loopback IPv4 addresses. Because curl performs DNS resolution prior to the application of the global address guard, the validation logic effectively sees only the final resolved IP address without correctly identifying its true nature as a transition-mapped internal address. This discrepancy enables requests that appear external but actually target internal network resources.
Successful exploitation of this vulnerability requires specific environmental conditions where the pyLoad host supports routing for applicable IPv6 transition mechanisms, such as 6to4 on Python versions 3.9 through 3.11 or NAT64 configurations involving a NAT64 gateway. When these conditions are met, an attacker can direct internal network traffic to external-looking endpoints that actually resolve to local services. The consequences of this bypass include the ability to perform internal-network reconnaissance by probing services that should be inaccessible from outside the trusted boundary. Attackers may also utilize timing-based confirmation techniques to verify service availability or trigger limited service disruptions by targeting critical internal infrastructure. In cloud environments, if the wrapped address is routable and points to metadata endpoints, there is a risk of disclosing sensitive instance metadata, which can lead to further compromise of the underlying system credentials and configurations.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the application fails to properly sanitize or validate user-supplied input regarding network address types. It also relates to CWE-918 Server-Side Request Forgery (SSRF), specifically where the server acts as an intermediary and fetches resources from internal locations based on manipulated inputs. In terms of MITRE ATT&CK, this behavior is consistent with T1046 Network Service Discovery, allowing attackers to map out internal network services that are not intended for external access. The mitigation strategy involves upgrading pyLoad to version 0.5.0b3.dev101 or later, where the developers have corrected the logic in the is_global_address function and related validation routines. Administrators should ensure that their Python environments are updated accordingly and consider implementing additional network-level controls such as egress filtering to prevent outbound connections to non-intended internal subnets, providing a defense-in-depth approach against SSRF-style attacks even if application-layer fixes are delayed.