From 499be761cf56d0383a3355188ba3e68c3aaee675 Mon Sep 17 00:00:00 2001 From: Al Snow <43523+jasnow@users.noreply.github.com> Date: Wed, 10 Jun 2026 09:38:35 -0400 Subject: [PATCH] GHSA/SYNC: 3 new net-imap advisories --- gems/net-imap/CVE-2026-47240.yml | 85 +++++++++++++++++++++++++ gems/net-imap/CVE-2026-47241.yml | 103 +++++++++++++++++++++++++++++++ gems/net-imap/CVE-2026-47242.yml | 74 ++++++++++++++++++++++ 3 files changed, 262 insertions(+) create mode 100644 gems/net-imap/CVE-2026-47240.yml create mode 100644 gems/net-imap/CVE-2026-47241.yml create mode 100644 gems/net-imap/CVE-2026-47242.yml diff --git a/gems/net-imap/CVE-2026-47240.yml b/gems/net-imap/CVE-2026-47240.yml new file mode 100644 index 0000000000..7527f661dc --- /dev/null +++ b/gems/net-imap/CVE-2026-47240.yml @@ -0,0 +1,85 @@ +--- +gem: net-imap +cve: 2026-47240 +ghsa: 8p34-64r3-mwg8 +url: https://www.cve.org/CVERecord?id=CVE-2026-47240 +title: 'Net::IMAP: Command Injection via non-synchronizing literal + in "raw" argument' +date: 2026-06-09 +description: | + 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. +cvss_v3: 5.8 +patched_versions: + - "~> 0.5.15" + - ">= 0.6.4.1" +related: + url: + - https://www.cve.org/CVERecord?id=CVE-2026-47240 + - https://rubygems.org/gems/net-imap/versions/0.6.4.1 + - https://github.com/ruby/net-imap/releases/tag/v0.6.4.1 + - https://github.com/ruby/net-imap/security/advisories/GHSA-8p34-64r3-mwg8 + - https://github.com/advisories/GHSA-8p34-64r3-mwg8 +notes: | + - cve is reserved + - cvss_v3 - in GHSA ; No cvss_v2, cvss_v4 values. diff --git a/gems/net-imap/CVE-2026-47241.yml b/gems/net-imap/CVE-2026-47241.yml new file mode 100644 index 0000000000..a7d0256cda --- /dev/null +++ b/gems/net-imap/CVE-2026-47241.yml @@ -0,0 +1,103 @@ +--- +gem: net-imap +cve: 2026-47241 +ghsa: c4fp-cxrr-mj66 +url: https://www.cve.org/CVERecord?id=CVE-2026-47241 +title: 'Net::IMAP: Denial of Service via incomplete raw argument validation' +date: 2026-06-09 +description: | + + ### 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:\n* 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. +cvss_v3: 2.1 +patched_versions: + - "~> 0.5.15" + - ">= 0.6.4.1" +related: + url: + - https://www.cve.org/CVERecord?id=CVE-2026-47241 + - https://rubygems.org/gems/net-imap/versions/0.6.4.1 + - https://github.com/ruby/net-imap/releases/tag/v0.6.4.1 + - https://github.com/ruby/net-imap/security/advisories/GHSA-c4fp-cxrr-mj66 + - https://github.com/advisories/GHSA-c4fp-cxrr-mj66 +notes: | + - cve is reserved + - cvss_v3 - in GHSA ; No cvss_v2, cvss_v4 values. diff --git a/gems/net-imap/CVE-2026-47242.yml b/gems/net-imap/CVE-2026-47242.yml new file mode 100644 index 0000000000..4dad0d36d3 --- /dev/null +++ b/gems/net-imap/CVE-2026-47242.yml @@ -0,0 +1,74 @@ +--- +gem: net-imap +cve: 2026-47242 +ghsa: 46q3-7gv7-qmgg +url: https://www.cve.org/CVERecord?id=CVE-2026-47242 +title: 'Net::IMAP: Command Injection via ID command argument' +date: 2026-06-09 +description: | + ### Summary + + Two `Net::IMAP` commands, `#id` and `#enable`, do not validate their + arguments. Arguments to either command could be used by an attacker + to inject arbitrary IMAP commands. + + Please note that passing untrusted inputs to these commands is usually + inappropriate and expected to be uncommon. + + ### Details + + When `Net::IMAP#id` is called with a hash argument, although the ID + field value strings are correctly quoted (escaping quoted specials), + they were not validated to prohibit CRLF sequences. + + While `Net::IMAP#enable` does process its arguments for aliases, it + does not validate them as valid atoms (or as a list of valid atoms). + The `#to_s` value is sent verbatim. + + ### Impact + + This is expected to impact very few users: use of untrusted user input + for either command is expected to be very uncommon. + + The documentation for `#enable` explicitly warns that using any arguments + that are not in the explicitly supported list may result in undocumented + behavior. Using arbitrary untrusted user input for `#enable` will always + be inappropriate. + + Although client ID field values will most commonly be static and hardcoded, + dynamic input sources may be used. For example, client ID fields may be + set by configuration or version numbers. Using untrusted user inputs + for client ID fields is expected to be uncommon. But any untrusted + inputs to client ID can trivially exploit this vulnerability. + + Untrusted inputs to either command may include a 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 `#id` and `#enable` + arguments. + + Untrusted inputs should _never_ be used for `#enable` arguments. + + If `net-imap` cannot be upgraded: + * do not use untrusted inputs for client ID field values + * or add validation that client ID field values must not contain + any CR or LF bytes. +cvss_v3: 4.3 +patched_versions: + - "~> 0.5.15" + - ">= 0.6.4.1" +related: + url: + - https://www.cve.org/CVERecord?id=CVE-2026-47242 + - https://rubygems.org/gems/net-imap/versions/0.6.4.1 + - https://github.com/ruby/net-imap/releases/tag/v0.6.4.1 + - https://github.com/ruby/net-imap/security/advisories/GHSA-46q3-7gv7-qmgg + - https://github.com/advisories/GHSA-46q3-7gv7-qmgg +notes: | + - cve is reserved + - cvss_v3 - in GHSA ; No cvss_v2, cvss_v4 values.