Roundcube Security Update: Patch 1.6.20 / 1.7.5 (2026)

The Roundcube security update released on 19 October 2026 ships versions 1.6.20 (LTS) and 1.7.5, fixing 20 security flaws in one release — including two IMAP command-injection bugs and four mail-header injections. Roundcube has assigned no CVE IDs and no severity scores to any of them yet, which means most vulnerability scanners will not flag this release. Do not let the missing CVEs fool you: the fix list reads like a tour of everything an attacker can poke at in a webmail server. If you run Roundcube anywhere — your VPS, your company’s mail, your cPanel shared hosting — this guide shows you how to check your version and upgrade tonight. All facts verified on 19 October 2026.

Table of Contents

The Roundcube Security Update at a Glance

Detail	Fact
Released	19 October 2026
Fixed versions	1.6.20 (1.6 LTS line) and 1.7.5 (1.7 line)
Flaws fixed	20
CVE IDs	None assigned yet
Severity scores	None published yet
Exploited in the wild	No confirmed exploitation of these new flaws as of 19 October 2026
Who should update	Every productive Roundcube 1.6.x and 1.7.x install
Official announcement	roundcube.net — “Security updates 1.6.20 and 1.7.5”

The 20 Fixes, Grouped by What They Let an Attacker Do

Roundcube’s announcement lists the flaws with the researchers who reported them but no technical write-ups and no severity ratings, so this section stays at the advisory level: what each group of fixes means for your server, in plain English. The full itemised list is in the official announcement (linked at the end).

IMAP command injection (2 flaws)

Two bugs let an attacker smuggle extra IMAP commands through line-break characters in request parameters — a classic CRLF injection. The first sits in the _uid parameter of the mail/headers and mail/viewsource actions; the second in the _flag parameter of the mail/mark action. A crafted request could make the mail server execute actions the user never intended — marking, moving, or fetching mail under the attacker’s control. Injection flaws that reach the mail server directly are the ones you patch first.

Mail header injection (4 flaws)

Four separate fixes close header injection through mail fields Roundcube builds from user-controlled input: the From display-name in the Bounce (resend) action, the References / In-Reply-To / Message-ID / From parameters, the subject of a message forwarded as an attachment, and the media type in an inline image data URI. When header fields are not filtered strictly, crafted input can inject extra headers into outgoing mail — the traditional route to spoofed senders, hidden BCC harvesting, or turning your server into a spam relay.

HTML content-filter bypasses (4 flaws)

Roundcube blocks remote content in HTML mail (the tracking-pixel defence) and scopes message CSS so it cannot restyle the whole webmail UI. Three fixes close bypasses of those filters: remote-content blocking evaded through the SVG SMIL by attribute, remote-content blocking evaded through CSS escapes in FuncIRI attributes (Roundcube notes this one is a repeat of a previous fix — the bypass came back), and CSS scoping in HTML messages evaded with at-rules. A fourth fix adds a size limit to CSS proxy content processing, which is resource-exhaustion hardening: unbounded proxy processing is a denial-of-service shape waiting to happen.

Session, login and permission quirks (4 flaws)

This group is the “small logic bugs with outsized consequences” drawer. Roundcube fixed a bug where an alias login was not qualified by the IMAP host (login routing matters when one install serves multiple domains), a bug where deprecated action aliases bypassed the disabled_actions setting (your carefully disabled actions were not actually disabled), a potential object-injection primitive in rcube_session::unserialize() via “!”-prefixed session keys, and unsafe use of the login name in the SquirrelMail import file path. None of these is glamorous; all of them are the kind of flaw that turns up in post-incident forensics.

SSRF, CSRF, password drivers and ImageMagick (6 flaws)

The remaining six are a mixed bag:

SSRF filter bypass via NAT64 — the is_local_url() check could be evaded with addresses in the 64:ff9b::/96 NAT64 range, letting an attacker make the server fetch internal URLs it should have refused.
CSRF validation bypass in the mark-as-junk action — cross-site request forgery protection that does not cover every state-changing action is not protection.
XSS in password driver error responses — error text from password plugins was rendered without escaping.
Password Modoboa driver bug — the driver could change the password for another account. If you use the Modoboa password driver, read that twice.
Unsafe attachment content passed to ImageMagick on resize — ImageMagick has a long, proud history of being an attack surface; feeding it untrusted content is how that history repeats.
ImageMagick resource limits bypassed by the GD fallback during thumbnail generation — the safety rails applied to one image library did not apply to the fallback path.

No CVE IDs — Why That Changes Nothing

Roundcube discloses security fixes in advisory style: the announcement lists what was fixed and who reported it, and CVE identifiers arrive later — if ever. The previous security roundup in September 2026 (twelve flaws, versions 1.7.4 and 1.6.19) shipped the same way. Your scanner staying quiet is a reporting convention, not a risk assessment.

And there is a recent warning shot that says exactly what happens when Roundcube admins wait. In September 2026, the Canadian Centre for Cyber Security updated advisory AV26-503 to say that CVE-2026-48842 — a pre-authentication SQL injection in Roundcube’s virtuser_query plugin, patched back in May 2026 in versions 1.6.16 and 1.7.1 — was being actively exploited. The Cyber Centre’s wording: “Open-source reporting indicates that CVE-2026-48842 is being exploited in the wild.” The flaw scored CVSS 8.1 and needed no login. Attackers had a four-month gap between patch and confirmed exploitation to scan for stragglers.

