Net::IMAP: Command Injection via non-synchronizing literal in "raw" argument

Open Source Vulnerabilities GHSA-8p34-64r3-mwg8

Several Net::IMAP commands accept a "raw data" argument that is sent verbatim after validation to prevent command injection. However, if a server does not support non-synchronizing literals, it may still be possible to inject arbitrary IMAP commands inside non-synchronizing literals. ### Details Raw data arguments support embedded literal values, both synchronizing and non-synchronizing. Non-synchronizing literals can only be safely sent when the server advertises any of the `LITERAL+`, `LITERAL-`, or `IMAP4rev2` capabilities. But raw data arguments do not verify server support for non-synchronizing literals prior to sending. Servers without support for non-synchronizing literals could handle them in several different ways: If a server sees a `"}\r\n"` byte sequence but can't parse the literal bytesize, it _may_ cautiously decide to close the connection, blocking any command injection attacks. However, a server without support for non-synchronizing literals may instead interpret the `"+}\r\n"` as the end of a malformed command line and respond with a tagged `BAD`. In that case, the contents of the literal will be interpreted as one or more new pipelined commands, allowing a CRLF command injection attack to succeed. This affects the following commands' string arguments: * `criteria` for `#search` and `#uid_search` * `search_keys` for `#sort`, `#thread`, `#uid_sort`, and `#uid_thread` * `attr` for `#fetch` and `#uid_fetch` Prior to `net-imap` v0.6.4, v0.5.14, and v0.4.24, raw data arguments were not validated in _any_ way, so they were also vulnerable to this attack. See CVE-2026-42257 (GHSA-hm49-wcqc-g2xg). ### Impact Fortunately, `LITERAL-` is supported by most modern IMAP servers. Even without support for non-synchronizing literals, cautious servers may handle invalid literal bytesize by closing the connection . However, servers which handle a non-synchronizing literal just like any other malformed command will enable this vulnerability. If a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers. ### Mitigation Update to a version of `net-imap` which validates server support for non-synchronizing literals before sending them. If upgrading `net-imap` is not possible: * Explicitly validate user-controlled inputs to prevent embedded non-synchronizing literals unless the server supports them. * For a simpler, more cautious approach: all embedded literals can be unconditionally prohibited, by checking that string inputs do not contain any CR or LF bytes. * Verify that the server advertises any of the `LITERAL+`, `LITERAL-`, or `IMAP4rev2` capabilities before using untrusted string inputs for the affected "raw data" arguments.

Open Source Vulnerabilities CVE-2026-47240

Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to 0.6.5 and 0.5.15, several Net::IMAP commands accept a "raw data" argument that is sent verbatim after validation to prevent command injection. However, if a server does not support non-synchronizing literals, it may still be possible to inject arbitrary IMAP commands inside non-synchronizing literals. A server without support for non-synchronizing literals may interpret the "+}\r\n" as the end of a malformed command line and respond with a tagged BAD. In that case, the contents of the literal will be interpreted as one or more new pipelined commands, allowing a CRLF command injection attack to succeed. This affects criteria for #search and #uid_search; search_keys for #sort, #thread, #uid_sort, and #uid_thread; and attr for #fetch and #uid_fetch. This vulnerability is fixed in 0.6.5 and 0.5.15.