The Roundcube RCE on CISA's KEV List Will Never Be Patched on 1.4, 1.3, or 1.2 — CVE-2025-49113
On February 20, 2026, CISA added CVE-2025-49113 — a remote code execution vulnerability in Roundcube Webmail — to its Known Exploited Vulnerabilities catalog, with a remediation due date of March 13, 2026. The fix had existed since June 1, 2025, when the Roundcube project shipped it in versions 1.5.10 and 1.6.11. A KEV listing eight months after the patch is CISA saying something specific: the servers still getting exploited are the ones that were never going to apply it.
Many of them can't. The fix for CVE-2025-49113 exists in exactly two places — 1.5.10 and 1.6.11 — and nowhere else, ever. Three Roundcube version lines that sit squarely inside the affected range — 1.4, 1.3, and 1.2 — were already past end of life when the advisory landed, and no fixed point release was ever issued for any of them. If your webmail runs one of those lines, this CVE is not a patching task on your backlog. It is a permanent property of the software until the install is upgraded or retired.
What the vulnerability lets an attacker do
CVE-2025-49113 is a PHP object deserialization flaw in Roundcube's file-upload handler. Per NVD and CISA's catalog entry, the _from request parameter is not validated before it reaches the deserialization path, allowing an authenticated user to achieve remote code execution on the server. MITRE, scoring it as the CVE Numbering Authority's assignment, rates it CVSS 9.9; NVD/NIST scores it 8.8. Both agree on the substance: near-total compromise, low complexity, no user interaction. And the advisory carries one detail that reframes the whole thing — the vulnerable code path had been present in the codebase for roughly a decade. Every Roundcube line this site tracks from the 1.x era shipped it.
The word "authenticated" is doing less protective work here than it appears to. The required credential is an ordinary webmail login — the credential class most exposed to phishing and credential stuffing on the internet. A Roundcube install typically fronts many mailboxes; any single one of them is a sufficient entry point. What this vulnerability does is convert the most commonly stolen credential there is into code execution on the mail server — the machine that holds every other user's mail, password-reset flows for every service those users touch, and, on shared hosting, often much more than mail. One phished mailbox in, everyone's mailbox out.
That shared-hosting angle is why this CVE's blast radius is wider than its install-base numbers suggest. Roundcube is the default or bundled webmail in major hosting control panels, including cPanel and Plesk, which puts it in front of an enormous number of organizations that never consciously chose it and may not know they run it. If your mail is hosted and your webmail login page looks like Roundcube, the version question in the next section applies to you — or to whoever operates the panel for you.
Thirty seconds: which Roundcube are you running?
If you can log in, check Help → About in the webmail interface — most installs display the version there. On the server, the version constant lives in the codebase (RCMAIL_VERSION, defined in program/include/iniset.php):
grep RCMAIL_VERSION /path/to/roundcube/program/include/iniset.phpIf your webmail is provided by a hosting panel, the panel's package manager reports the bundled Roundcube version. Anything at 1.5.10–1.5.15, 1.6.11 or later, or any 1.7 release is patched against this CVE. Anything else lands in one of two very different rows in the table below.
Which versions get a fix — and which are permanently exposed
The affected statement from our Exploited & Unpatchable feed entry, per NVD: all versions from 0 up to (excluding) 1.5.10, plus the 1.6 series through 1.6.11 — fixed only in 1.5.10 and 1.6.11. Dates below are from our tracked Roundcube lifecycle data, current as of the verification pass on August 12, 2026.
| Version line | Status | Released | End of life | Fix for CVE-2025-49113? |
|---|---|---|---|---|
| 1.7 | Supported | May 10, 2026 | — | Not affected |
| 1.6 | Supported (LTS) | Jul 25, 2022 | — | Yes — 1.6.11+ |
| 1.5 | EOL | Oct 18, 2021 | May 10, 2026 | Yes — 1.5.10, before the line's EOL |
| 1.4 | EOL | Nov 9, 2019 | Dec 10, 2023 | Never |
| 1.3 | EOL | Jun 26, 2017 | Jul 28, 2022 | Never |
| 1.2 | EOL | May 21, 2016 | Oct 18, 2021 | Never |
Three notes on that table. First, the 1.4 line's final release was 1.4.16, shipped the day the line went EOL in December 2023 — eighteen months before this advisory existed. There is no 1.4.17, and there never will be. The same holds for 1.3 (final: 1.3.17) and 1.2 (final: 1.2.13); the ancient 1.1 and 1.0 lines fall inside NVD's from-zero affected range too. Second, the 1.5 row is the odd one out: it received the fix in 1.5.10 while still supported, then reached end of life on May 10, 2026 — so a patched 1.5 install is safe from this CVE but now runs a line that will never see the next fix. Third, "supported" still is not "patched": a 1.6 install below 1.6.11 is inside the affected range until it takes a point update it is fully entitled to.
The upgrade-or-decommission decision
For installs on the 1.6 line, there is no decision — take the point update. Any release from 1.6.11 onward carries the fix, the current release is 1.6.18, and 1.6 is the designated LTS line. For 1.7, you were never affected. For a patched 1.5 install (1.5.10–1.5.15), you are safe from this CVE but standing on a line that went EOL in May — fold the move to 1.6 or 1.7 into the same planning cycle rather than waiting for the next advisory to force it.
For installs on 1.4, 1.3, or 1.2, the honest framing is the one from the table: there is no patch for you, and there never will be. The fix for CVE-2025-49113 is not an update you apply — it is an upgrade you undertake. Three moves, in order of preference:
1. Upgrade to a supported line — the real fix. Roundcube's own releases document the upgrade path, and the project maintains an in-tree upgrade script. The work concentrated in old-line jumps is the usual PHP-application set: PHP version requirements, database schema migration, plugin and skin compatibility. It is a bounded project — and a much smaller one than the incident response that follows a mail-server compromise. If your Roundcube arrives via cPanel or Plesk, the move may be as simple as updating the panel's bundled package to a current build — check which version your panel actually ships before assuming you are covered.
2. Constrain exposure while the upgrade is scheduled. The exploit needs a valid login and a route to the web interface. You cannot remove the credentials — they belong to your users, and phishing ensures some fraction is always in circulation — but you can shrink the route: put the webmail interface behind a VPN or IP allowlist if your users can tolerate it, enforce multi-factor authentication in front of Roundcube so a phished password alone is no longer a working entry ticket, and watch authentication logs for the credential-stuffing patterns that precede exploitation. These are real mitigations. None of them is a patch.
3. If mail has moved on, decommission. A meaningful share of old Roundcube installs are leftovers — webmail stood up years ago on a server whose users have long since migrated to hosted mail. An EOL webmail install that nobody actively uses is pure attack surface with zero business value. If that describes yours, the fix costs nothing: turn it off.
The full verified entry — affected statement, KEV dates, fixed versions, and sources to CISA, NVD, and the Roundcube advisory — is in our Exploited & Unpatchable feed, with a free JSON feed at /exploited-and-unpatchable.json. Every entry is verified against the vendor's own advisory before it goes in; "unpatchable" means the documentation says so, not that we infer it. We track Roundcube and 480+ other products against vendor-verified dates — every Roundcube line with live status, or check any version in seconds.
Roundcube 1.4 currently carries an EOL Risk Score™ of 50/100 — medium risk, recalculated at every site build from EOL recency, attack surface, CISA KEV exposure, and extended-support availability. Per-version scores and dates are on the Roundcube lifecycle page.
The right response comes down to one question: how many more years does this system need to run? Under a year, extended support (where it exists) is usually cheaper than an emergency migration. One to three years, migrate — support fees paid repeatedly cost more than doing the project once. Indefinitely, migrate now and plan the next one before it surprises you. Extended support is often the more expensive choice over a multi-year horizon — a bridge, not a destination. And if this deadline feels like vendor caprice, it isn’t — why end of life is inevitable for every version, with the receipts.
Frequently Asked Questions
What is CVE-2025-49113?
A remote code execution vulnerability in Roundcube Webmail: a PHP object deserialization flaw in the file-upload handler, reachable through the unvalidated _from request parameter. It requires an authenticated webmail session — any valid mailbox login is enough. MITRE rates it CVSS 9.9; NVD/NIST rates it 8.8. The vulnerable code path had been present in the codebase for roughly a decade. Fixes shipped on June 1, 2025 in Roundcube 1.5.10 and 1.6.11, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on February 20, 2026, confirming exploitation in the wild.
Is Roundcube 1.4 still supported?
No. Roundcube 1.4 reached end of life on December 10, 2023, and its final release was 1.4.16. No fixed point release for CVE-2025-49113 was ever issued for the 1.4 line, and none is coming — the fix exists only in 1.5.10 and 1.6.11. A 1.4 install cannot patch this vulnerability in place; the only fix is an upgrade to a supported line.
Does CVE-2025-49113 affect Roundcube 1.6?
Yes — 1.6 releases before 1.6.11 are affected. NVD lists the affected range as all versions from 0 up to (but excluding) 1.5.10, plus the 1.6 series through 1.6.11, with the fix landing in 1.6.11 itself. The difference from the older lines is that 1.6 is still supported, so the fix is a routine point update: current 1.6 releases (1.6.18 as of this writing) include it. If your 1.6 install is at 1.6.11 or later, you are patched against this CVE.
Which Roundcube versions will never receive the fix?
Three version lines: 1.4 (end of life December 10, 2023, final release 1.4.16), 1.3 (end of life July 28, 2022, final release 1.3.17), and 1.2 (end of life October 18, 2021, final release 1.2.13). All three sit inside NVD's affected range, and no fixed point release was ever issued for any of them. As of our last verification pass, no backport exists — and per our feed policy, the entry would be removed if one ever appeared. The even older 1.1 and 1.0 lines fall inside the affected range too.
It requires authentication — doesn't that make it low risk?
No. The required credential is an ordinary webmail login — the exact credential class most exposed to phishing and credential stuffing. A Roundcube install typically serves many mailboxes, and any one of those accounts is a sufficient entry point. The vulnerability then converts a single compromised mailbox into code execution on the mail server itself, exposing every other mailbox and credential it holds. CISA's decision to put this CVE on the KEV catalog means the chain is not theoretical: exploitation has been observed in the wild.
Related
- All Roundcube versions with live status · Roundcube 1.4 — dates and risk score
- Exploited & Unpatchable — the verified feed of KEV-listed vulnerabilities that end-of-life versions will never get fixes for, including this entry
- The TeamCity RCE that will never be patched on nine version lines — the same mechanic on a CI server, one KEV cycle later
- Confluence's three-wave CVE exposure — what repeated KEV listings do to an EOL install base
- Why End of Life Is Inevitable — the economics behind "fixes ship only in current lines," for every vendor