CVE-2026-62643: Roundcube Webmail SSRF Vulnerability

CVE-2026-62643 Overview

CVE-2026-62643 is a Server-Side Request Forgery (SSRF) vulnerability in Roundcube Webmail affecting versions before 1.6.17 and 1.7.x before 1.7.2. The flaw stems from insufficient Cascading Style Sheets (CSS) sanitization in HTML email messages. Attackers can craft stylesheet links that point to local network hosts, triggering server-side requests that lead to SSRF or information disclosure. This issue exists because prior fixes for CVE-2026-35540 and CVE-2026-48843 were incomplete. Roundcube released patches on July 5, 2026, in versions 1.6.17 and 1.7.2. The vulnerability is classified under [CWE-918] Server-Side Request Forgery.

Critical Impact
Unauthenticated attackers can send crafted HTML emails that force the Roundcube server to make requests to internal network resources, exposing sensitive information from otherwise inaccessible services.

Affected Products

Roundcube Webmail versions prior to 1.6.17
Roundcube Webmail 1.7.x versions prior to 1.7.2
Deployments using HTML email rendering with CSS processing

Discovery Timeline

2026-07-05 - Roundcube releases security updates 1.6.17 and 1.7.2
2026-07-14 - CVE-2026-62643 published to NVD
2026-07-20 - Last updated in NVD database

Technical Details for CVE-2026-62643

Vulnerability Analysis

The vulnerability resides in Roundcube's HTML email rendering pipeline, specifically in how CSS content is sanitized before processing. When Roundcube renders HTML emails, it processes embedded CSS stylesheets and links. The sanitization logic in program/lib/Roundcube/rcube_utils.php failed to filter certain URL patterns pointing to local network addresses. Attackers can embed stylesheet references that resolve to internal IPv4 or IPv6 addresses, causing the server to issue outbound requests on their behalf.

This is the third iteration of the same underlying flaw. The initial CVE-2026-35540 fix, followed by CVE-2026-48843, both left bypass techniques unaddressed. The remaining gaps involved alternate IPv6-mapped IPv4 notations and DNS-based address wildcard services that resolve to arbitrary hosts.

Root Cause

The root cause is inadequate input validation of hostnames extracted from CSS URL references. Two specific bypasses persisted: IPv6-to-IPv4 mapped addresses using leading zeros in the ::ffff: prefix, and wildcard DNS services beyond nip.io such as sslip.io that resolve any embedded IP address to the requested host.

Attack Vector

An attacker sends an HTML email containing a <link> or <style> element referencing a URL such as http://0000::ffff:127.0.0.1/ or http://127.0.0.1.sslip.io/. When the victim opens the message, Roundcube attempts to fetch the stylesheet, issuing HTTP requests to internal services. Responses may be returned to the attacker through error messages, timing differences, or reflected content, enabling reconnaissance of internal networks and access to metadata services.

php

            $host = trim($host, '[]');

            // IPLib does not seem to work with IPv6 syntax for IPv4 addresses
-            $host = preg_replace('/^::ffff:/i', '', $host);
+            $host = preg_replace('/^[0:]*:ffff:/i', '', $host);

-            if (preg_match('/([0-9a-f.-]+)\.nip\.io$/i', $host, $matches)) {
+            if (preg_match('/([0-9a-f.-]+)\.(nip|sslip)\.io$/i', $host, $matches)) {
                $host = trim($matches[1], '-.');
            }

Source: Roundcube commit 294c7da6. The patch broadens the IPv6-mapped IPv4 regex to catch leading-zero variants and adds sslip.io alongside nip.io to the wildcard DNS blocklist.

Detection Methods for CVE-2026-62643

Indicators of Compromise

Outbound HTTP requests from the Roundcube server to RFC1918 addresses, loopback interfaces, or cloud metadata endpoints such as 169.254.169.254
HTML email messages containing <link rel="stylesheet"> or @import directives referencing wildcard DNS services like nip.io or sslip.io
Server logs showing stylesheet fetches to IPv6-mapped IPv4 addresses with unusual prefix formatting
Anomalous DNS queries from the mail server to hostnames encoding internal IP addresses

Detection Strategies

Inspect inbound SMTP traffic for HTML messages containing suspicious CSS url() or @import references pointing to local address ranges
Correlate Roundcube web server outbound connections against internal network segments not typically accessed by the mail application
Monitor Roundcube application logs for CSS parsing events involving external URLs

Monitoring Recommendations

Enable egress filtering on the Roundcube host and alert on connections to internal ranges or metadata IPs
Deploy detection rules for HTML email attachments containing SSRF-adjacent DNS names like nip.io, sslip.io, and xip.io
Track Roundcube version strings in HTTP responses to identify unpatched instances across your environment

How to Mitigate CVE-2026-62643

Immediate Actions Required

Upgrade Roundcube Webmail to version 1.6.17 or 1.7.2 immediately
Audit outbound network policies from the Roundcube server and block access to internal networks and metadata services
Review web server access logs for prior exploitation attempts referencing wildcard DNS services
Disable HTML email rendering for high-risk user groups until patching is complete

Patch Information

Roundcube published fixes in commits 294c7da6 and 6d69e094. Official releases are available at Roundcube 1.6.17 and Roundcube 1.7.2. See the Roundcube Security Updates Announcement for full release notes.

Workarounds

Configure a strict egress firewall policy that blocks Roundcube from reaching RFC1918, loopback, and link-local addresses
Force plaintext-only rendering of HTML email until the patch can be applied
Deploy a reverse proxy or WAF rule that strips or blocks CSS @import and <link> elements from inbound message bodies

bash

# Verify installed Roundcube version and upgrade
grep -r 'RCMAIL_VERSION' /var/www/roundcube/program/include/

# Example iptables egress restriction for the Roundcube host
iptables -A OUTPUT -d 127.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 10.0.0.0/8 -j REJECT
iptables -A OUTPUT -d 172.16.0.0/12 -j REJECT
iptables -A OUTPUT -d 192.168.0.0/16 -j REJECT
iptables -A OUTPUT -d 169.254.0.0/16 -j REJECT