| Package | Affected versions | Patched versions |
|---|---|---|
| net-imap | ≥ 0.6.0, < 0.6.4.1< 0.5.15 | 0.6.4.10.5.15 |
Several Net::IMAP commands accept a raw string argument which is only validated to prevent CRLF injection and then sent verbatim. If this string is derived from user-controlled input, an attacker can force the next command to be absorbed as a continuation of the first command. This will cause the first command to eventually fail, but also prevents it from returning until another command is sent (from another thread). That other command will not return until the connection is closed.
Net::IMAP::RawData was hardened in v0.6.4, v0.5.14, and v0.4.24 to reject string arguments that would smuggle an invalid literal-continuation marker onto the wire (CVE-2026-42257, GHSA-hm49-wcqc-g2xg). But the trailing-marker check uses an incorrect regex which does not match {0} or {0+}, so an attacker-controlled seach criteria or fetch attr string ending in {0} or {0+} passes validation and is sent verbatim. Since these arguments are sent as the last argument in the command, they will be followed by CRLF. Although the CRLF was intended to end the command, the server will interpret it as part of a literal prefix. This consumes the next command the client puts on the socket as additional arguments to the current command.
This affects the following command's arguments:
criteria for #search and #uid_searchsearch_keys for #sort, #thread, #uid_sort, and #uid_threadattr for #fetch and #uid_fetchThe command which contained the attacker's raw data will not be able to complete until the next command is issued. If commands are only sent from single thread, the first command will hang until the connection times out (most likely by the server closing the connection).
If a second command is sent (from another thread), this would allow the server to respond to the first command. This combined command will be invalid:
{0}\r\n literal prohibits other arguments (such as a quoted string) from spanning both commandsSo the server should respond to the first command with a BAD response, which will raise a .
Running one of these products? Scan your site to see whether it exposes a vulnerable version.
Scan my site freeBadResponseErrorBut, since the server never saw a second command, the second command will never receive a tagged response and the thread that sent it will hang until the connection is closed.
This will result in unexpected crashes and timeouts, which could be used to create a simple denial of service attack. This attack will present very similarly to common network issues or server issues which also result in commands hanging or unexpectedly raising exceptions. By itself, this does not allow command injection. But the confusion caused by these errors could lead to other downstream issues, especially in a multi-threaded environment.
Update to a patched version of net-imap which validates that RawData arguments may not end with literal continuation markers.
If net-imap cannot be upgraded:
"}".Timeout or other standard strategies for slow connections and misbehaving servers will also mitigate the effects of this.Extra caution is required when issuing commands from multiple threads. While net-imap does have rudimentary support for issuing commands from multiple threads, the user is responsible for synchronizing that commands are issued in a logically coherent order, and for ensuring that commands are only pipelined when it is safe to do so. Practically, this means that many commands cannot be safely pipelined together, and user code will often need to wait for state changing commands to successfully complete before issuing commands that rely on that state change.