Roundcube CVE-2025-49113: critical post-auth RCE

CVE-2025-49113 is a critical Roundcube Webmail vulnerability rated CVSS 9.9. An authenticated user can inject a malicious PHP object and execute code on the webmail server, escalating from access to one mailbox to compromise of the application. The flaw affects Roundcube 1.1.0 through 1.6.10 and was fixed in 1.5.10 and 1.6.11.

Operational guidance: upgrade Roundcube to the latest supported release, review requests carrying abnormal session parameters and assume that one compromised mailbox can satisfy the attack prerequisite. Authentication is not a strong barrier in an environment exposed to phishing and stolen credentials.

CVE-2025-49113 facts

Attribute	Value
Product	Roundcube Webmail
Vulnerable versions	1.1.0 through 1.6.10
Fixed versions	1.5.10 and 1.6.11
CVSS	9.9 — critical
Requirement	a Roundcube user account
Weakness	PHP object deserialization / object injection
Impact	remote code execution as the web-server account
Public PoC	yes, published by the researcher

Roundcube announced the fixes on 1 June 2025 in its official 1.6.11 and 1.5.10 security release notice. Version 1.5.11 subsequently corrected a PHP 5.5 compatibility regression in 1.5.10; organisations should deploy a current supported release rather than the historical minimum.

How PHP deserialization becomes code execution

Roundcube used PHP unserialize() on state whose structure an authenticated user could influence. Serialization stores an object’s properties, but recreating an object may also invoke class behaviours such as magic methods, destructors and call chains. If the application or dependencies contain a suitable gadget chain, a controlled object can write a file or execute a command.

CVE-2025-49113 involved insufficient parameter-name validation and the way user-controlled data entered session storage. The researcher demonstrated that crafted input could poison stored state and later trigger PHP object injection.

An administrator account is not required. A normal session can come from:

a password captured through phishing;
credential stuffing against a reused password;
a legitimate low-privilege account on a hosting service;
a stolen session or weak SSO flow;
an internal mailbox with minimal privileges.

Why impact extends beyond one mailbox

Roundcube runs on a web server with access to IMAP/SMTP configuration, address books, plug-ins, databases and application secrets. Code running as the PHP account may read configuration, alter accessible files and connect to internal systems.

Architecture-dependent outcomes include:

theft of secrets and other user sessions;
a modified login page harvesting passwords;
access to the Roundcube database and address books;
use of the webmail host as an entry point into the mail network;
persistence through a webshell, plug-in or modified application code;
impersonation of the organisation in subsequent BEC campaigns.

Container isolation and role separation can reduce impact, but many older webmail deployments place application, database access and configuration on one server.

Public PoC and safe confirmation

The researcher released a public CVE-2025-49113 PoC and technical analysis. The repository contains code designed to execute a command and should not be used against production mail.

Safe validation should be version-led:

read the release from application files or the package manager, not only the UI footer;
determine whether the deployment comes from upstream, a Linux distribution or hosting panel;
check for vendor backports in a package with an older-looking version;
build a lab copy with a test mailbox and no corporate data;
monitor the filesystem and PHP process during any harmless proof;
retest and verify file integrity after updating.

Distribution package numbering may remain behind upstream after a backport. The operating-system vendor advisory and package changelog are the source of truth.

Updating and hardening Roundcube

Upgrade to 1.6.11 or later on the main branch or a supported LTS release at least 1.5.10. Because subsequent releases are available, use the current version supported by the project or distribution. Back up configuration and database state, deploy within a maintenance window, and test login, sending, address books and plug-ins.

Additional controls include:

run PHP-FPM as a dedicated unprivileged account;
make application directories read-only except where writes are required;
store credentials outside the webroot;
restrict outbound connections from the web process;
remove unused plug-ins and update Composer dependencies;
enforce identity-layer MFA, rate limits and credential-stuffing protection;
centralise reverse-proxy, application, IMAP, SMTP and operating-system logs.

A WAF may identify some public patterns but should not be the primary control. Serialized chains can be encoded in multiple ways, and authenticated traffic often receives greater trust.

Detection and incident response

Review the vulnerable exposure period for:

unusual authenticated requests and parameters carrying encoded content;
unserialize errors, PHP warnings and sudden session exceptions;
child processes of PHP-FPM not required by Roundcube;
new or changed PHP files, especially in writable directories;
outbound connections from webmail to unknown hosts;
modifications to plug-ins, configuration, cron and system accounts;
access to many mailboxes after one application event;
forwarding rules and sending anomalies consistent with BEC.

For confirmed RCE, isolate the host, preserve disk and logs, rotate application secrets and technical accounts, invalidate active sessions and validate the entire platform. Replacing Roundcube files does not remove a webshell written elsewhere.

Attack surface extends beyond the Roundcube version

The entry prerequisite is an authenticated Roundcube session, but the actual surface includes the full login and PHP runtime chain. Public webmail, SSO, reverse proxies, hosting panels, plug-ins and session storage determine whether vulnerable code is reachable and how far execution can extend.

Inventory every hostname and route serving Roundcube, the release on each node, package origin and whether a distribution backported the fix. Check container image contents, not only a deployment name. In an autoscaling platform, an old image can recreate a vulnerable pod after one live node was correctly updated.

Document the session handler: local files, database, Redis or another backend. The root cause involves manipulated stored state, so location, retention and correlation matter to investigation. Do not open or manually deserialise suspect data in a runtime that might invoke object methods. Perform static analysis on a copy in an isolated environment.

