Roundcube Webmail Hardening Guide: Patching and Sessions

Roundcube has 11 entries in the CISA Known Exploited Vulnerabilities catalog, and in the best known campaigns a user only had to open an email for state-sponsored attackers to start reading the mailbox. Roundcube is a PHP webmail client that sits in front of an IMAP and SMTP server and is widely used by universities, hosting providers and government bodies. Because it renders untrusted HTML from anyone on the internet inside an authenticated session, cross-site scripting flaws in its message sanitiser turn directly into mailbox theft. This guide covers how authentication and sessions work in Roundcube, the configuration secrets that matter, plugins that hold credentials, logging and detection, and a hardening baseline with patching at its centre. It is for mail, web platform and security operations teams. Settings come from Roundcube's config/defaults.inc.php and plugin documentation; confirm them for your version.

Key takeaways

Patching is the primary control. Most KEV listed Roundcube flaws are XSS in message rendering (CVE-2023-5631, CVE-2024-37383, CVE-2024-42009, CVE-2025-68461) that no configuration setting fully prevents. Run the current stable or LTS release and patch within days.
Roundcube does not own the password. Users log in with their IMAP credentials, which Roundcube keeps encrypted in the session with des_key. Change the default key and the legacy cipher, and put MFA in front, through OAuth2 with your identity provider or a reverse proxy.
Default logging is minimal. log_logins and smtp_log are false by default. Turn them on and forward them, or you will not see password spraying or mail being sent from a hijacked session.
Close the installer and private directories. Remove installer/ after setup, keep enable_installer false, and serve only the public_html directory so config/, logs/ and temp/ are never reachable.
Plugins carry machine credentials. The password plugin, LDAP address books and OAuth settings hold database DSNs, bind passwords and client secrets. Scope each one and keep them out of version control.

How identity and access work in Roundcube

Roundcube has no user directory of its own. At login it passes the username and password to the configured IMAP server (imap_host, default localhost:143); if IMAP accepts them, Roundcube creates a local user record (when auto_create_user is true) for preferences and identities, and stores the password in the PHP session, encrypted with des_key, so it can reuse it for IMAP, SMTP (smtp_user = '%u', smtp_pass = '%p') and ManageSieve. Whoever controls a valid Roundcube session can therefore read, send and filter mail as that user.

Login method	How it works	Security notes
IMAP password (default)	Form login, credentials checked by the IMAP server	No built-in MFA. Rate limiting is `login_rate_limit` (default 3 failed attempts per minute).
OAuth2 / OpenID Connect	`oauth_provider` with a client ID and secret, discovery via `oauth_config_uri`; the IMAP server must accept XOAUTH2 or OAUTHBEARER tokens	Lets your identity provider enforce MFA and conditional access. PKCE is on by default (`oauth_pkce = 'S256'`); keep `oauth_verify_peer` true; backchannel logout is supported.
Kerberos or HTTP authentication plugins	`krb_authentication`, `http_authentication` take identity from the web server	Security depends on the front-end authentication and on IMAP trusting it; often involves a master user on the mail server.
Autologon plugin	Logs users in from another application	Example code; a misconfigured trust between applications becomes a login bypass.

Session settings

Setting	Default	Recommended
`session_lifetime`	10 minutes of inactivity	Keep short; match your policy for mail access
`session_samesite`	null (PHP default)	`'Strict'` or `'Lax'`
`force_https` / `use_https`	false	`force_https` true, or `use_https` true behind a TLS terminating proxy (only one of them)
`ip_check`	false	true where users do not roam between networks mid session
`trusted_host_patterns`	empty (accepts any Host header)	List your hostnames; the comment in defaults warns a forged Host header can be used to collect usernames and passwords
`proxy_whitelist`	empty	Your reverse proxy addresses, so forwarded client IPs in logs and rate limits are trustworthy
`x_frame_options`	`sameorigin`	Keep, or `deny`
`login_autocomplete`	0	Keep 0 on shared computers
`display_product_info`	1 (product name)	0 so the login page does not advertise the product or version

Admin roles and privileged access

Roundcube has no administrator console. Administrative power sits in four places, and each needs to be treated as privileged access.

