Roundcube 1.6.20 and 1.7.5: IMAP Injection and Object Injection Fixed

Roundcube Webmail 1.6.20 (LTS) and 1.7.5, released on 19 October 2026, fix 20 security flaws, including IMAP command injection through CRLF in two request parameters and a PHP object injection primitive in session handling. Every 1.6 install before 1.6.20 and every 1.7 install before 1.7.5 is affected. Upgrade now and confirm the running version.

No exploitation of any of these 20 flaws has been reported as of 24 October 2026, and we found no public proof of concept. This is a vulnerability disclosure, not a breach. It still deserves fast attention, because Roundcube sits on the internet in front of mailboxes, it has a long record of bugs that went on to be exploited, and the fixes arrived in a single batch that spans command injection, server-side request forgery, mail header injection and authorization mistakes.

When Roundcube published the release, the announcement carried no CVE identifiers, and the oss-security summary posted the next day said the same. That has since changed. MITRE, acting as the CVE Numbering Authority, published CVE records for all 20 fixes between 20 and 22 October, and Debian shipped DSA-6579-1 for trixie on 23 October with all 20 IDs listed. This post maps each fix to its CVE record, gives the release hashes and signing details, and walks through version checks, upgrade paths, interim hardening and log checks for each common way Roundcube is deployed.

One note on timing. This release landed in the same week many teams are rebuilding PHP after PHP2Shell. The link is timing only. Roundcube is a PHP application, so anyone touching PHP hosts this week should patch Roundcube in the same window, but there is no technical connection between the two disclosures, and nothing in the Roundcube release refers to PHP2Shell. If you are on that work already, our posts on the PHP2Shell CVEs and finding and patching every PHP runtime cover the runtime side.

What happened

On Monday 19 October 2026, the Roundcube project published security updates for its two maintained branches: 1.6.20 for the 1.6 long term support line and 1.7.5 for the current 1.7 stable line. The project's news post describes them as fixes for recently reported vulnerabilities and strongly recommends updating every production installation. The GitHub release notes for both versions carry an identical list of 20 security fixes, each credited to its reporter, and both close with the usual advice to back up data before updating.

The 1.7.5 release also carries five non-security changes: the installer can now destroy its own session and cookie, the Enigma plugin's db_sync() now restores keyring files (#10343), the markasjunk plugin skips messages whose %s or %h values start with a hyphen (#10344), the password plugin replaces SQL placeholders in a single pass (#10345), and the healthcheck.sh exit code was fixed (#10337). Two of those touch plugins that also appear in the security list, which matters if you carry local patches to them.

The fixes fall into a handful of families:

• IMAP command injection. CRLF sequences in the _uid parameter of the mail/headers and mail/viewsource actions, and in the _flag parameter of the mail/mark action, could be turned into extra IMAP commands sent by Roundcube to the mail server.
• Session object injection. rcube_session::unserialize() mishandled session keys prefixed with "!", producing what the release notes call an object injection primitive.
• ImageMagick and image handling. Potentially unsafe content could be passed to ImageMagick on image resize, and the GD fallback for thumbnails skipped the memory check on non-Windows platforms.
• Server-side request forgery. The is_local_url() filter did not block the NAT64 prefix 64:ff9b::/96.
• Mail header injection. Four separate paths let CRLF sequences reach outgoing message headers or MIME part headers.
• Remote content and CSS. Two bypasses of remote content blocking, a CSS scoping bypass through at-rules, and an unbounded read in the CSS proxy.
• Authorization and authentication. Deprecated action aliases bypassed disabled_actions, mark-as-junk lacked effective CSRF validation, the Modoboa password driver could change another account's password, alias logins were not qualified by IMAP host, and the SquirrelMail import path trusted the login name.
• Cross-site scripting. Password driver error messages were shown without HTML escaping.

On Tuesday 20 October, Valtteri Vuorikoski posted a summary to the oss-security mailing list under the subject "Roundcube webmail: multiple vulnerabilities prior to 1.6.20 / 1.7.5". It lists the same 20 items with reporter credits and gives no CVE identifiers, no severity ratings and no exploitation details.

Timeline

All times are UTC unless noted. Times come from the source named in the last column.

The cadence is worth noticing. Roundcube shipped paired 1.6 and 1.7 releases on 5 July, 9 August, 6 September and 19 October, according to the GitHub releases API. Several fixes in this batch revisit areas fixed in September: 1.6.19 already fixed a remote content blocking bypass via CSS escapes in FuncIRI attributes, and 1.6.20 fixes it "again", in the release notes' own word. If your patch process treats Roundcube as a component that changes once a year, it is out of step with the project.

