GHSA-c4fp-cxrr-mj66: Net::IMAP: Denial of Service via incomplete raw argument validation

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 w