Cyrus IMAP CVE-2026-61908

Exploitation requires a valid, authenticated user account on the target Cyrus IMAP server - unauthenticated attackers cannot reach the vulnerable code path (CVSS PR:L). The JMAP protocol must be enabled and reachable on the server; deployments that use only IMAP/LMTP and have not configured JMAP are not exposed. The attacker must know or guess a valid email ID to construct the H<emailid>-<index> blob ID format, and must supply an index value beyond the actual blob_headers array length for that message (CVSS AC:H). The confidentiality impact is limited and non-deterministic: the heap memory adjacent to the array may or may not contain sensitive material at the time of the request. Organizations limiting JMAP access to internal, trusted users are largely protected from opportunistic abuse.

The provided CVSS 3.1 vector (AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N, score 3.1 Low) is consistent with the described vulnerability: reachable over the network but requiring a valid authenticated session and deliberate construction of a malformed blob ID, which warrants AC:H. The impact is strictly limited to partial confidentiality loss - the content of leaked heap memory is non-deterministic and may or may not contain sensitive data. There is no integrity or availability impact. No CISA KEV entry exists and no public exploit code has been identified, making this a theoretical information-disclosure risk rather than an active exploitation concern. Even a mid-sized municipal IT team in leszno operating a shared Cyrus IMAP deployment should treat this as a standard patch-cycle item rather than an emergency response, as exploitation requires a legitimate account and intentional abuse of the JMAP blob ID format. The EPSS signal is absent from the provided data, which is consistent with the low observed exploitation pressure suggested by the score and access requirements.

An authenticated JMAP user issues a blob download HTTP request to the Cyrus IMAP JMAP endpoint, supplying a crafted blob ID such as H<valid-emailid>-99999 where 99999 exceeds the actual number of header entries for that message. The server dereferences the out-of-bounds index into the blob_headers array, reads heap memory past the array's end, and returns the resulting bytes in the download response. The attacker receives a dump of adjacent heap content whose sensitivity depends on what the process had recently allocated nearby. No public exploit code has been identified.