CVE-2026-40203 in Dovecot Pro
Summary
by MITRE • 08/28/2026
When IMAP compression is enabled, the same compression state is reused across responses in a session, so response sizes depend on both attacker-supplied mail and other mail in the same mailbox. An attacker that can send mail to a user and can also observe the sizes of that user's IMAP traffic can confirm whether the body of a small message matches a guessed text. Recovery of arbitrary unknown content was not demonstrated, but the attack can disclose whether a secret-like message body matches a candidate. Disable IMAP compression. Update to non-vulnerable version. No publicly available exploits are known.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability described involves an information disclosure flaw within the Internet Message Access Protocol (IMAP) implementation when compression is enabled for email sessions. This issue stems from how the protocol handles data compression state across multiple responses during a single connection. Specifically, the IMAP server reuses the same compression context or dictionary for subsequent messages in a session rather than resetting it between individual emails. While this optimization improves performance by reducing bandwidth usage and processing overhead, it introduces a side-channel risk where the compressed size of an email becomes dependent not only on its own content but also on the existing state derived from previously transmitted mail within that same mailbox or session context.
This design choice allows for a sophisticated traffic analysis attack known as a compression oracle attack. An adversary who possesses the ability to send emails to a target user and simultaneously monitor the network traffic associated with that user's IMAP sessions can exploit this dependency. By carefully crafting small, specific messages containing guessed text fragments, an attacker can observe how these new emails compress in relation to the existing mailbox content. If the guessed text matches actual data already present or likely to be present in the target's mailbox, the compression algorithm will produce a smaller output size due to higher redundancy and better dictionary matching. Conversely, if there is no match, the compressed payload will be larger because the new data lacks sufficient overlap with the existing context.
The operational impact of this vulnerability centers on the ability to confirm whether specific secret-like content exists within a user's mailbox without directly accessing or decrypting the message body itself. Although full recovery of arbitrary unknown content was not demonstrated in public disclosures, the capability to verify matches against candidate texts effectively allows an attacker to perform dictionary attacks or brute-force guesses against sensitive information such as passwords, security questions, or confidential phrases embedded in email bodies. This transforms what appears to be a performance optimization into a significant privacy and confidentiality breach, particularly for users who communicate high-value secrets via email.
From a classification perspective, this vulnerability aligns with CWE-209: Generation of Error Message Containing Sensitive Information, as it leaks data through side channels rather than direct exposure. It also relates to CWE-358: Improperly Implemented Security Check for Condition, specifically regarding the failure to isolate compression contexts between distinct logical units of communication. In terms of offensive security frameworks like MITRE ATT&CK, this technique falls under T1048: Exfiltration Over Alternative Protocol and potentially T1071: Application Layer Protocol, as it leverages standard IMAP traffic patterns to infer sensitive data without triggering typical intrusion detection systems that look for explicit exfiltration attempts.
Mitigation strategies primarily involve disabling IMAP compression entirely if the environment does not strictly require bandwidth optimization at the cost of potential privacy risks. Organizations should review their mail server configurations and ensure that any third-party clients or proxies do not enforce compression in a way that maintains state across unrelated sessions or user contexts where possible. Updating to non-vulnerable versions of the affected software is critical, as vendors typically address such side-channel vulnerabilities by resetting the compression dictionary for each new message or session. Until patches are applied, administrators should consider network-level protections and monitor for anomalous traffic patterns that might indicate active exploitation attempts against high-value targets.