Who is affected

Some fixes only matter if a feature is turned on. The Modoboa fix applies only where the password plugin uses the Modoboa driver. The SquirrelMail path fix applies only where the squirrelmail_usercopy plugin uses its file backend. The alias login fix applies to multi-host installations. The mark-as-junk CSRF fix applies where the markasjunk plugin is enabled. The ImageMagick fixes matter most where im_convert_path points at ImageMagick; Roundcube's default im_convert_path is null, which means it uses the Imagick or GD extensions instead. The IMAP injection, session, header injection, CSS and remote content fixes apply to core code that every installation runs.

Who can reach these bugs

Most of the 20 need either a logged-in user or a crafted message that a logged-in user opens. The CVE records spell this out through their CVSS vectors. The two IMAP command injection records (CVE-2026-113386 and CVE-2026-114720) use PR:L, meaning an attacker needs a low-privilege account, which in webmail terms is any mailbox login. Several header injection and remote content records use PR:N, because the attacker's input arrives as a received message. None of the records describes an unauthenticated path to code execution, and we will not speculate beyond what the records say.

That still leaves a real risk model. Webmail accounts are phished, reused and shared. On hosting platforms that give Roundcube to thousands of customers, "authenticated attacker" can mean any customer. An IMAP injection that lets one logged-in user send arbitrary IMAP commands through the webmail's own connection is a concern precisely in those shared settings.

How it works

This section explains each family in plain language. It does not include payloads or step by step attack instructions.

IMAP command injection through _uid and _flag

Roundcube talks to the mail server over IMAP, a line-based protocol in which each command ends with a carriage return and line feed (CRLF). Some request parameters, such as the message UID a user wants to view or the flag they want to set, end up inside IMAP commands. If a parameter value contains CRLF, the server can read what follows as a new command. According to the CVE records, before the fix the _uid parameter of mail/headers and mail/viewsource and the _flag parameter of mail/mark accepted such sequences. The _flag fix, per CVE-2026-114720, rejects flags containing control, whitespace and IMAP-special characters.

The practical effect depends on the IMAP server and the account's rights. An injected command runs with the logged-in user's own IMAP session, so it is not a direct path to other users' mailboxes on a well configured server. It can still be used to act on the user's mailbox in ways the interface does not allow, and it bypasses whatever restrictions Roundcube applies above IMAP. Both records are scored 7.1 by the CNA, with integrity impact rated High.

Object injection in session handling

Roundcube stores session data in its own serialized format and parses it in rcube_session::unserialize(). CVE-2026-114724 explains that a session key starting with "!" was treated as having no value, so the reconstructed serialized string had a key with no matching value. Everything after it was then read out of step, which meant later session data could be interpreted as a serialized PHP value. That is an object injection primitive: if an attacker can shape stored session data, they may be able to get PHP to build objects of their choosing when the session is loaded. The fix rejects such keys.

Two details keep this in proportion. First, the CVE record's vector is AV:L/AC:H/PR:N/UI:N, scored 7.4: the CNA treats it as hard to reach and local in attack vector, reflecting that an attacker must be able to influence stored session data. Second, a primitive is not a chain. Turning object injection into code execution depends on which classes are loaded and what they do on construction or destruction. Nobody has published such a chain for this bug.

The reason defenders should still put this one near the top is history. CVE-2025-49113, fixed in June 2025 in 1.6.11 and 1.5.10, was a post-authentication PHP object deserialization flaw in program/actions/settings/upload.php that allowed remote code execution, scored 9.9 by its CNA. CISA added it to the Known Exploited Vulnerabilities catalog on 20 February 2026. A new deserialization primitive in the same application, even a harder one to reach, is the kind of finding attackers study.

ImageMagick and image resizing

Roundcube can resize images for contact photos and thumbnails. When im_convert_path is set, it shells out to ImageMagick. CVE-2026-114727 says SVG and EPS were accepted as valid image types for contact photo upload and conversion, and that both formats can reference external resources and invoke ImageMagick delegates when processed. The fix removes svg and eps from the accepted types. The CNA scores it 8.3, the highest in the batch.

The companion bug, CVE-2026-114723, is a resource exhaustion issue. When Roundcube falls back from ImageMagick to the GD extension for thumbnails, the available memory check ran only on Windows. On Linux and macOS a crafted image with very large dimensions was processed by GD with no limit. The fix applies the check everywhere.

