Roundcube October Security Update: Inside the NAT64 Fix

Three added address ranges explain one of the most useful details in Roundcube’s October security update. The NAT64 fix expands a URL classifier’s network list, and the accompanying tests show which IPv6 URL forms must be treated as local. The code gives administrators a more precise starting point than a generic “webmail RCE” headline.

Roundcube released 1.6.20 and 1.7.5 for its 1.6 LTS and 1.7 branches. Administrators should deploy the applicable supported security update through their installation’s normal maintenance channel. The practical challenge is deciding which workflows deserve extra attention, especially where a hosting panel, distribution package, or custom plugin sits between upstream Roundcube and the running service.

Reviewed October 21, 2026. This analysis uses the announcement, release notes, and a focused review of the published NAT64-filter commit. It does not report an end-to-end exploit reproduction or observed attacks against these October fixes.

Inside the NAT64 fix: three added ranges and five regression cases

について official 1.6-branch commit 3c3a65f changes program/lib/Roundcube/rcube_utils.php. Inside is_local_url(), it adds three address ranges to the existing network list. The NAT64 entries cover whole prefixes rather than one example of an embedded private IPv4 address.

// Added to the existing $nets array in is_local_url():
'::/128',
'64:ff9b::/96',
'64:ff9b:1::/48'

This is a range-level classification change. The two NAT64 entries address translated representations; ::/128 handles the unspecified IPv6 address separately. A prefix-wide rule can classify translated public destinations too, so the change is broader than rejecting a single localhost spelling.

The same commit adds five URL/boolean pairs in tests/Framework/Utils.php, all expecting 真の. The following are upstream regression fixtures, not output from tests run for this article.

// Added in provide_is_local_url_cases():
['http://[::]/', true],
['http://[64:ff9b::]/', true],
['http://[64:ff9b:1::]/', true],
['http://[64:ff9b::a9fe:a9fe]/', true],
['http://[64:ff9b::7f00:1]/', true],

These assertions describe the classifier’s expected answer. They do not establish a remotely reachable fetch action, an available NAT64 translator, or a sensitive internal response. Those are separate conditions to check in an authorized environment.

For a paired comparison, prepare clean 1.6.19 and 1.6.20 checkouts with supported PHP and development dependencies. Carry the same five fixtures into the older provider and run the matching helper tests in both trees. The older suite without these additions would omit precisely the cases of interest. Record the runtime, commit, command, and actual failures before reporting a before/after result.

Validation status: the published diff and fixtures were inspected. Paired PHP test runs have not been executed for this article; no pass counts or measured pre-patch results are reported.

First establish which installation you are updating

A company may have a panel-managed webmail instance, an older manually installed copy, and a staging system under different hostnames. The package updated by an administrator is not necessarily the application served by every virtual host. Identify the web root, deployment owner, release branch, and source of updates before selecting a package.

について 1.6.20 release そして 1.7.5 release are separate maintenance destinations. A security notice covering both does not require an administrator to turn an urgent maintenance update into an unplanned major-branch migration. Conversely, an older branch is not cleared merely because it is absent from a short announcement.

For packaged installations, an upstream-looking version alone can be misleading. Some vendors backport fixes while retaining an older base version; others lag behind upstream. The meaningful question is which patch set the installed package contains. Retain the package revision and vendor notice together rather than overriding the package manager with files from an unrelated installation method.

The IMAP fixes concern a protocol boundary, not a shell command

について 1.6.20 notes identify CRLF-based IMAP command injection involving message identifiers in the headers and source-view actions, and flags in the mark action. IMAP is the protocol Roundcube uses to work with mailboxes. Command injection at that boundary should not automatically be described as operating-system command execution.

The underlying engineering concern is that data and protocol syntax share a connection. Carriage returns and line feeds have structural meaning in many text protocols. If an application accepts them where it expects only a value, the receiving service may interpret an unintended command boundary. The exact effect still depends on the affected path and its authorization context; the release summary does not establish a universal unauthenticated exploit.

For an administrator, that distinction changes the follow-up. After updating, exercise normal source viewing, header viewing, and flag changes with a test mailbox. Confirm that read/unread changes and message selection still affect the intended messages. These are functional regression checks. Passing them does not independently prove that crafted protocol input is rejected; that stronger conclusion requires a reviewed regression test or controlled assessment.

Remote-content blocking and SSRF filtering protect different things

について October announcement includes a local-URL filter bypass involving the NAT64 prefix 64:ff9b::/96, alongside bypasses in SVG and CSS remote-content blocking. These belong in separate parts of a rollout review. A browser deciding whether to load outside content and a server deciding whether to fetch a destination are different security decisions.

