CVE-2024-34055
Description
Cyrus IMAP before 3.8.3 and 3.10.x before 3.10.0-rc1 allows authenticated attackers to cause unbounded memory allocation by sending many LITERALs in a single command.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
Cyrus IMAP before 3.8.3 and 3.10.0-rc1 allows authenticated attackers to exhaust server memory via many LITERALs in a single command.
Vulnerability
Cyrus IMAP server versions before 3.8.3 and 3.10.x before 3.10.0-rc1 contain a memory exhaustion vulnerability in the handling of IMAP LITERALs. The IMAP protocol allows command arguments to be LITERALs of negotiated length; the server allocates memory to receive the content before instructing the client to proceed, and the allocated memory is released only after the entire command has been received and processed. Commands such as SEARCH accept an unlimited number of arguments, each of which can be a LITERAL. By sending a single command with many LITERALs, an authenticated attacker can cause unbounded memory allocation, potentially exhausting server memory [1][2].
Exploitation
An attacker must be authenticated to the Cyrus IMAP server. The attacker sends a single IMAP command (e.g., SEARCH) containing a large number of LITERAL arguments. The server allocates memory for each LITERAL as it is received, and does not release that memory until the entire command is fully processed. By crafting a command with many LITERALs, the attacker can trigger continuous memory allocation, leading to memory exhaustion [1][2].
Impact
Successful exploitation results in denial of service due to memory exhaustion. The server may run out of memory, with consequences depending on the system's out-of-memory (OOM) policy. This can cause the Cyrus IMAP process to crash or become unresponsive, affecting email service availability [1][2].
Mitigation
The vulnerability is fixed in Cyrus IMAP 3.8.3 and 3.10.0-rc1 [1][2]. Two new configuration options in imapd.conf have been introduced to limit resource consumption: maxargssize (default unlimited) limits the overall length of a single IMAP command, and maxliteral (default 128K) limits the length of individual IMAP LITERALs. Deployments should upgrade to the fixed versions and configure these limits according to their system resources and client usage patterns. Note that the APPEND command's message literal is already limited by maxmessagesize, not by these new options [1][2].
AI Insight generated on May 25, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
7- Range: <3.8.3 and >=3.10.0-rc1? Actually the description says before 3.8.3 and 3.10.x before 3.10.0-rc1. So affected: <3.8.3 and >=3.9.0? Actually 3.10.x before rc1. So version_range should express that. Let's use: <3.8.3, >=3.10.0-rc1? That's not right. Better: before 3.8.3 and before 3.10.0-rc1 for 3.10.x. But for simplicity: <3.8.3 and <3.10.0-rc1. I'll put it as: <3.8.3, <3.10.0-rc1
- osv-coords5 versionspkg:rpm/almalinux/cyrus-imapdpkg:rpm/almalinux/cyrus-imapd-libspkg:rpm/almalinux/cyrus-imapd-utilspkg:rpm/almalinux/perl-Cyruspkg:rpm/opensuse/cyrus-imapd&distro=openSUSE%20Tumbleweed
< 3.4.8-1.el9+ 4 more
- (no CPE)range: < 3.4.8-1.el9
- (no CPE)range: < 3.4.8-1.el9
- (no CPE)range: < 3.4.8-1.el9
- (no CPE)range: < 3.4.8-1.el9
- (no CPE)range: < 3.8.4-1.1
Patches
0No patches discovered yet.
Vulnerability mechanics
AI mechanics synthesis has not run for this CVE yet.
References
5- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/CJZQAE3XC2GBCE5KSTWJ5A6QYANFWGFB/mitrevendor-advisory
- lists.fedoraproject.org/archives/list/package-announce%40lists.fedoraproject.org/message/WVZHUZDU4MGTTZJRNACTMSKXLNMMRLJ6/mitrevendor-advisory
- github.com/cyrusimap/cyrus-imapd/commit/ef9e4e8314d6a06f2269af0ccf606894cc3fe489mitre
- www.cyrusimap.org/dev/imap/download/release-notes/3.10/x/3.10.0-rc1.htmlmitre
- www.cyrusimap.org/imap/download/release-notes/3.8/x/3.8.3.htmlmitre
News mentions
0No linked articles in our index yet.