Vulnerabilities

On September 21, the Canadian Centre for Cyber Security updated its advisory on CVE-2026-48842 to say the flaw is now being exploited. The bug itself is not new. Roundcube fixed it back on May 24, in versions 1.6.16 and 1.7.1, four months before anyone confirmed attacks against it. A fix that shipped in May stopped looking urgent to a lot of admins somewhere along the way, and the servers that never got around to it are the ones under attack now.

CVE-2026-48842 is a CVSS 8.1 SQL injection in Roundcube Webmail's virtuser_query plugin, and it needs no account at all. It reaches every 1.6.x release before 1.6.16 and every 1.7.x release before 1.7.1. If your Roundcube instance uses that plugin and has not been touched since spring, treat it as exposed today, not as a bug you already dealt with.

How it works

Most Roundcube installs let the mail server itself decide who is allowed to log in. Some hosting setups do it differently: one Roundcube front end serves many mail domains off a shared backend, so instead of asking the mail server "is this a real user," Roundcube looks the login name up in its own database first, to work out which actual mailbox address it maps to. The virtuser_query plugin is what runs that lookup, and it runs before Roundcube has checked a password against anything.

A database only does what the text of the query tells it to do, so before your typed username goes into that query, code is supposed to strip out anything that could change the query's meaning, chiefly backslash characters and quote marks. The virtuser_query plugin does this with a preg_replace() call, a pattern-matching find-and-replace meant to neutralize backslashes in the input. The flaw is in that pattern: certain backslash sequences pass through it unchanged instead of being escaped, so a crafted login name reaches the query with its quote characters still live.

That is what SQL injection means in practice. Input that should stay a fixed value, "check whether a row matches this exact text," instead becomes part of the command, closing one clause and opening another that the attacker wrote. Because virtuser_query fires during the username lookup, this happens before Roundcube has verified any credential, so a visitor with no account and no password can still get the plugin to run their SQL against the mail database.

What attackers are doing

The Canadian Centre for Cyber Security's September 21 update says open source reporting shows the flaw being exploited, without naming specific victims or actors. Coalition, a cyber insurer that runs its own honeypot network, separately reported catching exploitation attempts against the same flaw. Neither source has published a victim count or a timeline of what attackers do after a successful injection, which is normal this early: a SQL injection hands over database access, and what happens with that access, credential theft, forwarding rule changes, resale of mailbox logins, tends to surface later rather than in the attack traffic itself.

What is confirmed is the exposure window. The fix has existed since May 24. Four months is long enough that this flaw likely dropped off patch-cycle dashboards that track "days since disclosure" rather than "still deployed," and it is long enough for scanning tools built against the public advisory to circulate widely by the time anyone bothered to point them at real targets.

What to do

Upgrade to Roundcube 1.6.16 or later on the LTS branch, or 1.7.1 or later on the current branch. Check your version from the Roundcube login screen footer or config/defaults.inc.php, and check whether virtuser_query is loaded at all with grep -n 'virtuser_query' config/config.inc.php, since the plugin has to be active in your $config['plugins'] array for this to affect you.

If you cannot upgrade today, remove virtuser_query from that plugins array and reload the configuration. That plugin is the only vulnerable code path, so taking it out closes the hole immediately. Test a few real logins first, since some hosting setups depend on it for username-to-mailbox mapping, and a login that used to resolve through the plugin will fail without it until you patch and turn it back on.

To check for prior compromise, turn on Roundcube's SQL and session debug logging if it is not already on ($config['sql_debug'] and $config['session_debug'] in config.inc.php, writing to sql.log and session.log in your configured log_dir) and watch for database errors tied to login attempts. On the web server side, grep your access log for POST requests to the login endpoint with backslash-heavy or quote-heavy strings in the username field, which is what a crafted injection attempt looks like on the wire. Separately, pull up your virtual user or mailbox mapping table and look for rows added or changed that no admin can account for, since a working injection can write to the database as easily as read from it.

If you find anything in either place, treat it as a breach of the mailbox credentials that database holds. Rotate stored mailbox passwords, and check every account's mail forwarding rules for ones nobody set up, since a quiet forwarding rule is a common way to keep reading someone's mail long after the original access point gets patched.

The wider issue is inventory tracking, not the code itself. Four months after a vendor fix ships, an attacker still gets a bigger pool of targets to work through, because instances that missed the original patch window rarely get revisited without a reason to look. Our web application penetration tests include exactly this kind of check, testing whether a fix that shipped months ago actually made it onto every instance you run, not just the one someone remembered to update. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: SecurityWeek, Greenbone, Field Effect, Hive Security.