Roundcube – the self-hosted webmail client bundled with cPanel, Plesk, DirectAdmin and countless independent mail servers – has patched two stored cross-site scripting flaws that need zero clicks to fire. With CVE-2026-54432, a malicious attachment MIME type executes JavaScript the moment the attachment-validation warning page renders. With CVE-2026-54433, a script hidden in a plain-text email runs silently as soon as the victim opens the message in plain-text view. No download, no click, no attachment opened – just reading the email. Both were reported by Bohdan Kurinnoy of Samsung R&D Institute Ukraine and fixed in Roundcube 1.6.17 and 1.7.2, released July 5, 2026, with public CVE detail landing July 9. The same release also closes two SSRF-filter bypasses and TNEF (winmail.dat) denial-of-service bugs.

What the Vulnerability Is

CVE-2026-54432 — stored XSS via unescaped attachment MIME type. When Roundcube shows its attachment-validation warning page, it prints the attachment's MIME type string without properly escaping it. An attacker sends an email whose attachment carries a crafted MIME type containing an HTML/JavaScript payload. When the warning page renders that string, the script executes in the victim's authenticated webmail session. Because the payload fires on page load – not on a click or a download – it is a genuine zero-click vector.

CVE-2026-54433 — zero-click stored XSS in plain-text rendering. Roundcube's plain-text message renderer fails to fully neutralize injected markup, so an attacker can embed script in an email that executes when the victim simply views the message in plain-text mode. This is especially nasty because plain-text view is the mode security-conscious users switch to precisely to avoid active content – the flaw turns a defensive habit into the trigger.

Both live in the message-display path, so the attacker's only "action" is sending an email. The victim's only "action" is reading it.

Also fixed in 1.6.17 / 1.7.2: two new server-side request forgery (SSRF) filter-bypass cases involving specific local-address URLs, an infinite-loop DoS in the TNEF (winmail.dat) decoder, a DoS via crafted compressed-RTF size values in TNEF attachments, and several password-plugin issues stemming from session-injected usernames.

Why It Matters

  • Webmail is a credential goldmine. A script running in a logged-in Roundcube session can read mail, exfiltrate messages, hijack the session, or pivot to change account settings – the classic path to full mailbox takeover.
  • Zero interaction removes the human safety net. User-awareness training does nothing here; there's no suspicious link to avoid and no attachment to decline. Delivery of the email is the attack.
  • It's everywhere on shared hosting. Roundcube ships as the default webmail in cPanel, Plesk and DirectAdmin stacks, so a single vulnerable server can expose every hosted mailbox at once.
  • Plain-text mode is no longer a shield. CVE-2026-54433 specifically defeats the "read it as plain text" precaution, so even careful users are exposed.
  • Internet-facing instances are prime targets. Self-hosted webmail exposed to external senders can be hit by anyone who knows a valid address.

Am I Affected?

  • You run self-hosted Roundcube Webmail on the 1.6.x or 1.7.x branch at any version below 1.6.17 / 1.7.2.
  • Your Roundcube login is reachable by external email senders (i.e., it receives mail from the internet) – which is essentially every production mail server.
  • You use a hosting control panel (cPanel, Plesk, DirectAdmin) that provides Roundcube as its webmail interface – the bundled copy is affected until the panel vendor ships the patched build.
  • Check your version: the footer of the Roundcube login/about page shows it, or run grep RCMAIL_VERSION in your Roundcube program/include/iniset.php / index.php, or check your package (dpkg -l roundcube\* / rpm -q roundcubemail).

What to Do About It: Step-by-Step

1. Upgrade to the fixed release for your branch. This is the primary remediation. On the 1.7 branch → upgrade to 1.7.2; on the 1.6 branch → upgrade to 1.6.17.

# Debian / Ubuntu
sudo apt update && sudo apt install --only-upgrade roundcube roundcube-core

# RHEL / Alma / Rocky (EPEL)
sudo dnf upgrade roundcubemail

For a manual/tarball install, download the matching release from roundcube.net and follow the upgrade script:

# from your Roundcube root, after extracting the new release over a backup
bin/installto.sh /path/to/roundcube

2. Back up first. The vendor explicitly recommends a full data backup (database + config + attachments) before applying the update. Snapshot the DB:

mysqldump roundcubemail > roundcube-backup-$(date +%F).sql

3. If you're on a control panel, patch through the panel. Update cPanel/WHM, Plesk, or DirectAdmin to the release that bundles Roundcube 1.6.17 / 1.7.2 rather than hand-editing the panel-managed copy. Check the panel vendor's changelog/advisory for the exact build.

4. Verify the running version after upgrade – confirm it reports 1.6.17 or 1.7.2, not a cached older build.

5. If you cannot patch within hours, reduce exposure now:

  • Restrict access to the Roundcube URL (IP allow-listing, VPN, or a reverse-proxy auth gate) so untrusted senders can't reach authenticated sessions as easily.
  • Ensure a strong Content-Security-Policy is enforced on the webmail vhost as defense-in-depth against XSS execution.
  • Consider temporarily disabling webmail access for exposed instances until patched.

6. Assume messages already delivered could carry payloads. After patching, be alert for signs of session abuse (unexpected forwarding rules, filter changes, or logins). Rotate credentials for any account you suspect was targeted.

Quick-Win Checklist

  • Identify your Roundcube branch and version (login footer / package query).
  • Upgrade to 1.7.2 (1.7.x) or 1.6.17 (1.6.x).
  • Take a full DB + config backup before upgrading.
  • If using cPanel/Plesk/DirectAdmin, update via the panel to the patched build.
  • Confirm the running version is the fixed release.
  • Enforce a strict CSP on the webmail vhost as an XSS backstop.
  • Restrict/gate the webmail URL if patching is delayed.
  • Watch for suspicious forwarding rules, filter changes, or logins on exposed mailboxes.

Sources