Roundcube fixed eight flaws in one release and named none of them. The exploited one was line three
The 24 May release notes list eight fixes in one line each, with no CVE, no severity and no CVSS. Four months later one of them, a pre-authentication SQL injection in a plugin, is being exploited.
By Parminder Kumar Sharma · · 7 min read
Eight lines, no identifiers, and one of them mattered
On 24 May 2026 Roundcube published versions 1.6.16 and 1.7.1. The announcement lists eight security fixes, each in a single line, each crediting a reporter. It carries no CVE identifiers, no severity ratings and no CVSS scores. Its advice is one sentence: "We strongly recommend to update all productive installations of Roundcube 1.6.x and 1.7.x with this new versions."
The third line reads: "Fix pre-auth SQL injection in virtuser_query plugin via preg_replace backslash escape bypass", reported by skull.
A hundred and twenty days later, that is the one being exploited. It is now CVE-2026-48842, scored 8.1, an unauthenticated SQL injection in Roundcube 1.6.x before 1.6.16 and 1.7.x before 1.7.1.
What that does not establish. It does not establish that Roundcube did anything unusual: publishing a release with a list of fixes and letting CVE assignment follow is common practice in open source, and the project did ship the fix and did tell people to update. It does not establish that CVE identifiers would have changed any particular administrator's behaviour. It does not establish how many installations are exploited, because nobody has published a number. And it does not establish who is exploiting it or how they found it, although the fix is a public commit and has been readable since May.
What it does establish is a gap between the information an administrator had on the day the fix shipped, which was eight one line descriptions, and the information they needed, which was that one of those eight was reachable before login.
What the release actually said
These are the eight fixes as the announcement describes them, in its own order and wording. Nothing here has a CVE, a score or a severity attached.
The security fixes in Roundcube 1.6.16 and 1.7.1, as published on 24 May 2026
| # | The fix, as written | Reported by |
|---|---|---|
| 1 | Stored XSS, HTML and CSS injection in the subject field of the draft restore dialog | Anand Jogawade |
| 2 | CSS injection bypass in the HTML sanitiser via an SVG animate attribute | wooseokdotkim |
| 3 | Pre-auth SQL injection in the virtuser_query plugin via a preg_replace backslash escape bypass | skull |
| 4 | SSRF bypass via specific local address URLs | not credited |
| 5 | Local and private URL fetch bypass when remote resources were not allowed | Orange Cyberdefense |
| 6 | Bypass of remote image blocking via CSS var() | Geame |
| 7 | Pre-auth arbitrary file delete via redis or memcache session poisoning bypass | valent1 |
| 8 | Code injection: support for code evaluation in the LDAP autovalues option removed | Glendaenri |
Read that list as an administrator with a maintenance window to justify. Two of the eight say pre-auth, which is the single most important word on the page, and it appears in the middle of a list where everything is formatted identically. Nothing ranks them. Nothing says which of the eight is the reason to move tonight rather than at the weekend.
The one that is now being exploited, line three, has a quality that makes it worse than it reads. It is in a plugin. virtuser_query resolves a username to a mail address by running a database query, and it is configured, not universal. So the honest answer to "are we affected?" is not in the release notes either: it is in your own configuration file, and a good many operators inherited that file from a predecessor.
What the CVE record adds, and when
CVE-2026-48842 was published on 25 May, the day after the release, and reads: "Roundcube Webmail 1.6.x before 1.6.16 and 1.7.x before 1.7.1 has Pre-authentication SQL injection in the virtuser_query plugin via a preg_replace() backslash escape bypass." CWE-89. The score is 8.1, high, and the vector is AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H.
Attack complexity is rated high. That is what holds an unauthenticated, network reachable, fully impactful SQL injection at 8.1 rather than 9.8. High complexity in CVSS means conditions outside the attacker's control have to line up, which for an escaping bypass usually means a particular configuration or input handling path.
It is a defensible score and it is also the kind of score that loses an argument with a change board. Eight point one is a number that fits comfortably inside "we patch highs monthly".
The catalogue that knows Roundcube well
Roundcube is not an obscure target. The CISA Known Exploited Vulnerabilities catalogue contains eleven Roundcube entries, going back to 2021 and running through to two added in February 2026. Cross site scripting appears seven times. There is a deserialisation flaw, a file disclosure, a remote code execution through a configuration setting, and one previous SQL injection.
CVE-2026-48842 is not in that catalogue, in the release fetched for this briefing, four days after a national cyber centre updated its advisory to warn that attackers are abusing it.
That is not a criticism of CISA, which catalogues on its own evidence and on its own schedule. It is a warning about a habit. If your vulnerability process waits for a KEV entry before it treats something as urgent, you have outsourced your triage to an organisation whose remit is United States federal networks, and you will regularly be several days or several weeks behind.
The two facts side by side
| Measure | Value |
|---|---|
| Roundcube entries in the KEV catalogue | 11 |
| Earliest, CVE-2017-16651, added | 3 November 2021 |
| Most recent, two entries, added | 20 February 2026 |
| Is CVE-2026-48842 in the catalogue? | No, as of catalogue version 2026.09.24 |
| Days from the fix to the exploitation warning | 120 |
What to do about it
Take this with you
In the order worth doing
- Establish which Roundcube version you run, including any instance a hosting provider runs on your behalf, and update to at least 1.6.16 or 1.7.1. The current releases are later again.
- Check whether the virtuser_query plugin is configured in your installation, because that determines whether this specific flaw applies to you.
- Because the flaw is pre-authentication, treat exposure as the primary control: put webmail behind a reverse proxy, restrict by network where you can, and rate limit the login path.
- Look for evidence rather than assuming: unusual query errors in the database log, authentication attempts with malformed usernames, and new or altered rows in user tables.
- If you cannot patch immediately, disable the plugin if you do not need it, which removes the affected code path rather than mitigating around it.
- Stop treating an absent KEV entry as absent risk. Add national CERT advisories to whatever feeds your patch decisions, because in this case a national centre warned before the catalogue did.
- For any product where the vendor publishes fixes without identifiers, subscribe to the release feed itself rather than waiting for a vulnerability database to catch up.
The question this leaves
There is a reasonable defence of how Roundcube handled this, and it is worth stating. A small open source project ships fixes when they are ready, credits the people who found them, and tells everyone to update. Assigning CVEs, arguing scores and writing advisories is work, and it is work that does not fix anything. The project did the part that fixes things.
But the release notes are the only artefact that exists at the moment a fix ships, and for four months they were the only thing an administrator had. During those four months, the fix itself sat in a public commit, which is a complete description of the flaw for anyone willing to read a diff. The asymmetry is the familiar one: the attacker's information arrives at commit time and the defender's arrives when somebody writes an advisory.
So the question, and it applies to every piece of open source in your estate: for the projects you depend on, does your patching decision start when the release is published, or when somebody else has finished describing it for you?
Sources
- PrimaryThe release announcement itself, used for the eight fixes, their wording and the absence of CVE identifiersRoundcubeaccessed 2026-09-25
- PrimaryThe CVE record, used for the description, the score and vector, the CWE and the affected versionsNIST National Vulnerability Databaseaccessed 2026-09-25
- PrimaryThe Known Exploited Vulnerabilities catalogue, used to count Roundcube's prior entries and to confirm this CVE is not among themCISAaccessed 2026-09-25
- Reported bySecondary coverage of the exploitation reports, used for the fact that warnings were issued and by whomSecurityWeekaccessed 2026-09-25
