Skip to main content

The Roundcube webmail flaw and the perimeter CISOs keep forgetting

Yanis Grigy, CEO5 min read

In June 2025, a single webmail bug put tens of thousands of mail servers one login away from full takeover. Eight months later, in February 2026, CISA was still adding it to the catalogue of vulnerabilities under active exploitation. That gap is the story.

The flaw is CVE-2025-49113, a critical vulnerability in Roundcube, one of the most common open-source webmail interfaces in Europe. It scores 9.9 out of 10. If you run a mail server for a regulated business, the reason to care is not the patch, which shipped over a year ago. It is that a service nobody had in scope stayed exploitable long enough for a federal remediation deadline to come and go.

A logged-in user could own the mail server

In plain terms, an authenticated Roundcube user could send a crafted request and make the server run their commands. From there an attacker reads every mailbox, harvests more credentials, and pivots into the rest of the estate. The technical root cause was an unsanitised parameter that corrupted the user's session and let attackers inject malicious code.

Two details make this worse than a normal patch cycle. First, the bug lived in the code for over a decade, affecting Roundcube versions 1.1.0 through 1.6.10. Second, once the fix shipped on 1 June 2025, attackers had diffed and weaponised it within 48 hours, then sold the working exploit on underground forums. The Shadowserver Foundation counted 84,925 vulnerable instances as of 8 June 2025, with about 3,600 in France. National cyber agencies, including the Centre for Cybersecurity Belgium, told organisations to patch immediately.

And it was not the only one. When CISA listed CVE-2025-49113 as actively exploited in February 2026, it listed a second Roundcube flaw in the same action: CVE-2025-68461, a cross-site scripting bug scored 7.2, reached through an animate tag in an SVG document and fixed in a December 2025 release. If you patch only the one with the higher score you are still exposed, which is the practical argument for testing the service rather than tracking its CVE list.

Why webmail is the blind spot

The vulnerability requires a valid login. That sounds like a safeguard. It is not. Every employee already has webmail credentials, and phishing hands an attacker the rest. The "authenticated" precondition that looks reassuring on a CVE page is trivial to meet in the real world.

Here is the gap that matters for a security leader. Webmail sits on the public internet, it is used by everyone in the company, and it is almost never in the scope of the annual pentest. Most engagements are scoped to "the product" or "the main app." The mail interface, the VPN portal, the file-share appliance: the boring perimeter services get a version number in an asset list and nothing more. That is exactly where CVE-2025-49113 lived.

Post-auth is not a mitigation when every employee already has a login and phishing hands attackers the rest.

What to do about it

  1. Inventory every internet-facing webmail and portal. You cannot test what you have not listed. Roundcube, and any perimeter service with a login page, belongs on the asset register with an owner and a version.

  2. Patch to 1.6.11 or 1.5.10 and verify the version, and treat this as a tracked obligation rather than a backlog item. The fix shipped on 1 June 2025. Confirm the running version rather than trusting the change ticket. On 20 February 2026, CISA added CVE-2025-49113 to the Known Exploited Vulnerabilities catalog with a federal remediation deadline of 13 March 2026. If you are reading this after that date and cannot name your Roundcube version, that is the finding.

  3. Put webmail in the pentest scope, with credentials. Ask for authenticated, assume-breach testing that starts from a normal user account, not just an unauthenticated scan of the login page. That is the only setup that would have surfaced this class of bug.

  4. Move from an annual snapshot to continuous testing. A once-a-year test taken in March would not have seen a June vulnerability until the following March. If you ship and patch continuously, your testing has to run on the same clock. We wrote more on why the annual pentest breaks for continuously changing systems.

What this means for you

If you are a CISO, RSSI, or GRC lead at a regulated mid-market company, CVE-2025-49113 is a cheap lesson in an expensive blind spot. Two questions to take to your provider on Monday: does our next pentest include the webmail and perimeter services our staff log into every day, and does it test them from an authenticated account rather than the outside only?

I am building Fleuret around exactly this gap: continuous, authenticated testing of the whole perimeter, not a yearly snapshot of the main app.

See Fleuret in action.

Sources


Share this postShare on LinkedIn

The Fleuret newsletter

One email a month. Cyber analysis, DORA, NIS2, and what we learn pentesting our customers' apps.

Privacy Settings

This site uses third-party website tracking technologies to provide and continually improve our services, and to display information according to users' interests. I agree and may revoke or change my consent at any time with effect for the future.