Security Advisory · Published 2026-05-27

Roundcube 1.6.16: Four Vulnerabilities, One Upgrade

The Roundcube team dropped security updates 1.6.16 and 1.7.1 on May 24th. Four vulnerabilities patched in one shot. The highest-priority issue is CVE-2026-48842 - pre-authentication SQL injection with public technical details already circulating. No login required. If your Roundcube login page is exposed, check the version and logs now. If your mail server hasn't been updated, check the version and logs now.

What's in this patch batch

Four CVEs are patched in 1.6.16 / 1.7.1. Review the unauthenticated paths first, then the inbox-triggered issues.

CVE-2026-48842 - CVSS 8.1 - Pre-auth SQL injection. The virtuser_query plugin. Public PoC exists. This is the one.
CVE-2026-48844 - CVSS 7.5 - LDAP code execution. The autovalues config option used to accept PHP code. They removed it entirely. That's not a fix, that's an admission.
CVE-2026-48843 - CVSS 7.2 - SSRF via email CSS. An attacker sends your users a crafted HTML email. Your mail server starts pinging internal addresses. Bypass of the CVE-2026-35540 fix, so if you thought you were safe from the last round, you weren't.
CVE-2026-48848 - CVSS 7.2 - CSS injection via SVG. Lower immediate impact, but it's a phishing lever. "Your session expired" dialogs styled to look native. Not glamorous, but effective.

CVE-2026-48842: the one that needs a proper explanation

Here's what actually happens. The virtuser_query plugin exists to map virtual email addresses to real IMAP logins - useful if your mail setup uses address aliasing. The plugin runs a preg_replace() on the input before it ever reaches the parameterized query. That regex call processes backslash sequences in a way that lets an attacker inject arbitrary SQL.

The attack surface is the login form. No account needed. An attacker who can reach your Roundcube login page can extract the full database contents: user emails, hashed passwords, session tokens, LDAP credentials if stored, and address books. Public writeups already describe the issue, so treat an exposed login page on a vulnerable version as urgent.

The virtuser_query plugin isn't enabled on every Roundcube install. If yours doesn't use virtual user mapping, the specific attack vector for 48842 doesn't apply to you - but you should still upgrade because the other three CVEs don't care about your plugin config.

CVE-2026-48844: why "removed entirely" is the honest answer

The LDAP autovalues feature let sysadmins put PHP expressions in the Roundcube config file to dynamically construct LDAP field values. The idea was flexibility. The reality was that you were handing an eval() to anything that touched the config.

To exploit this, an attacker needs write access to your config - so it's not a zero-click. But if someone got in through 48842 first, planted a webshell, and now can write files, this becomes their persistence layer. It survives plugin reinstalls. It survives Apache restarts. The Roundcube team's answer was to remove the feature entirely, which tells you everything about how confident they were in fixing it any other way.

If your config has autovalues with PHP blocks, upgrading will break that functionality. That's the correct outcome. Rewrite those values as static strings.

Step 1: Check your version right now

From the server (fastest)

# Most common install locations
cat /var/www/roundcube/composer.json | python3 -c "import sys,json; print(json.load(sys.stdin)['version'])"

# Or the blunt way
grep -r "rcmail_VERSION\|RCUBE_VERSION" /var/www/roundcube/program/include/ 2>/dev/null | head -3

# Debian/Ubuntu package
dpkg -l roundcube 2>/dev/null | grep "^ii"

Replace /var/www/roundcube with your actual path. Other common locations: /usr/share/roundcube, /opt/roundcubemail, /home/USER/public_html/webmail.

From the UI

What the version tells you

1.6.16 or 1.7.1: patched. You're done. Scroll to the exploitation check anyway if you ran a vulnerable version recently.
1.6.14 or 1.6.15: CVE-2026-48843 (SSRF) still applies, plus the SQL injection. Upgrade to 1.6.16.
Anything else below 1.6.16 / 1.7.1: all four CVEs. Upgrade now.
1.5.x or older: end-of-life branch. No backport coming. Your only path is 1.6.16.

Step 2: Upgrade

If you're on apt (Debian/Ubuntu)