SSRF filter bypass through NAT64

Roundcube fetches some remote resources on the user's behalf, for example stylesheets referenced by HTML messages through its CSS proxy. rcube_utils::is_local_url() is meant to stop those fetches from reaching loopback, private or link-local addresses. CVE-2026-114730 says its blocklist missed the RFC 6052 well-known NAT64 prefix 64:ff9b::/96, the RFC 8215 local-use NAT64 prefix 64:ff9b:1::/48 and the unspecified address ::/128. On a network with NAT64, an IPv6 address inside that prefix maps to an IPv4 address, so a URL that looked like public IPv6 could reach internal IPv4 services, including cloud metadata endpoints. The record lists the affected range as 1.6.14 up to 1.6.20 and 1.7.0 up to 1.7.5.

RFC 6052 itself says the well-known prefix must not be used to represent non-global IPv4 addresses, and translators should drop such packets. In practice, whether this bug matters depends on your network: hosts without IPv6 egress or without a NAT64 gateway are far less exposed.

Mail header injection

Four fixes stop CRLF sequences from reaching outgoing headers:

• In the Bounce (resend) action, the decoded From display name was not stripped of control characters (CVE-2026-114726).
• The References, In-Reply-To, Message-ID and From request parameters were not normalized, because newline stripping covered only Subject and Organization (CVE-2026-114725).
• The subject of a message forwarded as an attachment was used verbatim as the attachment name (CVE-2026-114717).
• The media type of an inline image data URI was used without validation in rcmail_sendmail::extract_inline_images() (CVE-2026-114716).

Header injection lets an attacker add recipients, alter how a message is parsed or smuggle MIME parts, using the victim's authenticated session and the organization's own outbound mail path. The 1.6.19 release in September already fixed three other header injection paths, so this is a recurring class in Roundcube's compose and send code.

Remote content blocking and CSS scoping

Roundcube blocks remote images and other remote content in HTML mail by default (show_images defaults to 0) so that opening a message does not reveal the reader's IP address or confirm the message was read. CVE-2026-114729 says the sanitizer checked the SVG SMIL animation attributes to, from and values but not by. CVE-2026-114728 says the url() detection in FuncIRI attributes missed some CSS escape spellings. The fix resolves CSS escapes before matching.

CVE-2026-114722 is different: Roundcube rewrites CSS in HTML messages so that it only applies inside the message body. At-rule prologues and selectors beginning with :: were not handled, so some rules escaped the message and restyled the Roundcube interface itself. The record describes the impact as UI redressing and spoofing. CVE-2026-114731 caps the CSS proxy at 5 MB, reads as a stream and adds a read timeout.

Authorization and authentication fixes

• disabled_actions bypass (CVE-2026-114721). Administrators use disabled_actions to switch off features. The check compared only the requested action name, so an action could be reached through its deprecated alias. The fix moves the check into rcmail::action_handler() and resolves aliases first.
• Mark-as-junk CSRF (CVE-2026-114719). The markasjunk plugin read _uid from POST but passed it to rcmail::get_uids() without constraining the input mode, so the helper could read values from the query string and skip the CSRF token check.
• Modoboa password driver (CVE-2026-114715). The driver took the first account in the Modoboa API's search result instead of the one matching the logged-in user, so a password change could land on a different account.
• Alias login (CVE-2026-114732). In multi-host installations, an alias login was matched against identity records without checking the IMAP host, so it could resolve to a user on a different host.
• SquirrelMail import path (CVE-2026-114714). With the file backend, a login name containing a slash could make the plugin read files outside squirrelmail_data_dir.
• Password driver XSS (CVE-2026-114718). Error text from a password backend, the record cites the DirectAdmin API as an example, was shown without HTML escaping.

Technical details