For SSRF, the interesting question is what the webmail server can reach on behalf of someone else. Address representations and translation can complicate a rule intended to exclude local destinations. The presence of a NAT64-related fix does not show that every installation has a working route to an internal service; routing, name resolution, and outbound controls remain deployment-specific. It does show why matching a URL’s visible spelling is an insufficient general design for a destination filter.

For remote-content blocking, the concern is whether material in an email can cause an external request despite the user’s chosen policy. Such a request may disclose that a message was opened or reveal connection information. It does not, by itself, establish theft of the mailbox or execution on the server. Keep those outcomes separate when communicating the update to users.

Use a harmless test message and a destination you control when reviewing expected content behavior in staging. Check the default blocked state and the explicit “show remote content” action separately. Avoid putting real customer messages or third-party tracking addresses into a regression fixture. A screenshot of a hidden image is also incomplete evidence: the relevant observation is whether a request left the browser or server.

Optional features deserve a configuration check

について 1.7.5 release notes also list a Password Modoboa driver account-change issue, deprecated action aliases bypassing disabled_actions, and an object-injection primitive in session decoding. A release containing these fixes is not proof that a particular deployment has the same optional driver, policy configuration, or reachable session-manipulation path.

This inventory helps set testing priorities; it is not a reason to remove the core security update when one optional feature is absent. Core code paths and installed extensions are maintained as a deployment, and a partial hand patch creates another variant to track. Custom plugins deserve separate compatibility review because an upstream release cannot establish the safety of code maintained outside the project.

Session decoding warrants especially careful wording. An object-injection primitive describes a building block, not a complete demonstrated outcome. Turning it into code execution may require control of particular input and usable behavior elsewhere in the application. The public release summary is sufficient to justify updating, but not to claim that an arbitrary unauthenticated HTTP request produces a shell.

Plan the update around the way Roundcube was installed

For an upstream installation, the project upgrade guide calls for backing up the application directory and database, reading the release package’s installation and upgrade instructions, and using the supplied update procedure. The guide itself warns that the wiki can become outdated, so the files shipped with the selected release take precedence. A database backup matters because restoring old application files may not reverse a schema migration.

The guide also distinguishes the 1.7 layout: its web-server document root must use public_html. Treat that as a migration prerequisite when moving branches, not as a directory change to apply blindly to every existing 1.6 installation. Review the virtual-host configuration in staging before changing a production path.

For panel-managed or distribution-managed deployments, follow the provider’s supported process. Replacing files behind the panel can leave its package database, permissions, and future updates inconsistent with the application on disk. If the fixed package has not appeared, ask the provider for the patched revision and delivery status, with the exact package and service identity attached.

A small local inventory can help identify who owns the deployment. The following commands are read-only examples for an administrator’s own host. They do not test a vulnerability, and no package output does not mean Roundcube is absent: a manual install, panel bundle, or container can use a different layout.

# Debian/Ubuntu: installed package names and versions
dpkg-query -W 'roundcube*'

# RPM systems: search installed package names
rpm -qa | rg -i roundcube

# Run from an upstream Git checkout, if this deployment has one
git describe --tags --always
git status --short

Run only the commands appropriate to the installation. A Git tag identifies a checkout, not necessarily the code served by PHP. Compare the result with the configured application path and the deployed release artifact. If several application nodes serve the same hostname, check all of them; a single updated node can mask an incomplete rollout during a browser test.

Finish with mailbox operations, not just a successful login

Use a dedicated mailbox to sign in, open a message, view its source, change flags, send a message, and open an ordinary attachment. Include the enabled password-change feature if the installation provides one. Capture the pre-update expectations so a team can distinguish a new failure from an existing configuration problem.

Review application and web-server errors during those checks. A new rendering failure, repeated backend error, or broken password-change flow deserves investigation before the maintenance window closes. Keep test mail and logs free of production passwords and message contents when attaching results to a ticket.

If suspicious activity was already present, preserve the relevant records before routine cleanup. Installing a fixed release addresses the application defects; it cannot establish what happened before installation. At the same time, the October release list alone is not evidence that a mailbox has been compromised. Investigate concrete observations rather than assuming either conclusion.

The useful completion record is short: which deployment was changed, which supported release or patched package now serves it, which enabled workflows were checked, and what remains unresolved. That gives the next operator a reliable starting point without requiring them to reconstruct the installation from an “updated successfully” message.

Explore Penligent →