Net::IMAP: Denial of Service via incomplete raw argument validationCVE-2026-47241

### Summary 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. ### Details `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_search` * `search_keys` for `#sort`, `#thread`, `#uid_sort`, and `#uid_thread` * `attr` for `#fetch` and `#uid_fetch` The 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: * The `{0}\r\n` literal prohibits other arguments (such as a quoted string) from spanning both commands * It will be sent without the space delimiter which is required between arguments. * The second command's tag will not be a valid argument to any of the vulnerable commands. So the server _should_ respond to the first command with a `BAD` response, which will raise a `BadResponseError`. But, 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. ### Impact 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. ### Mitigation 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: * Validate that user input to the affected command arguments does not end with `"}"`. * Use of `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.

Quoted source text, attributed separately from HOL analysis.