Roundcube published 1.7.3 and 1.6.18 on August 9, security updates to its current and LTS branches. Both carry the same eleven security fixes, and the project recommends updating every production installation. For anyone running a hosting fleet, two details matter more than the list itself. The release notes carry no CVE identifiers. And cPanel, which ships Roundcube to hosting fleets as a bundled package, has not picked the update up yet.

Both of the usual signals are silent. A host that relies on vulnerability scanners keyed to CVE numbers will see nothing, and a host that waits for its panel vendor is, on the last three releases, waiting between five and nine days.

What the Eleven Fixes Cover

The project lists the eleven flat, with no severity ratings attached to any of them, so the ordering below is ours rather than the project’s. The entry that reads heaviest is a remote code execution flaw in the markasjunk plugin, in its cmd_learn driver, reported by a researcher credited as nept1337. It needs qualifying, because the plugin is not part of a default setup. Roundcube ships with its plugin list empty, and cmd_learn is one of several drivers for that plugin, the one that hands a message to an external command such as salearn. The exposure therefore depends on configuration rather than on running Roundcube at all, which makes it a question every host has to answer for its own build rather than a blanket emergency.

The entry with the widest reach is probably the IMAP command injection, found through mail search and a byte-count desynchronization in LITERAL+ handling, reported by Zach Hanley of Horizon3.ai. Desynchronizing a protocol parser from the data it is counting is the kind of flaw that turns a search box into a channel for commands the server was never meant to receive.

The remaining nine are a tour of the places webmail touches untrusted input, and they are worth reading against your own configuration rather than in summary:

  • Two server-side request forgery bypasses. One used carrier-grade NAT and link-local ranges (100.64.0.0/10 and fe80::/10); the other used nip.io and sslip.io hostnames to slip past the local-address check
  • LDAP filter injection through unescaped substitution into the address book search filter
  • Arbitrary Sieve script injection that used a filter rule name to get around the list of disabled actions
  • A password plugin driver leaking an authentication token to a host the user controlled
  • Four content-handling fixes: CSS proxy validation, a remote content blocking bypass via an unclosed url() in a FuncIRI attribute, a stored XSS in the “add to address book” action, and an HTML and CSS sanitization bypass via an SVG animate attribute

Two names are worth noting. Milan Hoppe is credited on four of the eleven. And the stored XSS was reported by Paulos Yibelo from pwn.ai, the same firm credited by WordPress.org for the login screen flaw in its 7.0.3 release last week. That is the same outfit turning up in two different codebases three days apart, though nothing in either advisory says the method was the same.

Roundcube’s Zero-Click Webmail XSS, and How Fast It Reached cPanel

The Missing CVE Numbers Are the Operational Problem

Neither release note assigns a CVE identifier to any of the eleven issues. That is not how the previous round went. When Roundcube shipped 1.6.17 and 1.7.2 in July, the notes named CVE-2026-54432 and CVE-2026-54433, and cPanel’s change log named them again when it folded the fix into a maintenance build.

The practical effect is that the usual detection path does not fire. A scanner that compares installed package versions against a CVE feed has nothing to match. A compliance report that lists open CVEs will show none. A host with a policy of patching anything above a severity threshold has no severity to read, because none was published. The fix is available and the project says to install it, but the machinery fleets use to notice such things is looking for an identifier that does not exist yet.

Identifiers may still be assigned. The point is that they are not there now, in the window when the patch is public and therefore diffable.

Where cPanel Fleets Actually Stand

Days between a Roundcube LTS security release and the cPanel maintenance build that folded it into the cpanel-roundcubemail package, measured from the release dates and the cPanel 134 change log. The 1.6.18 count is still running: one day elapsed as of August 10, with no matching build listed.

cPanel ships Roundcube as the cpanel-roundcubemail package and tracks the 1.6 LTS branch rather than 1.7. Its change log makes the lag measurable, and the most recent one was the longest of the three: 1.6.17 arrived in build 134.0.45 on July 14, nine days after the upstream release.

As of today, 1.6.18 does not appear in the cPanel 134 change log at all, and the newest build listed there is 134.0.49, dated August 5, four days before Roundcube published the fix. cPanel publishes no schedule for it, and on the recent record the wait would run into next week, so a host that waits for the panel is choosing that exposure window rather than having it imposed.

Distributions sit further back again. Debian’s current stable release carries 1.6.17, and its previous stable is on a 1.6.5 package maintained with backported fixes, which is a normal arrangement but means the version string on the box will not match the upstream number.

Roundcube Is Now on a Steady Security Cadence

This is the fifth security release on the 1.6 line since March, and the 1.7 branch, which only opened in May, has already had three. At roughly one security release a month, a host treating webmail as a quarterly task is behind for most of every quarter.

The reasonable response is not alarm, since nothing here is reported as being exploited. It is scheduling. Webmail runs untrusted content from strangers by definition, it sits on the same hosts as everything else, and it is now producing security releases at a rate that a quarterly maintenance window cannot absorb.