CVE-2025-25186 (net-imap): Possible DoS by memory exhaustion in net-imap

ADVISORIES

GEM

net-imap

SEVERITY

CVSS v3.x: 6.5 (Medium)

UNAFFECTED VERSIONS

< 0.3.2

PATCHED VERSIONS

~> 0.3.8
~> 0.4.19
>= 0.5.6

DESCRIPTION

Summary

There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#to_a to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges.

Details

IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges.

The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received from the server. This attack works even when the client does not handle the APPENDUID or COPYUID responses.

Malicious inputs:

# 40 bytes expands to ~1.6GB:
&quot;* OK [COPYUID 1 1:99999999 1:99999999]\r\n&quot;

# Worst *valid* input scenario (using uint32 max),
# 44 bytes expands to 64GiB:
&quot;* OK [COPYUID 1 1:4294967295 1:4294967295]\r\n&quot;

# Numbers must be non-zero uint32, but this isn&apos;t validated.  Arrays
# larger than UINT32_MAX can be created.  For example, the following
# would theoretically expand to almost 800 exabytes:
&quot;* OK [COPYUID 1 1:99999999999999999999 1:99999999999999999999]\r\n&quot;

Simple way to test this:

require &quot;net/imap&quot;

def test(size)
  input = &quot;A004 OK [COPYUID 1 1:#{size} 1:#{size}] too large?\n&quot;
  parser = Net::IMAP::ResponseParser.new
  parser.parse input
end

test(99_999_999)

Fixes

Preferred Fix, minor API changes

Upgrade to v0.4.19, v0.5.6, or higher, and configure:

# globally
Net::IMAP.config.parser_use_deprecated_uidplus_data = false
# per-client
imap = Net::IMAP.new(hostname, ssl: true,
                               parser_use_deprecated_uidplus_data: false)
imap.config.parser_use_deprecated_uidplus_data = false

This replaces UIDPlusData with AppendUIDData and CopyUIDData. These classes store their UIDs as Net::IMAP::SequenceSet objects (not expanded into arrays of integers). Code that does not handle APPENDUID or COPYUID responses will not notice any difference. Code that does handle these responses may need to be updated. See the documentation for UIDPlusData, AppendUIDData and CopyUIDData.

For v0.3.8, this option is not available. For v0.4.19, the default value is true. For v0.5.6, the default value is :up_to_max_size. For v0.6.0, the only allowed value will be false (UIDPlusData will be removed from v0.6).

Mitigation, backward compatible API

Upgrade to v0.3.8, v0.4.19, v0.5.6, or higher.

For backward compatibility, uid-set can still be expanded into an array, but a maximum limit will be applied.

Assign config.parser_max_deprecated_uidplus_data_size to set the maximum UIDPlusData UID set size. When config.parser_use_deprecated_uidplus_data == true, larger sets will crash. When config.parser_use_deprecated_uidplus_data == :up_to_max_size, larger sets will use AppendUIDData or CopyUIDData.

For v0.3,8, this limit is hard-coded to 10,000, and larger sets will always raise Net::IMAP::ResponseParseError. For v0.4.19, the limit defaults to 1000. For v0.5.6, the limit defaults to 100. For v0.6.0, the limit will be ignored (UIDPlusData will be removed from v0.6).

Please Note: unhandled responses

If the client does not add response handlers to prune unhandled responses, a malicious server can still eventually exhaust all

client memory, by repeatedly sending malicious responses. However, net-imap has always retained unhandled responses, and it has always been necessary for long-lived connections to prune these responses. This is not significantly different from connecting to a trusted server with a long-lived connection. To limit the maximum number of retained responses, a simple handler might look something like the following:

limit = 1000
imap.add_response_handler do |resp|
  next unless resp.respond_to?(:name) &amp;&amp; resp.respond_to?(:data)
  name = resp.name
  code = resp.data.code&amp;.name if resp.data.respond_to?(:code)
  if Net::IMAP::VERSION &gt; &quot;0.4.0&quot;
    imap.responses(name) { _1.slice!(0...-limit) }
    imap.responses(code) { _1.slice!(0...-limit) }
  else
    imap.responses(name).slice!(0...-limit)
    imap.responses(code).slice!(0...-limit)
  end
end

RubySec