If you're running Roundcube with the password plugin and the modoboa driver enabled, this CVE demands immediate attention—not because of its Medium severity rating, but because of what sits on the other side of the vulnerability.
The flaw allows an attacker to redirect the Modoboa API token to an attacker-controlled host. The CVSS captures how hard it is to trigger: you need the modoboa driver active and you need to craft session data that influences the destination host. That's a narrow entry gate. But once that token leaves your infrastructure, the severity collapses entirely. A Modoboa token typically has broad permissions across your mail stack—account provisioning, alias management, routing, sometimes DNS. You're not looking at a compromised webmail session. You're looking at potential foundational compromise of your entire mail infrastructure.
Here's what makes this worse: the patch in Roundcube 1.6.18/1.7.3 fixes the entry point, but if that token was already harvested during the window before you patched, you have no way to know. There's likely no audit trail for Modoboa API token usage that would reveal whether the exploit was exercised. Rotating that token should be part of your remediation, not just the Roundcube update.
This vulnerability also sits in what amounts to a forgotten middleware layer. The modoboa driver shipped with Roundcube, probably maintained loosely if at all, deployed by operators who trusted the package without auditing integration code. Nobody explicitly owns security review of this driver. That's not unique to Roundcube—identical patterns have appeared in WordPress plugins, Jenkins integrations, and Squirrelmail. Each time the fix is surgical and correct. Each time the architecture that allowed it stays the same.
Check whether you're running the modoboa driver. If you are, verify your Roundcube version is 1.6.18+ or 1.7.3+, rotate the Modoboa API token as a precaution, and audit what permissions that token holds. Then ask a broader question: what other password plugin drivers are you running with similar integration patterns? The same architectural weakness that produced this flaw probably lives elsewhere in your plugin ecosystem.