CVE-2026-61910 in Cyrus IMAP
Summary
by MITRE • 09/09/2026
An issue was discovered in Cyrus IMAP before 3.12.4. Mailbox/set let a sharee change a special-use role on shared mailboxes. An authenticated user with maySetKeywords on another user's mailbox could change that mailbox's specialuse annotation. This could allow the sharee to change the shared mailbox to perform the archived, snoozed, or other role, which might cause mail mail to be written to the shared mailbox, sharing more content than intended. (This is likely to be an unusual situation, made more unusual because if the target already has an non-shared mailbox with that role, role duplication suppression will prevent the update.)
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/09/2026
The vulnerability identified in Cyrus IMAP versions prior to 3.12.4 represents a significant authorization flaw within the mail server's handling of shared mailbox permissions and special-use annotations. The core technical issue stems from an insufficient access control check when processing requests to modify mailbox keywords, specifically those related to special-use roles such as archived or snoozed states. In standard IMAP operations, users are granted specific rights over their own mailboxes, but the sharing mechanism allows for delegated permissions where one user may grant another user limited access, often including the ability to set certain flags or annotations known as maySetKeywords. The flaw arises because this permission was incorrectly interpreted to allow a sharee to modify special-use annotations on the owner's mailbox, even though these roles are typically reserved for system-level configuration or explicit administrative actions by the mailbox owner.
From an operational perspective, this misconfiguration enables an authenticated user who has been granted sharing rights with write capabilities to alter the functional classification of another user's shared mailbox. By changing special-use annotations such as archive or snooze, a malicious sharee can force incoming mail intended for other destinations to be delivered into that specific shared folder. This action effectively bypasses the logical separation between personal and shared storage spaces defined by the mailbox owner. The consequence is an unintended expansion of data visibility within the shared context, potentially exposing sensitive correspondence, private communications, or confidential documents to unauthorized parties who have access to that shared mailbox.
The impact of this vulnerability extends beyond simple privacy violations; it introduces a risk of information leakage and potential compliance failures in environments where strict data segregation policies are enforced. Although the scenario is described as unusual due to the specific permission requirements involved, the severity lies in the fact that any user with maySetKeywords access can exploit this logic error without needing higher-level administrative privileges. Furthermore, while there is a mitigation mechanism involving role duplication suppression which prevents updates if the target already possesses an unshared mailbox of the same special-use type, this safeguard does not cover all edge cases or initial states where such conflicts do not exist. Therefore, systems operating with these configurations remain vulnerable to exploitation until patched.
This issue aligns closely with CWE-269, Improper Privilege Management, as it involves an actor exercising permissions beyond their intended scope through a logic error in access control enforcement. Additionally, the technique of manipulating mailbox attributes to influence data flow and visibility can be correlated with ATT&CK T1530, Data from Information Repositories, specifically regarding the exfiltration or unauthorized viewing of stored information by altering repository structures. To mitigate this risk, organizations must upgrade Cyrus IMAP to version 3.12.4 or later where these authorization checks have been corrected to strictly limit special-use annotation modifications to authorized owners only. Until patching is complete, administrators should review sharing policies and restrict maySetKeywords permissions to trusted users who do not require the ability to alter mailbox structural metadata, thereby reducing the attack surface for this specific privilege escalation vector.