CVE-2025-43857: net-imap rubygem vulnerable to possible DoS by memory exhaustion
Summary
There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response.
This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname).
Details
The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not need to send any more data. There is no limit on the size of literals that will be accepted.
Fix Upgrade Users should upgrade to net-imap 0.5.7 or later. A configurable maxresponsesize limit has been added to Net::IMAP's response reader. The maxresponsesize limit has also been backported to net-imap 0.2.5, 0.3.9, and 0.4.20.
To set a global value for maxresponsesize, users must upgrade to net-imap ~> 0.4.20, or > 0.5.7.
Configuration
To avoid backward compatibility issues for secure connections to trusted well-behaved servers, the default maxresponsesize for net-imap 0.5.7 is very high (512MiB), and the default maxresponsesize for net-imap ~> 0.4.20, ~> 0.3.9, and 0.2.5 is nil (unlimited).
When connecting to untrusted servers or using insecure connections, a much lower maxresponsesize should be used. ruby Set the global maxresponsesize (only ~> v0.4.20, > 0.5.7) Net::IMAP.config.maxresponsesize = 256 << 10 # 256 KiB
Set when creating the connection imap = Net::IMAP.new(hostname, ssl: true, maxresponsesize: 16 << 10) # 16 KiB
Set after creating the connection imap.maxresponsesize = 256 << 20 # 256 KiB flush currently waiting read, to ensure the new setting is loaded imap.noop
Please Note: maxresponsesize only limits the size per response. It does not prevent a flood of individual responses and it does not limit how many unhandled responses may be stored on the responses hash. Users are responsible for adding response handlers to prune excessive unhandled responses.
Compatibility with lower maxresponsesize
A lower maxresponsesize may cause a few commands which legitimately return very large responses to raise an exception and close the connection. The maxresponsesize could be temporarily set to a higher value, but paginated or limited versions of commands should be used whenever possible. For example, to fetch message bodies:
ruby imap.maxresponsesize = 256 << 20 # 256 KiB imap.noop # flush currently waiting read
fetch a message in 252KiB chunks size = imap.uidfetch(uid, "RFC822.SIZE").first.rfc822size limit = 252 << 10 message = ((0..size) % limit).eachwithobject("") {|offset, str| str << imap.uidfetch(uid, "BODY.PEEK[]<#{offset}.#{limit}>").first.message(offset:) }
imap.maxresponsesize = 16 << 20 # 16 KiB imap.noop # flush currently waiting read
References
PR to introduce maxresponsesize: https://github.com/ruby/net-imap/pull/444 Specific commit: 0ae8576c1 - lib/net/imap/responsereader.rb Backport to 0.4: https://github.com/ruby/net-imap/pull/445 Backport to 0.3: https://github.com/ruby/net-imap/pull/446 Backport to 0.2: https://github.com/ruby/net-imap/pull/447
Other sources
net-imap rubygem vulnerable to possible DoS by memory exhaustion
— Microsoft
Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5, there is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). This issue has been patched in versions 0.5.7, 0.4.20, 0.3.9, and 0.2.5.
— MITRE
Affected Software
Remediation
Patch Available
Patch Available
Patch Available
Patch Available
Event History
Frequently Asked Questions
What is the severity of CVE-2025-43857?
CVE-2025-43857 has a severity rating that could allow for denial of service due to memory exhaustion.
How do I fix CVE-2025-43857?
To fix CVE-2025-43857, update the net-imap package to versions 0.2.5, 0.3.9, 0.4.20, or 0.5.7.
Which versions of net-imap are vulnerable to CVE-2025-43857?
Versions of net-imap prior to 0.2.5, 0.3.9, 0.4.20, and 0.5.7 are vulnerable to CVE-2025-43857.
What type of attack does CVE-2025-43857 facilitate?
CVE-2025-43857 facilitates a denial of service attack by allowing a malicious server to exhaust memory on the client.
Is CVE-2025-43857 related to any specific package management system?
Yes, CVE-2025-43857 is related to the Ruby package management system, specifically the net-imap gem.