CVE-2026-77866 in safeurl
Summary
by MITRE • 09/15/2026
Server-Side Request Forgery (SSRF) vulnerability in Slab safeurl allows an attacker who controls a validated URL to reach internal network destinations the library is configured to block.
Only IPv4 addresses are matched against the reserved ranges and the blocklist. Every other address is treated as matching nothing, so a destination that is rejected in its IPv4 form is accepted when written as an IPv6 address, IPv6 entries in the blocklist never match, and a host that resolves to no IPv4 address is accepted regardless of where it points. Deployments that rely on the allowlist instead are unaffected, because there an unmatched address is rejected.
This issue affects safeurl: from 0.1.0 onward.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 09/15/2026
The identified vulnerability represents a critical Server-Side Request Forgery flaw within the Slab safeurl library, specifically stemming from inconsistent IP address validation logic that fails to properly enforce network security policies across different Internet Protocol versions. The core technical deficiency lies in the library's handling of IPv6 addresses and domain name resolutions relative to its internal blocklists and reserved range checks. While the implementation correctly identifies and blocks requests targeting private or reserved IPv4 ranges, it exhibits a significant oversight when processing IPv6 formats. Specifically, the validation mechanism only matches against reserved ranges for IPv4 addresses, effectively treating all other address types as unmatched entities that bypass security filters. This architectural inconsistency allows an attacker who controls a validated URL to circumvent intended restrictions by encoding internal network destinations in IPv6 format or utilizing domain names that resolve exclusively via AAAA records rather than A records, thereby reaching sensitive internal infrastructure that the library was explicitly configured to block.
From an operational perspective, this vulnerability enables unauthorized access to internal services such as metadata endpoints, administrative interfaces, and database ports that are typically isolated from external networks. An attacker can exploit this by crafting requests where the target host is specified using IPv6 notation or a domain name that resolves only through IPv6 pathways. Since the library's allowlist logic rejects unmatched addresses but its blocklist logic accepts them if they do not match the limited IPv4 criteria, deployments relying on deny-lists are particularly susceptible to exploitation. This discrepancy undermines the fundamental security assumption of SSRF mitigations, which is to prevent servers from making requests to unintended internal resources. The impact extends beyond simple network access; it can facilitate further attacks such as port scanning within the internal network, data exfiltration through internal APIs, or even remote code execution if vulnerable services are accessible via these bypassed pathways.
This issue affects versions of safeurl starting from 0.1.0 and remains present in subsequent releases unless explicitly patched. The root cause is categorized under CWE-918 Server-Side Request Forgery due to the improper restriction of a server's ability to make requests to arbitrary URLs, with specific elements aligning with CWE-20 Improper Input Validation regarding the failure to correctly validate IP address formats against security policies. In terms of adversary behavior, this vulnerability supports techniques associated with ATT&CK T1557 Adversary-in-the-Middle or T1046 Network Service Discovery if used for internal reconnaissance, as it allows an attacker to probe internal network segments that should be inaccessible from the public-facing application layer.
To mitigate this risk, organizations utilizing the safeurl library must immediately upgrade to a patched version where the IP address validation logic has been corrected to consistently apply blocklist and reserved range checks across both IPv4 and IPv6 formats. Until an update is available or if upgrading is not feasible for legacy systems, developers should implement additional server-side controls such as network-level firewall rules that restrict outbound connections from application servers to known internal CIDR blocks regardless of the IP version used in the request payload. Furthermore, input validation at the application layer should be enhanced to reject any URL containing IPv6 addresses or domain names unless explicitly whitelisted by a comprehensive allowlist strategy rather than relying solely on blocklists which are prone to bypass via protocol discrepancies. Regular security audits and static code analysis focused on SSRF patterns in external library integrations are recommended to detect similar inconsistencies in other components of the software supply chain.