GHSA/SYNC: 3 new net-imap advisories

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.

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.

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.