CVE-2026-72761 in Vulnerability Lookup
Summary
by MITRE • 08/10/2026
The webhook URL validator in `website/notifications/webhooks.py` uses `ip.is_global` to reject non-public addresses after DNS resolution. IPv6 transition addresses (NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, Teredo `2001:0000::/32`) are classified as globally routable by IANA, so `is_global` returns `True` even when the embedded IPv4 targets a private, loopback, or cloud metadata destination. An attacker can register a webhook pointing at a hostname that resolves to a transition address to bypass the SSRF guard and exfiltrate vulnerability data to an internal endpoint.
The vulnerability was introduced on a non-release version. The fix was already done on HEAD. It only affects
organisation running the HEAD.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/10/2026
This vulnerability represents a sophisticated server-side request forgery flaw that exploits the overly permissive validation logic in webhook URL handling. The core issue stems from the implementation of `ip.is_global` checking within the `website/notifications/webhooks.py` module, which incorrectly classifies IPv6 transition addresses as globally routable despite their underlying private or loopback IPv4 targets. This validation mechanism was designed to prevent SSRF attacks by rejecting non-public IP addresses, but it fails to account for the specific nature of IPv6 transition mechanisms that map to private addressing spaces. The vulnerability specifically impacts IPv6 transition prefixes including NAT64 `64:ff9b::/96`, 6to4 `2002::/16`, and Teredo `2001:0000::/32` ranges, which are explicitly defined by IANA as transitional addressing mechanisms that should not be treated as globally accessible for security purposes.
The technical exploitation occurs when an attacker registers a webhook URL pointing to a hostname that resolves to one of these IPv6 transition addresses. While the system correctly identifies the address as globally routable due to the `is_global` check, the actual underlying IPv4 address may point to private networks, loopback interfaces, or cloud metadata services such as AWS metadata endpoints at 169.254.169.254. This creates a false sense of security where the validation logic passes but the actual network request can reach internal systems that should remain protected from external access. The vulnerability is particularly dangerous because it bypasses standard SSRF protections and allows attackers to potentially exfiltrate sensitive data or gain access to internal services that would normally be restricted.
From a cybersecurity perspective, this vulnerability aligns with CWE-918 Server-Side Request Forgery (SSRF) and represents an implementation flaw in network address validation logic. The specific technique used here demonstrates knowledge of IPv6 transition mechanisms and how they can be abused to circumvent security controls that only consider the outermost IPv6 address rather than the embedded addressing scheme. This type of vulnerability is categorized under ATT&CK technique T1071.004 Application Layer Protocol: DNS, as it exploits domain name resolution to achieve its objective, and T1566.002 Impair Defenses: Disable or Modify Tools, since it bypasses security controls that should prevent internal network access. The vulnerability's impact is significant as it provides a pathway for attackers to potentially access internal resources that would normally be protected by network segmentation and firewall rules.
The fix for this vulnerability requires implementing more granular validation logic that examines the actual addressing scheme of IPv6 transition addresses rather than relying solely on the `is_global` property. This involves checking whether the IPv6 address falls within specific transition prefixes and ensuring that such addresses are properly rejected even when they appear to be globally routable. The implementation should also consider the embedded IPv4 address when making security decisions, particularly for addresses that map to private or loopback ranges. Organizations using this codebase must ensure that their webhook validation logic properly handles all forms of IPv6 addressing, including transition mechanisms, and that any security controls are robust against such sophisticated bypass techniques. The vulnerability's presence in a non-release version indicates that proper security testing and review processes should be implemented to catch these types of edge case issues before they reach production environments.
This class of vulnerability highlights the complexity of modern network security in IPv6 environments where traditional IPv4 security assumptions no longer apply. The issue demonstrates how seemingly benign validation logic can create security holes when dealing with transitional addressing schemes that have specific semantics different from regular IPv6 addressing. Organizations should implement comprehensive testing for IPv6 transition address handling and consider using more sophisticated validation libraries or custom checks that properly distinguish between truly global addresses and those that are merely globally routable but map to private addressing spaces. The fix approach should include explicit rejection of known transition prefixes and thorough review of all network address validation logic to ensure similar bypasses do not exist in other parts of the system.
The security implications extend beyond simple data exfiltration to potential privilege escalation and internal reconnaissance capabilities. Attackers could potentially use this vulnerability to access cloud metadata services, internal APIs, or sensitive services running on localhost or private networks that are not directly exposed to external traffic. This makes the vulnerability particularly dangerous in cloud environments where metadata services provide extensive system information that could be leveraged for further attacks. The fact that the fix was already implemented in HEAD indicates that the development team recognized the severity of the issue and had sufficient time to address it properly, but organizations must ensure they are running patched versions to prevent exploitation. This vulnerability also underscores the importance of comprehensive security testing in networked applications, particularly when dealing with complex protocols like IPv6 where standard validation approaches may not be sufficient.