CVE-2026-47241.yml

---
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
cvss_v4: 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.