Summary
- CVE-2026-48842 affects Roundcube installations using the virtuser_query plugin.
- The flaw can permit SQL injection before authentication and is now being actively exploited.
- Fixed releases have been available since May, leaving remaining exposure concentrated in unpatched deployments.
Attackers are exploiting a Roundcube Webmail vulnerability that was patched in May, turning an older software flaw into a current incident risk for organisations that still run affected installations.
Roundcube fixed CVE-2026-48842 in versions 1.6.16 and 1.7.1. The high-severity vulnerability affects the built-in virtuser_query plugin and can allow SQL injection before a user has authenticated.
The Canadian Centre for Cyber Security has since warned that the flaw is being actively exploited, adding urgency for organisations that did not deploy the May updates or later releases.
Affected software includes Roundcube 1.6.x before 1.6.16 and the 1.7 branch before 1.7.1 when the vulnerable plugin is in use. Installations that do not enable virtuser_query are not exposed through this particular path.
The flaw arises from the way user-controlled input is processed before it is incorporated into database queries used to map virtual usernames to mail accounts. Crafted input can bypass intended escaping and alter the resulting SQL statement without requiring valid credentials.
Successful exploitation can expose or modify information accessible to Roundcube’s database account. The precise impact depends on how the installation is configured, what information sits in the database and which permissions the application holds.
Those variables mean the vulnerability should not be described as automatically providing access to every mailbox or to the underlying operating system. Its risk comes from allowing an unauthenticated attacker to cross the database boundary before ordinary login controls have succeeded.
Roundcube is widely deployed as a browser-based interface for email and is bundled into hosting environments used by large numbers of smaller organisations. That distribution creates a long tail of installations that may not follow the same patch cycle as centrally managed enterprise services.
Older web applications can remain reachable for months because they are embedded in hosting platforms, maintained by third parties or simply absent from the asset inventories used by security teams. An organisation may have patched its primary mail server while overlooking the internet-facing webmail application sitting in front of it.
The move into active exploitation also shows why vulnerability age is a poor proxy for urgency. Attackers often adopt flaws after patches and technical details have been available for some time, particularly where exposed systems remain easy to discover.
By late September, the vulnerability had been public for roughly four months. That period gave administrators time to update, but it also gave researchers and attackers time to study the flaw and build reliable exploitation methods.
Plugin state complicates remediation because version information alone does not completely describe exposure. Administrators need to know both whether the vulnerable release remains installed and whether virtuser_query is enabled on a public-facing instance.
Once exploitation has begun, updating also becomes part of an incident response process rather than simply routine maintenance. Installing a corrected release removes the vulnerable condition but cannot establish whether an attacker used it before the update.
Roundcube has issued several security releases since the May fix, meaning organisations still on vulnerable versions are now behind more than one maintenance cycle. Current supported releases contain the correction as well as subsequent security changes.
The campaign reinforces the role of webmail as security-sensitive infrastructure. Even where an organisation relies on a separate mail server or cloud service behind it, the web interface remains part of the authentication and data access path.
For exposed Roundcube systems, the relevant questions are now whether the vulnerable plugin was reachable, how long an affected release remained online and whether database or application logs show activity consistent with exploitation before remediation.