The scale of the target surface is not theoretical either. Shadowserver telemetry reported in September showed over 523,000 Roundcube instances exposed on the internet (with the honest caveat that there is no data on how many are honeypots or already patched). Roundcube ships as the default webmail in cPanel, so a large share of those instances are on shared hosting where the admin never chose Roundcube at all — it just came with the server.

Two things follow. First, the new flaws have no confirmed exploitation and no public proof of concept yet — that is the best possible moment to patch, while the window is still closed. Second, if your Roundcube is older than 1.6.16 / 1.7.1, you were exposed to the September flaw too; upgrading to 1.6.20 or 1.7.5 closes both doors at once.

Check Which Roundcube You’re Running

Before anything else, find out what you have. Two reliable ways:

In the web UI: log in and open the About dialog — in 1.7 it lives under Settings — which displays the installed version. If your login page shows a version string, do not trust it alone; the About dialog reads it from the running code.

On the command line: the version constant lives in program/include/iniset.php (Roundcube’s own upgrade script reads it from there):

grep -E "define\('(RCUBE|RCMAIL)_VERSION'" /path/to/roundcube/program/include/iniset.php

If the version is anything below 1.6.20 on the 1.6 line or below 1.7.5 on the 1.7 line, you are on a vulnerable release. If it is below 1.6.16 / 1.7.1, you were also exposed to the actively exploited September flaw — treat the upgrade as urgent, not routine.

How to Upgrade to 1.6.20 or 1.7.5

Roundcube’s official upgrade path is the installto.sh script, and it is refreshingly painless — but do the backup first, because webmail databases hold the one thing users will riot over losing.

Step 1 — back up everything. Copy the whole Roundcube directory and take a full database dump (schema plus data):

cp -a /var/www/roundcube /var/www/roundcube-backup-$(date +%F)
mysqldump -u dbuser -p roundcubemail > roundcube-db-$(date +%F).sql

Step 2 — download the new release. Grab the tarball for your line (1.6.20 or 1.7.5) from the official download page and unpack it somewhere outside your web root:

tar xf roundcubemail-*.tar.gz
cd roundcubemail-1.6.20   # or roundcubemail-1.7.5

Step 3 — run the upgrade script. From the unpacked directory, point installto.sh at your existing install. It copies the updated files over, migrates your local configuration, and updates the database schema if the release needs it:

bin/installto.sh /var/www/roundcube

Read the UPGRADING file in the package first and check the system requirements section — releases occasionally raise the PHP floor, and discovering that mid-upgrade is no fun.

Step 4 — finish with Composer if needed. If you did not download the complete package, install the third-party dependencies:

php composer.phar install --no-dev

Step 5 — the 1.7 gotcha. From Roundcube 1.7, your web server must use the public_html folder inside the Roundcube directory as the document root. If you are jumping lines (or your vhost still points at the old root), fix the document root before you declare victory.

Step 6 — verify. Check the About dialog shows 1.6.20 or 1.7.5, log in, send and receive a test message, and confirm your plugins still load. Keep the backup from Step 1 until you have done this.

On Shared Hosting or cPanel

Most Roundcube installs are not hand-rolled — they arrived with cPanel or a hosting panel, and the update arrives the same way: through your host’s update process, not your SSH session. You usually cannot upgrade Roundcube yourself on shared hosting, so the move is:

Check the About dialog today and note the version.
If it is below 1.6.20 / 1.7.5, open a ticket or check your host’s status page — ask when the Roundcube update lands.
Check again after they confirm. Hosts batch these updates; the September flaw showed that a four-month lag is enough to get exploited, so a polite ticket beats silent waiting.

cPanel administrators on dedicated or VPS servers: make sure your cPanel update routines have run and pulled the patched Roundcube RPM packages across all tiers. Webmail commonly listens on ports 2095/2096 — exposed by design, which is exactly why the patch matters.

If You Can’t Patch Tonight

Roundcube published no workaround for these flaws — the upgrade is the fix. There are no published indicators of compromise for the new flaws either, so “check whether you were hit” is not an option; the honest move is to close the window before anyone finds it.

If the upgrade genuinely cannot happen tonight, do the next best things: make sure you are at least on 1.6.16 / 1.7.1 (the May release that fixed the exploited September flaw), restrict webmail access to the IPs that need it if your setup allows, and put the upgrade at the top of tomorrow’s list. The new flaws have no confirmed exploitation today. Every day you wait, that sentence gets more likely to expire.

The Pattern Worth Noticing

Roundcube has now shipped three security releases in five months — May (the exploited SQL injection), September (twelve flaws), and October (twenty flaws). Attackers keep coming back because webmail is where the credentials live: one compromised webmail server hands over mail, password resets for every other service, and the trust of everyone that account emails. If you are responsible for a Roundcube install, add a monthly version check to whatever maintenance routine you already run — the five minutes it takes is the cheapest security work in your stack. A standing backup routine helps too, so an upgrade never feels risky: see our automated VPS backups guide.

This is the same triage instinct as our GhostAction supply-chain check and the CISA KEV weekend triage: when the fix is published, the clock starts for everyone who has not applied it.

Roundcube Security Update: 20 Flaws Fixed in 1.6.20 and 1.7.5 — Patch Tonight (2026)