The host and configuration files: anyone who can edit config/config.inc.php can point IMAP at their own server, load plugins or read secrets. Restrict the file to the web server group, read only, and deploy it from configuration management.
The installer: installer.php helps create configuration and tests connections. The defaults file warns that enabling it can expose sensitive config data. Leave enable_installer false and delete the installer directory in production.
The Roundcube database: the db_dsnw account holds users, preferences, contacts, identities and (with database session storage) encrypted session data. Give it rights only on the Roundcube schema.
Mail server master users: SSO plugins often rely on a Dovecot master user or proxy authentication that can open any mailbox. Keep that credential on the mail server side, scoped to the Roundcube host, and monitored.

Integrations, API tokens and service accounts

A Roundcube deployment holds several non-human credentials. Store them in a secrets manager or root owned include files, not in Git, and rotate them on staff changes. See the Secrets Management Guide.

Secret	Setting	What it protects	Hardening
Session encryption key	`des_key` (default `rcmail-!24ByteDESkey*Str`)	IMAP passwords stored in sessions	Generate a random key per installation; set `cipher_method` to `AES-256-CBC` (default is the legacy `DES-EDE3-CBC`), with a key of the length that cipher requires
Database DSN	`db_dsnw`	Roundcube data and sessions	Dedicated account, schema only rights, TLS to the database
OAuth client secret	`oauth_client_secret`	Token exchange with the identity provider	Confidential client, exact redirect URIs, rotate with the IdP
Password plugin DSN or LDAP bind	`password_db_dsn`, LDAP driver bind settings	Ability to change any user's mail password	Stored procedure or narrowly scoped bind account; keep `password_confirm_current` true; never store passwords with `password_algorithm = 'clear'` (the sample default)
LDAP address book bind	`ldap_public` entries	Directory lookups	Read only account limited to the attributes needed, LDAPS
Enigma PGP keys	Enigma plugin key storage	Users' private keys if server side PGP is enabled	Decide deliberately whether server side private keys are acceptable

The password plugin in particular turns a webmail XSS into an account takeover path: a script in the victim's session can submit a password change. Keep password_confirm_current enabled so the current password is required.

Logging and detection

Roundcube writes to logs/ by default (log_driver = 'file') or to syslog. Enable log_logins (successful and failed logins to userlogins.log) and smtp_log (sent messages to sendmail.log), keep errors.log, and forward all of them with web server access logs to your SIEM. Correlate with IMAP and SMTP logs on the mail server, where the real authentication decision happens.

Signal	Source	Maps to
Many failed logins across many accounts from few IPs	`userlogins.log`, IMAP logs	Password Spraying, T1110.003
Session used from a new IP or user agent without a new login	Access logs, `ip_check` failures	Steal Web Session Cookie, T1539
Bulk message fetches or exports, new forwarding or Sieve redirect rules	Access logs (`_action=` parameters), ManageSieve logs	Remote Email Collection, T1114.002
Inbound mail with SVG, odd HTML attributes or obfuscated links aimed at a few users	Mail gateway, IMAP content scanning	Spearphishing Attachment, T1566.001, JavaScript, T1059.007
Browser connections from webmail sessions to unknown domains	Proxy or CSP violation reports	Second stage loaders, as in the Winter Vivern campaign
New PHP files or changed files under the install path	File integrity monitoring	Web Shell, T1505.003, after server-side flaws such as CVE-2025-49113

ESET's write-up of CVE-2023-5631 describes a crafted email whose HTML contained an SVG element with an onerror handler; opening the message in Roundcube was enough to load a second stage that listed folders and sent mail to the attacker. Use the published indicators in threat hunts after any Roundcube XSS disclosure. See the Winter Vivern Threat Actor Profile Guide and the APT28 (Fancy Bear) Threat Actor Profile.

Metrics

Patch latency: days from a Roundcube security release to production (target under 7, under 2 for KEV listed flaws).
Version coverage: percentage of instances on the current stable or LTS release.
MFA coverage: percentage of logins through OAuth2 or an MFA enforcing proxy.
Logging coverage: instances forwarding login and SMTP logs to the SIEM.
Secret hygiene: instances still on the default des_key or DES-EDE3-CBC (target zero).

Hardening baseline

