CVE-2025-49113: Roundcube Webmail post-authentication remote code execution, actively exploited
The short version: Roundcube Webmail has a PHP object-deserialization flaw (CVE-2025-49113) that lets an authenticated user turn a crafted request into code execution on the mail server. Patched versions shipped in June 2025, a working exploit followed almost immediately, and it's now in CISA's KEV catalog. The authentication requirement is a real speed bump — but webmail credentials are cheap, so treat this as patch-now. Steady hands, but move.
At a glance
| Fact | Detail |
|---|---|
| Our severity take | High — in practice (see below) |
| CVSS v3.1 (NVD) | 8.8 — High · AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H |
| CVSS (MITRE, CNA) | 9.9 — Critical · AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
| EPSS | 94.74% · 99.85th percentile (2026-07-17) |
| In CISA KEV? | Yes — remediation was due 2026-03-13 |
| Known exploited? | Yes — public exploitation shortly after disclosure |
| Vulnerability type | CWE-502 deserialization of untrusted data → remote code execution |
| Requires authenticated session? | Yes — any authenticated user (post-auth) |
| Affected | Roundcube Webmail before 1.5.10 and 1.6.x before 1.6.11 |
| Fixed in | 1.5.10 · 1.6.11 |
What you need to know
The flaw lives in program/actions/settings/upload.php: the _from parameter in a URL isn't validated, which lets an attacker smuggle a serialized PHP object into the application. When Roundcube deserializes it, the attacker gains control over object internals and, through that, code execution on the server hosting the mail app.
- It needs a login, but not much of one. Any authenticated account will do — and webmail is exactly the place where credentials are phished, sprayed, or reused. Roundcube's own XSS bugs (several also in KEV) exist to harvest those sessions.
- It's the mail server. Code execution there reaches mailboxes, stored credentials, and whatever else the host can see.
- It's automatable and public. Exploit code circulated quickly, which is why EPSS sits near the top of the scale.
How serious we see it
High — a notch below the CNA's Critical, and here's the honest reasoning.
NVD scores it 8.8 and MITRE 9.9; the gap is the scope metric. Either way, the mechanics are remote code execution on a mail server, and it's confirmed in KEV. What keeps our real-world take at High rather than Critical is the authentication precondition: an attacker needs a valid session first. That's a genuine barrier — but a low one for webmail, so we don't let it lull anyone. The reassuring part is that it's narrow and fixed: two specific version lines, a published patch, and a quick way to tell if it applies to you.
Recommendations
Straight from Roundcube's advisory and CISA:
- Patch now. Upgrade to 1.6.11 or 1.5.10 (or later).
- If you couldn't patch immediately, restrict access. Limit the Roundcube host to trusted networks until the update is in place.
- Assume credential exposure. Given how webmail is attacked, enforce MFA, and hunt for anomalous logins and unexpected server-side processes if you ran an affected build while exposed.
- If you find evidence of code execution, respond. Rotate credentials and secrets reachable from the host and investigate for persistence.
- Confirm your exposure first. Verify whether you run an internet-facing Roundcube instance and which version.
How BreachRisk sees it
BreachRisk works the problem from the outside in. From little more than your domain it discovers internet-facing Roundcube Webmail, fingerprints the version from the application's own resources, and flags exposure tied to KEV-listed vulnerabilities like this one — pushed to the top of your results because it's actively exploited. We identify and flag the exposed, affected version; we don't exploit it. That continuous, attacker's-eye view means an exposed Roundcube build is already on your map when a bug like this breaks.