Blast radius depends on the PHP-FPM account, write access to webroot, shared temporary directories, database privileges and IMAP/SMTP secrets. When several sites share one operating-system identity, Roundcube RCE can cross their intended boundary. A configuration containing technical credentials or a master password raises rotation priority.

Confirm exposure safely without the public PoC

Three facts justify the patch decision: a release without a confirmed fix or backport, a reachable Roundcube login and the ability to create an ordinary user session. There is no need to send a serialised object.

Use this safe process:

read the upstream version from application code and the system package release;
compare the distribution’s changelog or advisory with the CVE rather than rely only on semantic versioning;
inspect every replica, image, application backup and staging environment containing copied configuration;
confirm externally which addresses present the Roundcube login;
perform a normal sign-in with a test identity and verify the event reaches proxy, Roundcube and identity logs;
preserve pre-update evidence and repeat the same functional test after deployment.

If SSO fronts the application, assess it against OAuth 2.0 Security BCP and RFC 9700. Weak issuer, audience or session validation might reduce the intended “valid user” prerequisite. Report that as a separate defect rather than part of CVE-2025-49113.

Roundcube incident triage

Use four handling levels:

Level A — fixed release and complete history. Confirm the active package and close after retesting.
Level B — vulnerable release but demonstrably unavailable to untrusted users. Patch, preserve logs and document the access-control boundary.
Level C — vulnerable public instance with no decisive indicator. Hunt across sign-ins, sessions, PHP errors, file integrity and egress.
Level D — PHP child process, altered file, unauthorised data access or BEC. Isolate, perform full IR and rebuild from trusted media after evidence capture.

Authentication does not automatically lower priority. If the organisation experienced phishing, password spraying, infostealers or weak MFA, correlate affected identities with Roundcube requests. Phishing-resistant MFA rollout reduces the chance of satisfying the prerequisite but never replaces the patch.

Do not reset only the mailbox password when host compromise is possible. Isolate the web tier while maintaining mail through another client if feasible. Revoke sessions, rotate app secrets, review system accounts and investigate forwarding rules plus OAuth grants in the mail plane. Follow the broader data-breach response process.

Telemetry and event correlation

Reverse proxies should record time, source, method, path, status, response size and a correlation ID without full cookies or secrets. Roundcube should map an event to its local user and session. PHP-FPM and EDR expose exceptions, file access, child processes and outbound connections.

A high-value alert joins events in a short window: an authenticated session sends unusual parameters, PHP logs deserialisation behaviour or writes a file, and a worker launches a process or new egress. Each item can have a benign explanation alone; together they describe a coherent chain.

File Integrity Monitoring covers Roundcube code, plugins, configuration, PHP startup files, cron and writable directories. Use a trusted package or signed image as the baseline, not the possibly compromised host. Compare hashes, owner, mode, extended attributes and timestamps.

At the mail tier, look for bulk IMAP reads, new forwarding rules, new recipient domains and account use after reset. Exchange and Microsoft 365 telemetry is covered in our Microsoft 365 security guide; on-premises IMAP platforms need corresponding server-side sources.

Hardening the webmail platform

Separate Roundcube from other sites by operating-system identity, PHP pool and preferably container or VM boundary. Webroot and plug-in directories should be read-only during normal operation. Keep only explicitly required paths writable and mount them noexec where supported and compatible.

Restrict PHP egress to IMAP/SMTP, database, DNS and explicitly required services. General Internet access should not be the default. Store secrets outside webroot with minimum ACLs, and limit database identities to the specific schema and operations.

Remove unused plug-ins because they expand PHP code and potential gadget-chain surface. Every extension needs an owner, trusted source, version and update plan. Apply Zero Trust segmentation inside the service boundary: webmail code does not need unrestricted access across every mail-network segment.

Verify remediation and retest safely

After updating, record application-file, package and active PHP-worker versions. Restart according to procedure to clear bytecode/opcache so old workers do not retain vulnerable code. Verify every backend plus the image tag and immutable digest used for deployment.

Functional testing covers sign-in, sign-out, session expiry, send, read, address book and every business-critical plug-in. Security validation can confirm in a lab that the formerly dangerous parameter-name class no longer poisons session state, using a harmless marker without a gadget chain or command execution. Do not replay the public PoC in production.

Retesting should also prove that PHP cannot write executable content into webroot, egress is limited and a controlled PHP warning reaches the SIEM. The absence of a browser error is not proof. Closure requires fixed code on every replica, clean artefacts, rotation where compromise was possible and working detections.

CVE-2025-49113 decision tree

Is the release at least 1.6.11/1.5.10 or covered by a documented backport? If no or unknown, patch and preserve evidence. If yes, confirm active code on every node.
Was a vulnerable instance available to Internet users or a broad population? If yes, begin hunting. If no, document the enforcing access layer.
Were any identities compromised during exposure? Correlate their sessions and application events even if passwords have since changed.
Did PHP spawn a process, alter code or make unusual egress? If yes, perform full IR and rebuild from a trusted image. If no, assess telemetry completeness.
Was forwarding/BEC or multi-mailbox access observed? Extend investigation to the mail platform, identity plane and affected recipients.

Prioritising the issue

Despite requiring an account, the flaw scores 9.9 because the lowest application privilege is enough to affect another security component—the server. For public webmail, compromise of one account is a realistic prerequisite. Priority rises further when Roundcube shares a host with a hosting panel, database or other websites.

Organisations should combine patching with web application penetration testing and identity protection. Testing can validate tenant separation, plug-ins, sessions and server boundaries without uncontrolled use of a public exploit.