Inventory and patch: find every Roundcube instance, including those bundled with hosting panels and mail appliances, which often lag upstream. Move to the current stable (1.7.x at the time of writing) or LTS (1.6.x) release and subscribe to Roundcube security announcements. Check every KEV listed CVE: CVE-2017-16651, CVE-2020-12641, CVE-2020-13965, CVE-2020-35730, CVE-2021-44026, CVE-2023-5631, CVE-2023-43770, CVE-2024-37383, CVE-2024-42009, CVE-2025-49113 and CVE-2025-68461.
Serve only the public directory: point the document root at public_html (or, on older layouts, deny web access to config/, temp/, logs/, bin/, SQL/ and installer/), and remove the installer.
Enforce TLS everywhere: HTTPS with HSTS for users, and TLS on IMAP (993 or STARTTLS on 143), SMTP submission (587) and the database.
Set secrets: random des_key, cipher_method AES-256-CBC, dedicated database account, password plugin with hashed storage and current password confirmation. Changing des_key invalidates existing sessions, so do it in a maintenance window.
Harden sessions: trusted_host_patterns, session_samesite, force_https, proxy_whitelist, short session_lifetime, display_product_info = 0.
Add MFA: integrate OAuth2 with your identity provider where the mail server supports token authentication, or place an MFA enforcing reverse proxy in front. Restrict webmail to known networks where your users allow it.
Reduce rendering risk: keep show_images = 0 or 3 (trusted senders only) so remote content is not loaded automatically, consider prefer_html = false for high risk user groups, and strip or quarantine SVG and HTML attachments at the mail gateway. Roundcube's install notes say a Content Security Policy must allow 'unsafe-inline' 'unsafe-eval' in script-src, so CSP limits where scripts can connect rather than stopping inline execution.
Minimise plugins: enable only the plugins you need, keep them at the version shipped with your release, and remove example plugins such as autologon.
Turn on logging: log_logins, smtp_log, syslog forwarding, and file integrity monitoring on the install path.
Test and roll back: stage each upgrade on a copy with the same plugins and skins, run bin/update.sh as documented in the upgrade notes, and keep the previous release directory and a database backup so you can switch back quickly.

Small and large deployments

A small organisation or hosting customer may get most value from moving to a managed mail service or keeping Roundcube automatically updated by the hosting panel, plus MFA at the proxy. Large providers and public bodies should run Roundcube behind a WAF and reverse proxy with MFA, central logging, a written patch SLA tied to KEV additions, and threat hunting for the indicators that follow each disclosed XSS campaign. See the Email Security Guide for the wider mail stack.

Common misconfigurations

Old versions bundled in panels: instances shipped with control panels or appliances stay years behind upstream and carry KEV listed XSS and RCE flaws.
Default des_key: the published default key protects nothing if an attacker obtains session data from the database or a backup.
Installer left in place: a reachable installer exposes configuration and connection tests.
Whole install directory as web root: exposes logs (with usernames and IPs), temp files and configuration backups.
No MFA on internet facing webmail: single factor IMAP passwords are reused and sprayed; the web login is then the easiest route into mail.
Logging off: without log_logins and smtp_log, investigators cannot tell which accounts were accessed or what was sent after an XSS campaign. See the Cross-Site Scripting (XSS) Prevention Guide for the underlying flaw class.

Framework mapping

Control area	NIST SP 800-53 Rev. 5	NIST CSF 2.0	CIS Controls v8.1	ATT&CK
Patching and KEV remediation	SI-2	PR.PS-02, ID.RA-01	7.4, 7.7	T1190
MFA and session protection	IA-2, SC-23	PR.AA-03	6.3	T1110.003, T1539
Secure configuration and secrets	CM-6, IA-5, SC-28	PR.PS-01	4.1, 3.11	T1505.003
Content filtering of mail	SI-3, SI-8	DE.CM-09	9.6, 9.7	T1566.001, T1059.007
Logging	AU-2, AU-12	PR.PS-04, DE.CM-09	8.2	T1114.002

Practitioner checklist

Every Roundcube instance is inventoried and on a supported stable or LTS release, with all 11 KEV listed CVEs confirmed fixed.
Only public_html is web reachable and the installer is removed.
des_key is unique and random and cipher_method is AES-256-CBC.
Logins pass through MFA, via OAuth2 or a proxy.
trusted_host_patterns, force_https, session_samesite and proxy_whitelist are set.
Password plugin uses hashed storage, a scoped credential and current password confirmation.
log_logins and smtp_log are on and forwarded; file integrity monitoring covers the install path.
Mail gateway strips or quarantines risky SVG and HTML content for webmail users.
A threat hunt runs after each new Roundcube XSS disclosure using published indicators.

Roundcube Webmail Hardening Guide: Patching, Sessions, Secrets and XSS Defence