CVE-2025-25186

What it actually does

The flaw is a remote denial-of-service condition in the Ruby net-imap client library response parser. A malicious or compromised IMAP server can send a syntactically small UID-set or range expression that expands to an extremely large set of integers. Vulnerable versions convert those ranges with Range#to_a without enforcing an expansion limit, causing the Ruby process to allocate excessive memory. The likely result is severe memory pressure, process termination, container restart, worker crash, or host-level instability if resource limits are weak. The issue affects net-imap versions starting at 0.3.2 and before 0.3.8, 0.4.19, and 0.5.6.

Why it matters to the business

Applications that use Ruby net-imap to connect to external, user-supplied, third-party, or potentially compromised IMAP servers can be made unavailable by a hostile server response. This can interrupt mail ingestion, ticket creation, notification processing, account synchronization, or any workflow that depends on IMAP polling. The vulnerability is not known to be in CISA KEV, is not reported as ransomware-used, and has a low EPSS score, but it is simple to trigger when an attacker can influence the IMAP server endpoint or compromise a mailbox provider. Because the issue was published in February 2025 and has had fixed releases available for an extended period, remaining exposure is primarily a patch hygiene and dependency-management risk.

How an attack unfolds

An attacker first needs a Ruby application using a vulnerable net-imap version to connect to an IMAP server the attacker controls or has compromised. This may happen when an application lets users configure mailboxes, when test or integration systems connect to attacker-controlled IMAP endpoints, or when a legitimate IMAP server is compromised. After the client authenticates or otherwise establishes an IMAP session, the server sends a response containing a highly compressed UID-set or range that is small on the wire but expands to a very large number of integers. The vulnerable receiver thread automatically reads the response, and the parser converts the range into an array using Range#to_a. Memory consumption spikes rapidly until the Ruby process is killed by the runtime, operating system, container orchestrator, or out-of-memory protection. The attacker does not gain code execution or data access from the flaw itself; the impact is availability loss.

How to fix it

Upgrade the Ruby net-imap dependency to a fixed release: 0.3.8 or later for the 0.3.x line, 0.4.19 or later for the 0.4.x line, or 0.5.6 or later for the 0.5.x line. If consuming directly from Git, use a revision containing commit 38ce681e594e0a12b46fda77b9729c85e090dc13 or a later trusted commit. Rebuild and redeploy applications so the fixed gem/library version is actually loaded at runtime. If immediate upgrade is not possible, reduce exposure by disallowing user-controlled IMAP server destinations, allowlisting trusted IMAP hosts, enforcing strict connection egress controls, placing Ruby workers in memory-limited containers, configuring supervisor restart backoff, and isolating mail ingestion workers from critical application processes. Resource limits are mitigation only; they do not correct the parser flaw.

How to confirm the fix worked

Confirm dependency resolution with package inventory and runtime checks, not only source manifests. Review Gemfile.lock, gemspecs, bundled gems, container images, and SBOMs for net-imap versions earlier than 0.3.8, 0.4.19, or 0.5.6. In a running application, verify the loaded net-imap version using Ruby dependency introspection such as `Gem.loaded_specs['net-imap']&.version`. Confirm direct Git dependencies include commit 38ce681e594e0a12b46fda77b9729c85e090dc13 or later. After upgrading, run application IMAP integration tests and monitor memory behavior while parsing large but bounded IMAP UID-set responses. Exposure remains if any deployed image, worker, scheduled job, or mail-processing component still loads a vulnerable net-imap version.

Typical attack path

1. Identify or lure a Ruby application using vulnerable net-imap versions 0.3.2 through versions before 0.3.8, 0.4.19, or 0.5.6 into connecting to an IMAP server under attacker control.
2. Allow the IMAP TCP/TLS session to be established and keep the client connected long enough for the client receiver thread to process server responses.
3. Send an IMAP response containing a compact but extremely large UID-set/range expression.
4. Trigger the vulnerable response parser to expand the UID-set into a large Ruby array using Range#to_a.
5. Exhaust process memory, causing the mail-processing worker, application process, container, or host service to crash or restart.
6. Repeat the malicious response after reconnects to create a persistent denial of service.

How to detect it

Look for evidence of abnormal memory exhaustion in Ruby processes that use net-imap, especially mail ingestion workers or background jobs that maintain IMAP sessions. Useful sources include application logs, Ruby exception logs, container stdout/stderr, process supervisor logs, system OOM-killer logs, Kubernetes pod events, endpoint telemetry, and network/proxy logs for IMAP/IMAPS connections. Investigate NoMemoryError, abrupt worker exits, container OOMKilled events, repeated restarts, or host OOM events that occur during or shortly after IMAP sessions. Correlate crashes with outbound connections to new, unusual, user-supplied, or low-reputation IMAP servers on ports 143 or 993. If packet capture or mail protocol logging is available, search for IMAP responses containing unusually large UID-set ranges, especially compact numeric ranges with very large upper bounds. Because exploitation does not require dropping files or spawning attacker tooling, detection is primarily behavioral: memory spikes plus IMAP response parsing activity plus a suspicious server endpoint.

• NoMemoryError
• failed to allocate memory
• Range#to_a
• net/imap
• net-imap
• OOMKilled
• Out of memory: Killed process
• Killed process ruby
• signal 9 (SIGKILL)
• exit status 137
• port 143
• port 993
• UID 1:4294967295
• 1:4294967295
• 1:2147483647
• VANISHED 1:4294967295
• ESEARCH UID

What your security team should do

• Inventory all Ruby applications, background workers, mail ingestion services, and automation jobs that use net-imap, including transitive dependencies and bundled gems.
• Prioritize upgrades for systems that connect to user-configurable, third-party, internet-hosted, or otherwise untrusted IMAP servers.
• Pin net-imap to fixed versions 0.3.8, 0.4.19, 0.5.6, or later, and redeploy all affected runtime artifacts.
• Add dependency-scanning policy to block net-imap versions >=0.3.2 and <0.3.8, >=0.4.0 and <0.4.19, and >=0.5.0 and <0.5.6.
• Restrict outbound IMAP/IMAPS connections to approved providers where business requirements allow.
• Apply memory limits and restart controls to mail-processing workers to contain availability impact if a malicious server response is encountered.
• Review recent crash, OOM, and mail-worker restart events for signs of prior exploitation, especially where failures correlate with specific IMAP server connections.
• Because this is not currently KEV-listed and has low EPSS, treat it as moderate-priority unless the application connects to untrusted IMAP endpoints, in which case patch promptly.