CVE-2025-49113

What it actually does

This vulnerability is an authenticated remote code execution flaw in Roundcube Webmail caused by insufficient validation of the `_from` URL parameter in `program/actions/settings/upload.php`. A low-privileged authenticated webmail user can supply crafted serialized PHP data that is later deserialized by the application, allowing attacker-controlled object chains to execute code in the context of the web server/PHP process. Because the CVSS scope is changed and confidentiality, integrity, and availability impacts are high, successful exploitation can move beyond the user’s mailbox and affect the underlying Roundcube application host and adjacent services reachable from it.

Why it matters to the business

A compromised Roundcube instance can expose email contents, credentials, address books, session data, and sensitive attachments, while also giving attackers a foothold on the mail infrastructure. Because exploitation requires only a valid webmail account, attackers can abuse stolen, phished, or self-registered credentials where registration is available. This issue is listed in CISA KEV with a remediation due date of 2026-03-13, has very high EPSS likelihood, and is reported as actively exploited in the wild, so internet-facing Roundcube deployments should be treated as high-priority exposure even though it is not currently flagged as ransomware-associated.

How an attack unfolds

An attacker first obtains valid Roundcube credentials, commonly through phishing, credential stuffing, password reuse, or abuse of an existing low-privileged mailbox. After logging in, the attacker sends a crafted request to the settings upload action and manipulates the `_from` parameter with malicious serialized PHP content. Because vulnerable Roundcube versions do not properly validate this parameter before deserialization, the application may instantiate attacker-influenced PHP objects and trigger gadget-chain behavior. If a usable gadget chain is present, the attacker can execute commands as the web server user, write files, alter application state, access mail data, harvest configuration secrets, and potentially pivot to the mail server, database, or other internal services accessible from the webmail host. Public reporting tracks this issue in the Q2 2025 vulnerability and exploit landscape and active exploitation has been observed, increasing the likelihood of opportunistic scanning and targeted abuse against exposed Roundcube portals.

How to fix it

Upgrade Roundcube Webmail to a fixed release immediately: use Roundcube 1.5.10 or later for the 1.5 branch, and Roundcube 1.6.11 or later for the 1.6 branch. For source/Git-based deployments, ensure the fix commit `0376f69e958a8fef7f6f09e352c541b4e7729c4d` or a later commit is present. If package-based inventories also report related Ubuntu package exposure, apply vendor fixes where applicable: `schroot` on Ubuntu Pro 16.04 LTS fixed in `1.6.10-1ubuntu3+esm1`, Ubuntu 18.04 LTS fixed in `1.6.10-4ubuntu0.1`, Ubuntu 20.04 LTS fixed in `1.6.10-9ubuntu0.1`, and Ubuntu 22.04 LTS fixed in `1.6.10-12ubuntu3.1`; validate package relevance because the primary vulnerability described here is in Roundcube. If immediate upgrade is not possible, restrict access to Roundcube to trusted networks or VPN, enforce MFA for webmail accounts, disable or tightly control untrusted account access, add WAF rules for suspicious `_from` values on settings upload routes, and monitor for exploitation attempts. Mitigations should be considered temporary because the vulnerable deserialization behavior remains present until patched.

How to confirm the fix worked

Confirm the installed Roundcube version from the application UI, package manager, deployment manifest, or source checkout and verify it is 1.5.10 or later, 1.6.11 or later, or contains commit `0376f69e958a8fef7f6f09e352c541b4e7729c4d`. Review `program/actions/settings/upload.php` or the vendor changelog to ensure the `_from` parameter validation fix is present. Restart or reload the web server/PHP-FPM after upgrade and clear opcode caches if used. Validate that internet-facing asset inventories and vulnerability scanners no longer report vulnerable Roundcube versions. Where a WAF or reverse proxy rule was deployed as a compensating control, test that requests to settings upload endpoints containing serialized-object markers in `_from` are blocked or alerted without affecting normal user profile or settings upload behavior.

Typical attack path

