CVE-2026-82973 in docker-mailbox
Summary
by MITRE • 09/29/2026
Improper neutralization of CRLF sequences in IMAP command construction in psyb0t/docker-mailbox before 0.4.13 allows a remote unauthenticated attacker, when bearer-token authentication is not configured, to inject additional IMAP commands into an authenticated upstream mailbox connection via crafted folder, UID, or search values.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/29/2026
The vulnerability identified in psyb0t/docker-mailbox versions prior to 0.4.13 represents a critical input validation failure within the Internet Message Access Protocol implementation. Specifically, the flaw resides in the improper neutralization of Carriage Return Line Feed sequences during the construction of IMAP commands. This class of issue is formally categorized under CWE-93 as Improper Neutralization of CRLF Sequences or HTTP Headers Injection. The root cause stems from insufficient sanitization of user-supplied data that is directly incorporated into protocol-level command strings without adequate escaping or validation mechanisms to prevent line breaks from being interpreted as command delimiters by the underlying mail server software.
In a standard IMAP session, commands are terminated by specific control characters, primarily the carriage return and newline sequence. When an application constructs these commands dynamically using unsanitized input fields such as folder names, unique identifiers for messages, or search criteria parameters, it creates a vector for command injection if those inputs contain embedded CRLF sequences. In this specific instance, the vulnerability allows a remote unauthenticated attacker to exploit this weakness provided that bearer-token authentication is not configured on the target system. The absence of strong external authentication mechanisms leaves the application vulnerable to direct manipulation of its internal protocol logic by any network-accessible actor.
The operational impact of this flaw is severe and multifaceted. By injecting crafted folder, UID, or search values containing CRLF sequences, an attacker can effectively split a single intended IMAP command into multiple distinct commands. This allows the injection of arbitrary IMAP operations that are then executed by the upstream mailbox server on behalf of the authenticated session. Consequently, this leads to unauthorized access to sensitive email data, including reading private communications, deleting messages without authorization, or modifying message flags and metadata. The attacker gains the ability to perform actions typically restricted to legitimate users with valid credentials, thereby compromising the confidentiality, integrity, and availability of the mail system's contents.
From a threat modeling perspective, this vulnerability aligns with ATT&CK technique T1078, specifically Valid Accounts or Default Accounts if default configurations are exploited, allowing an adversary to establish persistence or move laterally within an email infrastructure. The exploitation path involves crafting specific HTTP requests that target the application endpoints responsible for processing IMAP-related parameters. Since the attack requires no prior authentication when bearer tokens are disabled, it significantly lowers the barrier to entry for malicious actors, enabling widespread automated exploitation across vulnerable deployments.
Mitigation strategies must prioritize immediate software updates and configuration hardening. The primary remediation is upgrading psyb0t/docker-mailbox to version 0.4.13 or later, where this input validation flaw has been addressed through proper encoding of special characters within IMAP command construction logic. For environments that cannot immediately upgrade, administrators should enforce bearer-token authentication mechanisms as a compensating control. This ensures that even if the CRLF injection vector is present, an unauthenticated attacker cannot initiate the session required to exploit it. Additionally, implementing strict input validation at the application layer to reject or escape carriage return and line feed characters in all user-supplied fields related to mail operations can provide defense-in-depth against similar injection attacks across other protocol implementations.