sudo apt update && sudo apt install roundcube roundcube-core roundcube-mysql
# swap roundcube-mysql for roundcube-pgsql if you use PostgreSQL

dpkg -l roundcube | grep "^ii"

Fair warning: Debian stable repos often lag. If apt still shows an older version, the tarball method below is faster than waiting for the backport.

Tarball install (always current)

# Get the complete package from the official release
wget https://github.com/roundcube/roundcubemail/releases/download/1.6.16/roundcubemail-1.6.16-complete.tar.gz

# Verify the hash against the GitHub release page before extracting
sha256sum roundcubemail-1.6.16-complete.tar.gz

tar -xzf roundcubemail-1.6.16-complete.tar.gz

# Sync new files, keep your config directory intact
rsync -av --exclude='config/' roundcubemail-1.6.16/ /var/www/roundcube/

chown -R www-data:www-data /var/www/roundcube/

Run the database updater - always

cd /var/www/roundcube
php bin/updatedb.sh --package=roundcube --dir=SQL

Some releases don't need schema changes. This script handles it safely either way. Run it every time.

Step 3: Check whether CVE-2026-48842 was used against you

If you ran a vulnerable version on a public server, it's worth a quick log scan. SQL injection via the login endpoint leaves traces.

# Look for anomalous login attempts with encoded payloads
grep "POST.*login\|POST.*index.php" /var/log/apache2/access.log | grep -i "union\|select\|0x\|%27\|--" | tail -50

# Roundcube's own error log
grep -i "sql\|query\|error\|exception" /var/log/roundcube/errors.log | grep "$(date +%Y-%m)" | tail -100

# Any PHP errors around the virtuser plugin
grep -i "virtuser" /var/log/roundcube/errors.log

A clean log doesn't prove you weren't hit - good SQL injection leaves no PHP errors if it succeeds. But unusual POST traffic to the login endpoint with encoded characters is a flag worth investigating.

If you find evidence of exploitation: change all Roundcube user passwords immediately (attackers have the hashed version; if they've had time to crack weak ones, the real credentials are already burned), rotate any LDAP service account passwords Roundcube uses, and audit your mail server for web shells.

One thing most guides skip: SSRF in email means your internal network

CVE-2026-48843 doesn't require your server to be compromised. It requires someone to send your users an email. A lot of Roundcube deployments sit inside corporate networks where the mail server can reach things the internet can't - internal admin panels, Elasticsearch clusters, development databases, CI/CD endpoints.

The attack is: send a crafted HTML email with stylesheet link pointing to http://10.0.0.5:9200/. Your user opens the email. Roundcube renders the CSS. Your mail server fires a request to that internal address. The attacker watches the response or just enumerates what's alive. They don't need your user to click anything - just open the message.

Upgrade patches this. As a belt-and-suspenders measure, consider blocking outbound requests to RFC1918 addresses from your mail server at the network layer regardless of what application-layer sanitization claims to do.

FAQ

I don't use the virtuser_query plugin. Am I safe from 48842?

For the SQL injection specifically, yes - the vulnerable code path is in that plugin and if it's not loaded, the injection point doesn't exist. But the LDAP eval (48844), the SSRF (48843), and the CSS injection (48848) don't depend on that plugin. Upgrade regardless.

My Roundcube is behind a VPN / not public. Does it matter?

Less urgency on 48842 if your login page genuinely isn't internet-accessible and access is tightly controlled. But CVE-2026-48843 and 48848 are triggered by incoming email, which presumably still arrives from the outside. Upgrade anyway - the risk is just lower, not zero.

How do I know if autovalues was in my config?

grep -r "autovalues" /var/www/roundcube/config/

Empty output means you weren't using it. If you get hits, review those config blocks before upgrading so you know what functionality will break.

References

Bottom line

Roundcube is one of those pieces of infrastructure that gets installed, works quietly for years, and never gets looked at again. That's exactly why this matters - a lot of these installs are running on servers nobody checks unless something breaks. The SQL injection has public technical details and requires no login. The SSRF works through your users' inboxes. Both are active operational risk, not theoretical.

The upgrade itself is 10 minutes. The schema update is one command. The only reason not to have done this already is not knowing about it - which is now fixed.