Everything in this section comes from the Roundcube release notes, the GitHub releases API, the CVE records published by MITRE, Debian's tracker and advisory, Packagist and Docker Hub. CVSS scores below are the CNA's (MITRE's) CVSS 3.1 scores in the CVE records. Other scorers may differ, and Roundcube itself published no scores.

The 20 fixes mapped to CVE records

Two observations. The highest CNA scores in the batch are the inline image header injection (8.5) and the ImageMagick content issue (8.3), not the session bug. And the CNA scored the session object injection with a local attack vector. If your patch policy keys only on "critical" scores, nothing in this batch crosses 9.0, and that is exactly the wrong reason to wait.

Fix commits referenced by the CVE records

Each CVE record links two upstream commits, which correspond to the fixes in the two maintained branches. For the four fixes most teams will want to review:

These are useful if you maintain a fork or a vendor build and need to confirm a specific fix is present. They are not a substitute for upgrading: the 20 fixes interact, and backporting a subset leaves you on a version nobody else runs.

Release artifacts and SHA-256 digests

From the GitHub releases API. Each tarball has a detached .asc signature next to it.

We downloaded roundcubemail-1.6.20.tar.gz on 24 October and its SHA-256 matched the value above. Inside it, program/include/iniset.php defines RCMAIL_VERSION as 1.6.20 and program/lib/Roundcube/bootstrap.php defines RCUBE_VERSION as 1.6.20. Note that the same files in the git tree at the tag read 1.6-git; the version string is set when the release tarball is built, so a git checkout will not tell you its version this way.

Signing: GitHub shows both tags signed with a verified signature by Aleksander Machniak, GPG key ID BEE674A019359DC1. Roundcube's download page says release tarballs are signed by "Roundcube Developers" with the alias 41C4F7D5, with the public key at the project's pubkey.asc and on public keyservers.

Distribution and image status

DSA-6579-1 summarizes the impact as IMAP command injection, cross-site scripting, SSRF bypass, email header injection, CSS property injection, remote content blocking bypass, information disclosure or privilege escalation.

Indicators of compromise

There are none. No advisory lists IPs, domains, hashes or user agents, because no exploitation has been reported. Treat any "IOC list" for this release that you see elsewhere with suspicion. The detection ideas in the next section are behavioural checks you can run on your own logs, not indicators from an official source.

Why this release matters: Roundcube's KEV history

CISA's Known Exploited Vulnerabilities catalog is a list of flaws CISA has evidence were exploited in the wild. In catalog version 2026.10.23, released 23 October, 11 entries name Roundcube. None of them is from this release. They are context for why Roundcube patches should move quickly, not evidence that these new bugs are being used.

Three patterns stand out. First, most exploited Roundcube bugs were cross-site scripting in how HTML mail is rendered, the same code area that this release touches through the remote content and CSS fixes. Second, the one deserialization entry, CVE-2025-49113, was a post-authentication bug, so "needs a login" did not keep it off the list. Third, several bugs were added to KEV years after their fix, which tells you that unpatched Roundcube installations stay exposed for a long time.

CISA's description of CVE-2025-68461 is a cross-site scripting flaw "via the animate tag in an SVG document." This release fixes another SVG animation issue, the SMIL by attribute bypass, though as a remote content blocking bypass rather than script execution. The overlap is in the code area, not in impact.

What to do now

Work through these steps in order. Commands assume a Linux host with shell access; adapt paths to your layout.

1. Find every Roundcube instance

Roundcube often arrives bundled. Look beyond the host you think of as "the webmail server":

# Upstream tarball installs: find the version file and print the version
sudo find / -path '*/program/include/iniset.php' -type f 2>/dev/null \
  -exec grep -H "define('RCMAIL_VERSION'" {} \;

# Debian and derivatives
dpkg -l 'roundcube*' 2>/dev/null | awk '/^ii/ {print $2, $3}'

# RPM based systems
rpm -qa 'roundcube*' 2>/dev/null

# Containers running anywhere you can reach
docker ps --format '{{.Image}} {{.Names}}' | grep -i roundcube

On the login screen, Roundcube shows the version only when display_product_info is set to 2; the default 1 shows the product name only. Checking files on the host is more reliable than reading the login page, and you should not probe servers you do not run.

If you deploy with Composer, check the lock file:

composer show roundcube/roundcubemail 2>/dev/null | grep -E '^versions'
grep -A3 '"name": "roundcube/roundcubemail"' composer.lock

2. Upgrade by deployment type

Debian 13 trixie:

sudo apt update
apt-cache policy roundcube-core
sudo apt install --only-upgrade roundcube roundcube-core
dpkg -l roundcube-core | awk '/^ii/ {print $3}'   # expect 1.6.20+dfsg-0+deb13u1

Debian 12 bookworm: as of 24 October, Debian's tracker lists bookworm as vulnerable with no fixed package. Your options are to wait for a DSA or LTS update while applying the hardening in step 3, or move to an upstream 1.6.20 tarball install. Do not mix a tarball over the packaged files; install to a separate path and switch the web server root.

Upstream tarball: download from the GitHub release, verify, then follow the upgrade instructions in the package's UPGRADING file and run the bundled update script.

VER=1.6.20   # or 1.7.5
curl -LO https://github.com/roundcube/roundcubemail/releases/download/$VER/roundcubemail-$VER-complete.tar.gz
curl -LO https://github.com/roundcube/roundcubemail/releases/download/$VER/roundcubemail-$VER-complete.tar.gz.asc

# Compare with the SHA-256 table in this post or the GitHub release page
sha256sum roundcubemail-$VER-complete.tar.gz

# Verify the signature with Roundcube's published key
curl -LO https://roundcube.net/download/pubkey.asc
gpg --import pubkey.asc
gpg --verify roundcubemail-$VER-complete.tar.gz.asc roundcubemail-$VER-complete.tar.gz

tar xzf roundcubemail-$VER-complete.tar.gz
# Back up the database and current install first, then:
cd roundcubemail-$VER
sudo -u www-data bin/installto.sh /var/www/roundcube

bin/installto.sh copies the new release over an existing installation and runs the database and config update steps. Run it as the user that owns the install, and take a database backup first, as the release notes ask.

Docker:

docker pull roundcube/roundcubemail:1.6.20-apache-nonroot   # or your variant
docker image inspect roundcube/roundcubemail:1.6.20-apache-nonroot \
  --format '{{index .RepoDigests 0}}'
docker compose up -d   # after updating the tag in your compose file
docker exec <container> grep "define('RCMAIL_VERSION'" /var/www/html/program/include/iniset.php

If you use latest or 1.6.x, a fresh pull is still required; a running container keeps the old image. Pin the digest you deployed so you can prove later which build was live.

Composer:

composer require roundcube/roundcubemail:1.7.5 --update-with-dependencies
composer show roundcube/roundcubemail | grep versions

Hosting panels and appliances: check the vendor's release notes for a build that includes Roundcube 1.6.20 or 1.7.5. Ask the vendor directly if their notes do not state the bundled version. Until the vendor ships, apply the hardening below where the panel allows it.

3. Interim hardening while you schedule the upgrade

None of this replaces the upgrade. It narrows exposure for the hosts you cannot patch today.

Turn off plugins you do not use. Review $config['plugins'] in config/config.inc.php. If you do not need the password plugin's Modoboa driver, the squirrelmail_usercopy plugin or markasjunk, remove them from the list.

grep -n "plugins'" /var/www/roundcube/config/config.inc.php
grep -n "password_driver" /var/www/roundcube/plugins/password/config.inc.php 2>/dev/null

Constrain ImageMagick. If im_convert_path is set, either unset it (Roundcube then uses Imagick or GD) or restrict ImageMagick with a policy. ImageMagick's own security policy documentation recommends a deny-by-default module policy, for example allowing only common raster formats:

<policymap>
  <policy domain="resource" name="memory" value="256MiB"/>
  <policy domain="resource" name="width" value="4KP"/>
  <policy domain="resource" name="time" value="60"/>
  <policy domain="delegate" rights="none" pattern="*"/>
  <policy domain="module" rights="none" pattern="*"/>
  <policy domain="module" rights="read | write" pattern="{GIF,JPEG,PNG,WEBP}"/>
</policymap>

ImageMagick applies the last matching rule, so the broad deny comes before the narrow allow. Check what is in force with:

magick identify -list policy      # ImageMagick 7
identify -list policy             # ImageMagick 6
grep -n "im_convert_path" /var/www/roundcube/config/config.inc.php

Test thumbnails and contact photos after the change; the allowed list above covers what Roundcube normally needs.

Filter egress from the webmail host. The NAT64 SSRF bypass only matters if the host can reach internal addresses through a NAT64 path. Allow outbound traffic only to the IMAP, SMTP and any sieve or LDAP servers it needs, plus the specific external hosts you want it to fetch from. Block the cloud metadata address at the host firewall. If your network does not use NAT64, confirm that 64:ff9b::/96 is not routed from the webmail host:

ip -6 route get 64:ff9b::1 2>&1

Check disabled_actions after upgrading. If you rely on $config['disabled_actions'] to switch off features, the alias bypass means it did not fully work before 1.6.20 and 1.7.5. After the upgrade, test that each disabled action is really unreachable from a test account.

Protect session storage. The default session_storage is db. The session object injection needs an attacker able to influence stored session data, so keep the database or Redis or Memcached session backend off any shared network, use a dedicated database user for Roundcube, and do not let other applications write to its session table.

Shorten sessions and require MFA where you can. Most of these bugs need a logged-in session. Strong authentication on mailboxes, such as a second factor through a plugin or your identity provider, raises the cost of every authenticated bug in this list.

4. Look for signs of attempted abuse

There are no official indicators. These are checks for unusual input that the fixes now reject.

Web server logs: CRLF in _uid, _flag or header parameters. Encoded CR and LF are %0d and %0a in a query string. A legitimate Roundcube client does not send them in these parameters.

sudo zgrep -iE '[?&]_(uid|flag)=[^& ]*%0[ad]' /var/log/nginx/access.log* /var/log/apache2/access.log* 2>/dev/null | head
sudo zgrep -iE '[?&]_action=(headers|viewsource|mark)' /var/log/nginx/access.log* 2>/dev/null \
  | grep -iE '%0[ad]' | head

POST bodies are not in standard access logs, so a clean result is not proof. If you have a reverse proxy or web application firewall that logs request bodies, search there too.

Roundcube logs. Check logs/errors.log (or syslog, if log_driver is syslog) for IMAP errors that mention unexpected commands, and logs/sendmail.log (on by default through smtp_log) for outgoing messages with unusual headers or recipients from a single account.

IMAP server logs. If your IMAP server can record per-session commands for a test period, look for commands from the webmail host's IP that Roundcube would not normally issue. Turn such logging on briefly; it records message content.

Contact photos. Look for SVG or EPS files uploaded as contact photos in Roundcube's temp directory or database, and for ImageMagick processes with long run times or outbound connections from the webmail host.

Outbound connections. Check firewall or flow logs for connections from the webmail host to 64:ff9b::/96 addresses or to internal ranges it has no reason to reach.

5. Confirm and record

After upgrading, re-run the version check from step 1 on every instance, keep the image digest or package version as evidence, and add Roundcube to whatever inventory feeds your vulnerability matching so the next batch is a one-line lookup, not a search.

What changed since first reports

• CVE IDs now exist. The release (19 Oct) and the oss-security summary (20 Oct) carried no CVE IDs. MITRE had in fact published CVE-2026-113386 at 04:53 UTC on 20 October, about eleven hours before the oss-security post, and published the remaining 19 on 22 October. If your tooling matched nothing on 20 October, run it again.
• Debian shipped a fix for trixie. DSA-6579-1 on 23 October lists all 20 CVEs. Bookworm is still marked vulnerable in the tracker.
• Official Docker images rebuilt. The 1.6.20 and 1.7.5 tags and the floating tags were updated on 23 October.
• Scores appeared. The CVE records carry CNA CVSS 3.1 scores from 3.1 to 8.5. Roundcube itself still publishes none.
• No exploitation, no KEV entry. Nothing in CISA's catalog as of version 2026.10.23, and no exploitation reports we could find.

Open questions

• Will the session primitive be chained? The record treats it as hard to reach. Whether anyone builds a reliable path from influencing session data to code execution in a real deployment is unknown.
• Bookworm timing. Debian 12 has a much older Roundcube (1.6.5 base). When and how its fix lands is not yet public.
• Vendor bundles. We could not confirm when hosting control panels and other distributions will ship 1.6.20 or 1.7.5.
• NVD enrichment. The CNA scores are in the records; whether NVD adds its own assessment, and whether it differs, is open.
• The 1.5 line. Older installs on 1.5 or earlier are not named in these records and get no release in this batch. Whether any of the bugs exist there has not been stated by the project.

What would have helped

There is no breach to explain here. The useful question is what lets a team move from "Roundcube shipped 20 fixes" to "every instance is on the fixed version" in days rather than months, given the KEV history above.

Practices any team can use

• Know where Roundcube runs. Keep a list of every webmail instance, its deployment type (package, tarball, container, Composer, panel) and its owner. Bundled copies inside hosting panels are the ones that get missed.
• Subscribe to the right feeds. Roundcube's news page, the GitHub releases feed for roundcube/roundcubemail, the oss-security list and your distribution's security tracker. This batch reached GitHub, Debian and oss-security before most CVE-keyed feeds.
• Treat webmail as an internet-facing application tier. Patch targets for Roundcube should match those for your VPN or edge devices, not those for internal tools. Our post on edge device zero-days this month makes the same case for appliances.
• Turn off what you do not use. Each optional plugin in this list (Modoboa driver, SquirrelMail import, markasjunk) is code you can remove from the attack surface without waiting for anyone.
• Limit what the server can reach. Egress filtering would have made the NAT64 SSRF bypass mostly irrelevant before the fix existed.
• Keep ImageMagick on a short leash. A restrictive policy.xml is cheap and outlives any single Roundcube bug.
• Rebuild, do not patch in place. For container deployments, pin by digest, rebuild from the new tag and redeploy. In-place edits inside a running container disappear on restart.
• Patch the stack together this week. If you are already rebuilding PHP images or hosts after PHP2Shell, bump Roundcube in the same change. Our October incidents roundup lists the other moving parts.

Zero-Day Discovery and Gold

Two Safeguard capabilities relate to the habit this post argues for, and we want to be exact about what they are.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh, a paid service, provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

We have not confirmed that Gold holds records or hardened builds for these Roundcube CVEs, so we do not claim it. The habit these capabilities support is the right one here: look up the safe version quickly, pull patched and signed components from a curated source, and rebuild fast.

Where Safeguard fits

Safeguard is a software supply chain security platform. For a Roundcube release like this, the honest fit is inventory, matching and rebuilding the parts you build yourself:

• Finding Roundcube where you build it. If Roundcube arrives through Composer or inside a container image you build, safeguard scan --dir . scans the repository, safeguard scan --image <name> scans the image and safeguard scan --sbom <file> scans an SBOM, with results written as JSON under ./output. The platform shows which projects contain a given component and version, which answers "where is 1.6.19 still running" across many repositories at once. Our post on using SBOMs in incident response covers that workflow.
• Matching against vulnerability databases. Now that the 20 CVE records exist, Safeguard matches them against your components. Reachability analysis helps rank findings by whether your code calls the vulnerable paths.
• Policies and gates. Policies evaluated in the platform can stop a build that still carries a Roundcube version you have decided not to ship.
• Autonomous remediation. When a fixed version exists, fix pull requests can bump the dependency or image tag. It ships switched off by default.
• The Safeguard CLI assistant. It can edit a Dockerfile, compose file or composer.json, then run your build and tests, asking before each command under the permission mode you choose (/permissions: Ask, Accept edits, Plan, Auto, Strict). safeguard exec runs the same work in CI.

Where Safeguard does not help: it does not patch Roundcube installed by a hosting panel, an appliance or a hosted mail service; that fix comes from the vendor. It does not read your web server or IMAP logs for CRLF injection attempts, and it does not configure ImageMagick policy or egress filtering on your hosts. A Roundcube copied onto a server by hand, outside any repository, image or SBOM you scan, will not show up until you bring it into one of those.

When you are ready to try it, download Safeguard and read the CLI documentation.

Common mistakes and troubleshooting

• Checking the git tree for the version. At the release tag, iniset.php in git says 1.6-git. Only the release tarball sets 1.6.20. Check the installed files, not a checkout.
• Pulling the image but not restarting. A new latest image does nothing until the container is recreated. Use docker compose up -d or your orchestrator's rollout, then check the version inside the running container.
• Upgrading the package but serving another copy. Servers with both a distribution package and a hand-installed tarball often serve the tarball. Confirm the web server's document root points where you think it does.
• Assuming "authenticated only" means low priority. CVE-2025-49113 needed a login and still went to KEV. Webmail logins are among the most phished credentials there are.
• Waiting for a 9.0 score. Nothing in this batch is scored above 8.5 by the CNA. A severity threshold of 9.0 would leave all 20 open.
• Backporting a single fix. Carrying only the session fix on 1.6.19 leaves 19 other bugs and puts you on a build nobody else tests.
• Breaking thumbnails with an ImageMagick policy. If thumbnails or contact photos stop working, check that the formats you allow match what users upload, and look in Roundcube's errors.log for conversion failures.
• Forgetting bin/installto.sh steps. Copying files without running the update step can leave the database schema or config out of date. Read UPGRADING in the release package.
• Leaving the installer reachable. After an upgrade, make sure the installer directory is removed or disabled, as the install documentation advises. 1.7.5 also adds a way to destroy the installer session and cookie.

FAQ

What did Roundcube 1.6.20 and 1.7.5 fix?

Twenty security issues, the same list in both versions: two IMAP command injection paths, a session object injection primitive, two ImageMagick related issues, an SSRF filter bypass via NAT64, four mail header injection paths, three remote content and CSS bypasses, a CSS proxy size limit, a disabled_actions bypass, a CSRF bypass in mark-as-junk, an XSS in password driver errors, and three password or login related authorization bugs.

Are these vulnerabilities being exploited?

No exploitation has been reported as of 24 October 2026, none appears in CISA's KEV catalog version 2026.10.23, and we found no public proof of concept. That can change quickly for Roundcube, which has 11 earlier entries in KEV.

Do these bugs have CVE IDs?

Yes, now. The release and the oss-security post gave none, but MITRE published CVE-2026-113386 on 20 October and CVE-2026-114714 through CVE-2026-114732 on 22 October. Debian's DSA-6579-1 lists all 20.

Which bug should I worry about most?

Patch everything, but if you need to explain priority, the IMAP command injections (7.1) are reachable by any logged-in user, the inline image header injection (8.5) and the ImageMagick content issue (8.3) carry the highest CNA scores, and the session object injection (7.4) sits in a code area with a KEV-listed predecessor, CVE-2025-49113.

Do I need to be logged in to exploit these?

For most of them, yes, or the victim needs to open a crafted message. Several CVE records use PR:N because the input arrives as received mail. None describes an unauthenticated route to code execution.

Is there a link to PHP2Shell?

Only timing. Both landed in the same weeks and Roundcube runs on PHP, so it makes sense to patch them together. There is no shared bug, and Roundcube's release does not mention PHP2Shell.

I run Debian 12 bookworm. What do I do?

As of 24 October, Debian's tracker marks bookworm's 1.6.5+dfsg-1+deb12u12 as vulnerable with no fixed package. Apply the interim hardening, watch the tracker, and consider moving to an upstream 1.6.20 install or Debian 13 if you cannot wait.

How do I check which version I am running?

On a tarball install, run grep "RCMAIL_VERSION" program/include/iniset.php in the install directory. On Debian, dpkg -l roundcube-core. In a container, run the same grep inside the running container. Expect 1.6.20 or 1.7.5, or the Debian build string 1.6.20+dfsg-0+deb13u1.

Does upgrading change my configuration?

The security fixes do not require configuration changes, but disabled_actions now works as intended, so any action you listed there and relied on through an alias will stop working. SVG and EPS are no longer accepted for contact photo conversion. Back up before upgrading, as the release notes ask.

Is Roundcube 1.5 still supported?

The project's download page lists only 1.7.5 as stable and 1.6.20 as LTS. This batch has no 1.5 release, and the CVE records name only the 1.6 and 1.7 lines. If you run 1.5 or older, plan a move to a maintained branch.

Fix it without waiting for upstream

For Roundcube, upstream has already shipped. The gap that remains is the time between that release and the fixed version running everywhere you build and deploy it.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Roundcube. Each shows a real flow that maps onto the work this release asks of teams that build and ship webmail.

The first demo is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal and asks it to fix a lodash CVE: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For Roundcube you would ask the same assistant to bump the image tag in your compose file from 1.6.19 to 1.6.20, or the Composer constraint to 1.7.5, then run your build and smoke tests, approving each command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is the step that answers "which of our repositories and images still carry an affected Roundcube" across the code you already have checked out.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session. The CLI session appears in the conversation list, you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit; it ends with an upgrade done and tests passing. The same flow fits a Roundcube rollout: point it at the repository that defines your webmail image, let it propose the version bump, and approve the build and test commands one at a time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Security updates 1.6.20 and 1.7.5 released (Roundcube, 19 Oct 2026)
• Roundcube Webmail 1.6.20 release (GitHub)
• Roundcube Webmail 1.7.5 release (GitHub)
• Roundcube releases (GitHub API)
• Roundcube webmail: multiple vulnerabilities prior to 1.6.20 / 1.7.5 (oss-security, 20 Oct 2026)
• Roundcube download page
• CVE-2026-113386 record (CVE.org)
• CVE-2026-114724 record (CVE.org)
• CVE-2026-114727 record (CVE.org)
• CVE-2026-114730 record (CVE.org)
• CVE-2026-114714 to CVE-2026-114732 records (CVE Services API)
• DSA-6579-1 roundcube security update (Debian, 23 Oct 2026)
• Debian security tracker: roundcube
• Debian security tracker: CVE-2026-114724
• Debian bug #1151279: roundcube multiple security vulnerabilities
• roundcube/roundcubemail on Packagist
• roundcube/roundcubemail tags (Docker Hub)
• Roundcube default configuration, 1.6.20 (GitHub)
• Known Exploited Vulnerabilities Catalog (CISA)
• KEV catalog JSON feed, version 2026.10.23 (CISA)
• CVE-2025-49113 record (CVE.org)
• Security updates 1.6.11 and 1.5.10 released (Roundcube, 1 Jun 2025)
• ImageMagick security policy
• RFC 6052: IPv6 Addressing of IPv4/IPv6 Translators

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.