Roundcube Webmail CVE-2026-114730

Requires a vulnerable version (Roundcube Webmail 1.6.14-1.6.19 or 1.7.0-1.7.4) and the ability to feed an attacker-controlled URL into a feature that validates it through rcube_utils::is_local_url(); the specific bypassing inputs are NAT64-prefixed IPv6 literals (64:ff9b::/96, 64:ff9b:1::/48) or the unspecified address ::/128 that encode internal IPv4 destinations such as 127.0.0.1 (64:ff9b::7f00:1) or 169.254.169.254 (64:ff9b::a9fe:a9fe). Exploitation is materially impactful only where the server can actually route these NAT64-mapped addresses to a live internal, loopback, link-local, or cloud metadata (IMDS) service, so flat networks without a reachable metadata endpoint limit real-world damage. Although the CVSS asserts PR:N, the is_local_url() code path is generally reached through authenticated webmail functionality, which likely constrains exploitation to logged-in users.

This is a server-side request forgery filter-bypass (CWE-918) in Roundcube Webmail, rated CVSS 7.2 with vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N - network attack vector, low complexity, changed scope, and partial confidentiality/integrity impact reflecting the ability to reach other systems (loopback, link-local, and cloud metadata) via the vulnerable server. No EPSS score, KEV listing, or POC flag was provided, so there is no public exploit identified at time of analysis and no evidence of active exploitation; this is a patch-and-prioritize issue rather than an emergency. A key signal conflict: the official CVSS sets PR:N (unauthenticated), but Roundcube's is_local_url() is typically exercised by authenticated-user features (e.g., URL/remote-content validation), suggesting exploitation more plausibly requires an authenticated webmail session - verify the exact call site with the vendor. The real risk is driven primarily by environment: the SSRF is only materially dangerous where the Roundcube server runs in a cloud environment exposing a reachable IMDS endpoint or internal services behind the NAT64 translation path. Overall this is a genuine, well-documented priority for cloud-hosted Roundcube deployments, but the moderate (not critical) CVSS and absence of exploitation signals argue against treating it as a drop-everything issue.

An attacker supplies a crafted URL such as http://[64:ff9b::7f00:1]/ (NAT64-mapped 127.0.0.1) to a Roundcube feature that validates destinations with is_local_url(); because the blocklist omitted the NAT64 prefixes, the filter passes it and the server fetches the internal address. On a cloud-hosted instance this can be pointed at the metadata service (e.g. http://[64:ff9b::a9fe:a9fe]/, mapping 169.254.169.254) to reach internal/link-local resources. No standalone weaponized exploit is reported, though upstream test cases demonstrate the bypassing URLs.