1. Identify an internet-facing Roundcube Webmail instance and determine whether it appears to be running a vulnerable version before 1.5.10 or 1.6.11.
2. Acquire valid webmail credentials through phishing, credential reuse, brute force against weak accounts, or another account-compromise path.
3. Authenticate to Roundcube as a low-privileged user.
4. Send a crafted request to the settings upload functionality containing a malicious `_from` parameter intended to trigger PHP object deserialization.
5. Use the resulting code execution to run commands or write files as the web server/PHP user.
6. Collect Roundcube configuration files, database credentials, session data, mail content, address books, and other locally accessible secrets.
7. Establish persistence or pivot to connected mail, database, or internal systems if additional credentials or trust relationships are available.
8. Clean up obvious request traces or uploaded artifacts where possible.

How to detect it

To determine whether exploitation already occurred, review HTTP access logs from the web server, reverse proxy, load balancer, CDN, and WAF for authenticated requests to Roundcube settings upload functionality with a `_from` parameter, especially values containing URL-encoded PHP serialization markers such as `O%3A`, `C%3A`, `a%3A`, encoded quotes, long encoded payloads, or repeated malformed requests. Correlate suspicious requests with Roundcube session activity, login logs, and account authentication events to identify the user account and source IP used. Examine Roundcube error logs, PHP-FPM logs, web server error logs, and system logs for deserialization warnings, fatal PHP errors, unexpected command execution, child process crashes, or anomalous file-write behavior around the request timestamps. Inspect the Roundcube installation tree and web-accessible directories for newly created or modified PHP files, unexpected plugin files, altered configuration, suspicious timestamps, or files owned by the web server user. Review process execution telemetry, EDR, auditd, or Sysmon-equivalent data for the web server/PHP process spawning shells, interpreters, download utilities, archive tools, mail utilities, or network clients. If compromise is suspected, preserve logs and a filesystem snapshot before remediation, rotate application secrets, and investigate downstream access to mailboxes, databases, and internal services from the Roundcube host.

• program/actions/settings/upload.php
• _from=
• settings/upload.php?_from=
• _task=settings
• _action=upload
• _from=O%3A
• _from=C%3A
• _from=a%3A
• %4f%3a
• %43%3a
• GET /program/actions/settings/upload.php
• POST /program/actions/settings/upload.php
• GET /?_task=settings&_action=upload
• POST /?_task=settings&_action=upload
• GET /index.php?_task=settings&_action=upload
• POST /index.php?_task=settings&_action=upload
• php-fpm: pool
• /bin/sh -c
• /bin/bash -c
• www-data

What your security team should do

• Treat this as urgent for any internet-facing Roundcube deployment because it is KEV-listed, actively exploited in the wild, and has a very high EPSS probability.
• Patch Roundcube to 1.5.10, 1.6.11, or later; for Git deployments verify commit `0376f69e958a8fef7f6f09e352c541b4e7729c4d` or later is deployed.
• Inventory all Roundcube instances, including legacy, test, appliance-bundled, containerized, and mail-hosting control-panel deployments.
• Hunt web, reverse proxy, WAF, PHP-FPM, and Roundcube logs for authenticated requests to settings upload actions containing suspicious `_from` parameters, especially serialized PHP markers such as `O%3A`.
• Review webmail accounts for suspicious logins, unusual source IPs, impossible travel, recent password-spray activity, and newly compromised low-privileged accounts.
• Inspect Roundcube application directories and web-accessible paths for unexpected PHP files, modified application files, or recently created artifacts owned by the web server user.
• Rotate credentials and secrets accessible to the Roundcube application if exploitation is suspected, including database credentials, IMAP/SMTP service credentials, API keys, and administrative passwords.
• Add temporary WAF or reverse-proxy detections for suspicious `_from` values on Roundcube settings upload routes while patching is in progress.
• Enforce MFA and strong password controls for webmail users to reduce the likelihood that the authenticated prerequisite can be met.
• Meet or beat the CISA KEV remediation deadline of 2026-03-13; do not defer exposed systems because exploitation has already been observed.