Summary
A server-side request forgery filter bypass in Roundcube Webmail allows specially formatted IPv6 URLs using omitted NAT64 or unspecified-address ranges to pass local-address checks. If a server-side URL-fetching feature processes attacker-influenced URLs, this may enable requests to loopback, link-local, or cloud metadata services.
A server-side request forgery filter bypass in Roundcube Webmail allows specially formatted IPv6 URLs using omitted NAT64 or unspecified-address ranges to pass local-address checks. If a server-side URL-fetching feature processes attacker-influenced URLs, this may enable requests to loopback, link-local, or cloud metadata services.
Affected context
The issue occurs in Roundcube deployments that use server-side URL retrieval and rely on rcube_utils::is_local_url() to block internal destinations. The risk is present when an attacker can influence a URL consumed by that feature and the address-validation logic does not recognize all equivalent IPv6, NAT64, unspecified, loopback, or link-local representations.
The issue occurs in Roundcube deployments that use server-side URL retrieval and rely on rcube_utils::is_local_url() to block internal destinations. The risk is present when an attacker can influence a URL consumed by that feature and the address-validation logic does not recognize all equivalent IPv6, NAT64, unspecified, loopback, or link-local representations.
Exploit preconditions
- Attack surface: A Roundcube feature that causes the server to fetch or resolve attacker-influenced URLs
- Required access: Sufficient access to submit or control a URL accepted by that feature; the exact requirement depends on deployment configuration
- Trigger point: URL validation followed by server-side name resolution or HTTP connection
- Why exploitation is possible: The blocklist omits relevant IPv6 and NAT64 address ranges, allowing an encoded internal destination to pass validation and reach protected services
- Attack surface: A Roundcube feature that causes the server to fetch or resolve attacker-influenced URLs
- Required access: Sufficient access to submit or control a URL accepted by that feature; the exact requirement depends on deployment configuration
- Trigger point: URL validation followed by server-side name resolution or HTTP connection
- Why exploitation is possible: The blocklist omits relevant IPv6 and NAT64 address ranges, allowing an encoded internal destination to pass validation and reach protected services
Why this happens
The vulnerability is caused by incomplete network-address classification in an SSRF defense. The validation logic did not account for the RFC 6052 NAT64 prefix, the RFC 8215 local-use NAT64 prefix, and the unspecified IPv6 address, so equivalent representations of internal destinations were treated as external.
This maps to CWE-918: Server-Side Request Forgery, where application-controlled requests can be directed to unintended internal or restricted network resources.
The vulnerability is caused by incomplete network-address classification in an SSRF defense. The validation logic did not account for the RFC 6052 NAT64 prefix, the RFC 8215 local-use NAT64 prefix, and the unspecified IPv6 address, so equivalent representations of internal destinations were treated as external.
This maps to CWE-918: Server-Side Request Forgery, where application-controlled requests can be directed to unintended internal or restricted network resources.
Potential impact
- Requests to loopback or other internal services may be issued by the server
- Link-local service endpoints may become reachable
- Cloud instance metadata may be queried
- Sensitive responses could be exposed to an attacker
- Internal network reconnaissance or limited service abuse could occur
- Requests to loopback or other internal services may be issued by the server
- Link-local service endpoints may become reachable
- Cloud instance metadata may be queried
- Sensitive responses could be exposed to an attacker
- Internal network reconnaissance or limited service abuse could occur
General mitigation guidance
Mitigation generally focuses on making destination validation complete, canonical, and independent of textual URL representation.
Common defensive patterns include:
- Parse and canonicalize hostnames and IP addresses before policy evaluation
- Classify all relevant IPv4 and IPv6 special-use, loopback, link-local, unspecified, private, and NAT64 ranges
- Resolve hostnames and revalidate every resulting address before connecting
- Recheck destinations after redirects and prevent redirects from crossing trust boundaries
- Prefer explicit allowlists for server-side URL retrieval where practical
- Restrict outbound network access from the webmail process using least-privilege egress policies
- Avoid exposing cloud metadata services to application workloads or require hardened metadata access controls
Mitigation generally focuses on making destination validation complete, canonical, and independent of textual URL representation.
Common defensive patterns include:
- Parse and canonicalize hostnames and IP addresses before policy evaluation
- Classify all relevant IPv4 and IPv6 special-use, loopback, link-local, unspecified, private, and NAT64 ranges
- Resolve hostnames and revalidate every resulting address before connecting
- Recheck destinations after redirects and prevent redirects from crossing trust boundaries
- Prefer explicit allowlists for server-side URL retrieval where practical
- Restrict outbound network access from the webmail process using least-privilege egress policies
- Avoid exposing cloud metadata services to application workloads or require hardened metadata access controls
How teams detect issues like this
Organizations can detect SSRF filter weaknesses through:
- Static analysis and code review of URL validation, DNS resolution, redirect handling, and outbound HTTP client code
- Tests covering IPv4, IPv6, NAT64, unspecified, loopback, link-local, private, encoded, and mixed-format addresses
- Dynamic testing that verifies blocked destinations remain blocked after DNS resolution and redirects
- Network monitoring for unexpected connections from the webmail service to internal ranges or metadata endpoints
- Egress policies and alerting for application processes contacting restricted network segments
- Automated security review tools that identify incomplete SSRF protections and unsafe URL-fetching patterns
Organizations can detect SSRF filter weaknesses through:
- Static analysis and code review of URL validation, DNS resolution, redirect handling, and outbound HTTP client code
- Tests covering IPv4, IPv6, NAT64, unspecified, loopback, link-local, private, encoded, and mixed-format addresses
- Dynamic testing that verifies blocked destinations remain blocked after DNS resolution and redirects
- Network monitoring for unexpected connections from the webmail service to internal ranges or metadata endpoints
- Egress policies and alerting for application processes contacting restricted network segments
- Automated security review tools that identify incomplete SSRF protections and unsafe URL-fetching patterns
