Roundcube Webmail CVE-2026-114721

Exploitation requires that the administrator has explicitly configured the non-default 'disabled_actions' setting to block one or more actions; on a default install this list is empty and there is nothing to bypass. The attacker must be a remote but authenticated Roundcube user (PR:L), and must know the deprecated alias name of a disabled action, since the pre-patch check compared only the requested action name without resolving aliases. Limiting factors: no effect without the disabled_actions hardening in place, valid credentials are mandatory, no user interaction of a victim is needed, and the impact is confined to reaching an otherwise-restricted action (integrity-only, no data disclosure or denial of service). Affected versions are Roundcube Webmail before 1.6.20 and 1.7.x before 1.7.5.

This is a genuinely low-priority issue, and the signals are internally consistent rather than conflicting. The CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:N, base 3.1) describes a network-reachable but high-complexity, authenticated-only flaw with no confidentiality or availability impact and only limited integrity impact - matching CWE-863 (Incorrect Authorization). No EPSS score, CISA KEV listing, or public exploit was provided in the input; exploitation status is therefore 'no public exploit identified at time of analysis.' Critically, the flaw only has any effect when an administrator has explicitly populated the non-default 'disabled_actions' configuration setting - on a default Roundcube install this setting is empty, so there is nothing to bypass. The real-world risk is low: the attacker must already hold valid webmail credentials, the target must have deliberately hardened specific actions via disabled_actions, and the only payoff is regaining access to an action the admin tried to hide (not privilege escalation or data theft beyond what that action already exposes). This is a defense-in-depth hardening fix, not an externally weaponizable vulnerability.

In a Roundcube deployment where an administrator has restricted certain actions via the disabled_actions setting, an authenticated user who should not reach a blocked action instead requests that action through its deprecated alias name, which the pre-patch access check failed to resolve, thereby reaching the disabled functionality. No public exploit code was identified in the provided data, and the high attack complexity reflects the need for valid credentials plus a specifically-configured (non-default) disabled_actions list.