CVE-2026-42245

What it actually does

CVE-2026-42245 is a denial-of-service flaw in Ruby Net::IMAP's response parsing logic. Net::IMAP::ResponseReader processes large IMAP responses containing many string literals with quadratic time complexity, meaning parsing cost grows disproportionately as response size and literal count increase. A malicious or compromised IMAP server can craft responses that cause a Ruby IMAP client using affected Net::IMAP versions to consume excessive CPU, slowing or stalling the process. The issue affects Net::IMAP before 0.4.24, 0.5.14, and 0.6.4.

Why it matters to the business

Applications, background jobs, mail-processing pipelines, or integrations that connect to IMAP servers using vulnerable Ruby Net::IMAP versions may become slow or unavailable if they connect to a hostile or compromised mail server. This can interrupt email ingestion, ticket creation, notification processing, compliance archiving, or other workflows that depend on IMAP. The vulnerability is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has low EPSS, but remediation is still important for internet-facing or third-party mail integrations because exploitation can be performed remotely by a malicious server once a client connects.

How an attack unfolds

An attacker first needs to control, compromise, spoof, or otherwise influence an IMAP server that the vulnerable Ruby application will connect to. When the Ruby client initiates an IMAP session and requests mailbox data, the hostile server returns specially crafted large responses containing many string literals. The vulnerable Net::IMAP::ResponseReader parses those responses inefficiently, causing CPU usage to rise sharply and potentially tying up the Ruby process or worker thread. Repeated connections or responses can sustain the resource exhaustion and degrade or deny service to the application component that performs IMAP processing.

How to fix it

Upgrade Net::IMAP to a patched release: 0.4.24 or later for the 0.4.x line, 0.5.14 or later for the 0.5.x line, or 0.6.4 or later for the 0.6.x line. If Net::IMAP is pulled in through Ruby, Bundler, or another dependency, update the dependency lockfile and rebuild/redeploy affected applications. Where immediate upgrade is not possible, reduce exposure by allowing IMAP connections only to trusted servers, enforcing TLS certificate validation, preventing users or configuration sources from supplying arbitrary IMAP endpoints, applying connection/read timeouts, limiting response sizes where feasible, and isolating mail-processing workers so CPU exhaustion cannot affect unrelated services.

How to confirm the fix worked

Confirm the deployed Net::IMAP version is 0.4.24, 0.5.14, 0.6.4, or newer using dependency manifests, lockfiles, software composition analysis, or runtime package inspection. For Bundler-based applications, check Gemfile.lock for the resolved net-imap version. Validate that production artifacts and containers were rebuilt after the dependency update. Operationally, test that IMAP clients still authenticate and process mail successfully after upgrade. If compensating controls are used, verify that IMAP destinations are restricted to approved servers, TLS validation is enabled, and client-side timeout settings are active.

Typical attack path

1. Identify an application or service that uses Ruby Net::IMAP to connect to an IMAP server.
2. Gain control of an IMAP server used by the application, operate a malicious IMAP endpoint, or induce the client to connect to an attacker-controlled IMAP service.
3. Wait for or trigger the Ruby IMAP client to establish a connection and request mailbox data.
4. Return crafted IMAP responses with many string literals and large response bodies.
5. Cause Net::IMAP::ResponseReader to spend excessive CPU time parsing the response.
6. Repeat or sustain the responses to slow, stall, or deny service to the affected Ruby process or job queue.

How to detect it

There is no known public exploit signature or unique network indicator for this issue, and exploitation may look like an abnormal IMAP response followed by high CPU consumption in a Ruby process. To investigate possible prior exploitation, review application logs, job/worker logs, process metrics, and network telemetry for Ruby services using Net::IMAP. Look for sudden CPU spikes, long-running or stuck mail-processing jobs, IMAP read timeouts, repeated reconnects, mailbox operations that never complete, or abnormal response sizes from IMAP servers. Correlate these events with outbound IMAP connections to newly configured, unexpected, compromised, or untrusted servers. If packet capture or proxy logs are available, inspect IMAP sessions immediately preceding CPU exhaustion for unusually large server responses containing many literals. Forensic review should include stack traces, crash dumps, profiler output, and thread dumps showing time spent in Net::IMAP::ResponseReader or Net::IMAP response parsing code.

What your security team should do

• Inventory Ruby applications, workers, and integrations that use Net::IMAP or the net-imap gem, especially systems that connect to external or user-configurable IMAP servers.
• Prioritize upgrades for services that process email from third-party, customer-supplied, partner-supplied, or internet-accessible IMAP servers.
• Upgrade affected dependency lines to Net::IMAP 0.4.24, 0.5.14, 0.6.4, or later, then redeploy all affected application artifacts.
• Review configuration paths that allow IMAP hostnames, ports, or credentials to be modified and restrict them to trusted sources.
• Add or verify IMAP client timeouts, worker concurrency limits, CPU quotas, and process supervision so a single malicious response cannot degrade the broader service.
• Monitor Ruby application CPU usage, job duration, and IMAP error/timeout rates for anomalies that may indicate attempted exploitation.
• Because the vulnerability is not KEV-listed and EPSS is low, handle through normal vulnerability management unless the application connects to untrusted IMAP infrastructure, in which case treat as higher priority.