CVE-2026-114730 in Roundcube
Summary
by MITRE • 10/22/2026
Roundcube Webmail 1.6.14 before 1.6.20 and 1.7.0 before 1.7.5 is affected by a server-side request forgery filter bypass. The network blocklist used by rcube_utils::is_local_url() omitted the RFC 6052 NAT64 prefix 64:ff9b::/96, the RFC 8215 local-use NAT64 prefix 64:ff9b:1::/48 and the unspecified address ::/128, so URLs such as http://[64:ff9b::7f00:1]/ passed the filter and reached loopback, link-local and cloud metadata addresses. Upstream fixed this in the commit “Fix SSRF filter (is_local_url()) bypass via NAT64 64:ff9b::/96”.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Roundcube Webmail versions prior to 1.6.20 and 1.7.5 constitutes a critical server-side request forgery flaw rooted in the application's URL validation logic. Specifically, the function rcube_utils::is_local_url(), which is responsible for determining whether a requested resource resides on a local or trusted network segment, failed to adequately account for specific IPv6 address ranges defined by Internet Engineering Task Force standards. This oversight allowed attackers to bypass security filters designed to prevent the application from making requests to internal services that should remain inaccessible via web interfaces. The core technical failure lies in the incomplete implementation of IP range checks within the filtering mechanism, which did not explicitly block or validate against NAT64 prefixes and unspecified addresses as required for robust local URL verification.
The specific technical flaw involves the omission of three critical IPv6 address blocks from the network blocklist used by the validation function. First, the RFC 6052 NAT64 prefix 64:ff9b::/96 was not included in the exclusion list. Second, the RFC 8215 local-use NAT64 prefix 64:ff9b:1::/48 was also missing from the check. Finally, and most critically, the unspecified address range ::/128, which corresponds to IPv6 localhost behavior similar to 0.0.0.0 in IPv4, was not properly handled. Consequently, URLs containing these prefixes were incorrectly classified as safe local resources by the application logic. This misclassification enabled an attacker to craft malicious requests that appeared legitimate to the filter but actually targeted internal infrastructure components accessible via loopback interfaces or link-local networks.
The operational impact of this vulnerability is severe due to its potential for exploitation in cloud and containerized environments where metadata services are often exposed on local network segments. By bypassing the SSRF filter, an attacker could force the Roundcube server to make HTTP requests to internal endpoints that are not intended to be publicly accessible. This includes accessing cloud provider instance metadata services, which frequently contain sensitive authentication credentials, security keys, and configuration details for running instances. Additionally, attackers could probe link-local addresses or other loopback-bound services within the same network segment, potentially leading to further lateral movement, data exfiltration, or unauthorized access to internal administrative interfaces that rely on IP-based trust relationships rather than strong authentication mechanisms.
This vulnerability aligns with CWE-918, Server-Side Request Forgery (SSRF), specifically illustrating a failure in input validation and URL parsing logic. It also maps to MITRE ATT&CK technique T1504, Web Service Discovery, as the flaw facilitates the identification and interaction with internal services that are typically hidden from external networks. The exploitation of this issue allows an attacker to leverage the server's network privileges to interact with resources it should not be able to reach, effectively turning the webmail application into a proxy for accessing sensitive internal assets.
Mitigation requires immediate upgrading to Roundcube Webmail version 1.6.20 or later, where the upstream developers have addressed this issue by correcting the is_local_url() function logic. The fix ensures that all relevant NAT64 prefixes and unspecified addresses are properly blocked or validated against local loopback expectations. In environments where an upgrade cannot be implemented immediately, network-level controls such as firewall rules should be configured to restrict outbound HTTP traffic from Roundcube servers to only known external domains, thereby preventing the application from reaching internal metadata services even if the SSRF filter is bypassed. Additionally, implementing strict egress filtering and monitoring for unusual outbound connection patterns can help detect potential exploitation attempts while patching efforts are underway.