net-imap CVE-2026-42245

The vulnerability requires the client application to establish a connection to an IMAP server controlled by or compromised by an attacker. No authentication bypass is required - the attacker only needs to send a malicious IMAP response over the connection. The attack is triggered automatically when the receiver thread reads the response; no client-side user action is needed. Exploitation is limited to scenarios where the application connects to untrusted or externally-hosted IMAP servers, or where an attacker can perform man-in-the-middle interception of IMAP connections (unless TLS is enforced with certificate pinning). Applications connecting only to trusted internal IMAP servers or servers under the organization's control are not at risk unless the server is compromised by an attacker.

This is a denial of service vulnerability with medium-to-high real-world risk but limited default exploitability. CVSS vector is not provided, but attack vector is clearly network (AV:N) with no authentication required (PR:N) and no user interaction (UI:N). Complexity is low (AC:L) because the attacker only needs to connect as an IMAP server. However, no public exploit code is identified, and this requires the client to connect to a hostile server - a prerequisite that limits opportunistic exploitation. EPSS data is absent, so probability calculation is uncertain. The technical impact is significant: CPU exhaustion in production IMAP clients can cascade into application-level denial of service, hanging message synchronization and blocking foreground operations. The algorithmic flaw allows small responses (well under max_response_size) to consume disproportionate resources, making traditional size-based rate limiting ineffective. Organizations using net-imap in production (especially for mail synchronization, automated message processing, or persistent connections to external IMAP services) face real risk if they interact with untrusted servers or if malicious actors can control IMAP server responses.

An attacker controls or compromises an IMAP server that a Ruby application connects to. The attacker crafts an IMAP response containing hundreds of thousands of small string literals (e.g., {100} ...{100} ...) staying below the default max_response_size limit. When the client's receiver thread parses this response, the ResponseReader rescans the accumulated buffer O(n) times, each with a linear regex, blocking the receiver thread for seconds or minutes and holding the Global VM lock. Other application threads attempting I/O or CPU-bound work experience severe latency, causing the application to appear frozen or unresponsive.