CVE-2026-42256

What it actually does

Net::IMAP, the Ruby IMAP client library, mishandles SCRAM-SHA1 and SCRAM-SHA256 authentication parameters supplied by an IMAP server. During SCRAM authentication, the server can return an excessively large iteration count, causing the client to perform an extremely expensive password-based key derivation operation. Because the attacker-controlled value directly influences CPU work, a malicious or compromised IMAP server can consume substantial client CPU and make the Ruby process hang, time out, or become unavailable. The issue affects Net::IMAP versions 0.4.0 through 0.4.23, 0.5.0 through 0.5.13, and 0.6.0 through 0.6.3, and is fixed in 0.4.24, 0.5.14, and 0.6.4.

Why it matters to the business

Applications, background jobs, mail-processing services, monitoring tools, or automation that connect to IMAP servers using Ruby Net::IMAP may become slow or unavailable if they authenticate to a hostile, spoofed, or compromised mail server. The most likely consequence is service degradation or outage in workflows that retrieve, process, or monitor email. The risk is lower than remote code execution because exploitation requires the vulnerable client to connect and authenticate to an attacker-influenced IMAP server, but it can still disrupt production mail-dependent processes. This vulnerability is not listed in CISA KEV, has no known ransomware association, and has a low EPSS score, so remediation should be prioritized based on exposure to untrusted IMAP endpoints and operational dependence on Ruby-based mail processing.

How an attack unfolds

An attacker first needs a way to have a vulnerable Ruby application connect to an IMAP server they control or influence. This can happen if the application accepts user-supplied mail server settings, connects to third-party IMAP services, follows attacker-controlled configuration, or if a legitimate IMAP server is compromised or impersonated through network or DNS manipulation. During SCRAM-SHA1 or SCRAM-SHA256 authentication, the malicious server sends a server-first SCRAM message containing an abnormally large iteration count. The vulnerable Net::IMAP client accepts that value and begins the required key derivation work. Because the iteration count is extremely high, the Ruby process spends excessive CPU cycles computing the SCRAM response, causing the process to stall, exhaust worker capacity, hit timeouts, or be restarted by service supervision. Repeated connections can sustain denial of service against mail-processing workers or any application path that depends on the affected authentication flow.

How to fix it

Upgrade the net-imap Ruby gem to a patched version appropriate for the release line in use: 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 possible, upgrade to the latest available net-imap release compatible with the application. Regenerate dependency lockfiles, rebuild application images, and redeploy all services, workers, and scheduled jobs that include the vulnerable gem. If immediate upgrade is not possible, restrict IMAP connections to trusted servers, prevent user-controlled IMAP host configuration, enforce TLS certificate validation, block outbound IMAP access to unapproved destinations, and avoid SCRAM-SHA1/SCRAM-SHA256 authentication against untrusted endpoints where operationally feasible. Mitigations reduce exploitability but do not fully replace the patched library behavior.

How to confirm the fix worked

Confirm installed dependency versions using dependency manifests and runtime package inventory, such as Gemfile.lock, gem list net-imap, bundle info net-imap, SBOM output, or container image scans. A deployment is remediated only when all running application instances and job workers use net-imap 0.4.24, 0.5.14, 0.6.4, or a later fixed version. Validate that rebuilt containers or packages no longer include vulnerable versions 0.4.0-0.4.23, 0.5.0-0.5.13, or 0.6.0-0.6.3. Operationally, test IMAP authentication to expected mail servers and confirm normal latency, no excessive CPU consumption, and no authentication regressions. Review outbound network policy to ensure Ruby applications cannot connect to arbitrary IMAP servers unless explicitly required.

Typical attack path

1. Identify or induce a Ruby application using affected Net::IMAP versions to connect to an IMAP endpoint under attacker control or influence.
2. Ensure the authentication mechanism negotiated or selected is SCRAM-SHA1 or SCRAM-SHA256.
3. Return a malicious SCRAM server challenge containing an excessively large iteration count.
4. Cause the Net::IMAP client process to perform computationally expensive password-derivation work.
5. Repeat or maintain connection attempts to tie up Ruby worker processes, background jobs, or service threads and degrade availability.

How to detect it

Look for signs that Ruby processes performing IMAP authentication became CPU-bound or stalled after connecting to an unusual, newly configured, or untrusted IMAP server. Relevant log sources include application logs, background job logs, mail ingestion logs, outbound proxy or firewall logs, DNS logs, endpoint process telemetry, container metrics, and APM traces. Investigate repeated or prolonged IMAP authentication attempts using SCRAM-SHA1 or SCRAM-SHA256, especially when followed by request timeouts, worker restarts, job failures, or sustained high CPU in Ruby processes. Network telemetry may show outbound TCP connections to IMAP ports 143 or 993 shortly before CPU exhaustion. Because exploitation does not require writing files or executing commands, host artifacts may be limited to performance anomalies, authentication failures, timeout messages, and connections to suspicious IMAP endpoints. If packet capture or protocol logs are available, inspect SCRAM server-first messages for an unusually large iteration attribute in the form 'i=<large number>'.

• gem list net-imap
• net-imap (0.4.0)
• net-imap (0.4.1)
• net-imap (0.4.2)
• net-imap (0.4.3)
• net-imap (0.4.4)
• net-imap (0.4.5)
• net-imap (0.4.6)
• net-imap (0.4.7)
• net-imap (0.4.8)
• net-imap (0.4.9)
• net-imap (0.4.10)
• net-imap (0.4.11)
• net-imap (0.4.12)
• net-imap (0.4.13)
• net-imap (0.4.14)
• net-imap (0.4.15)
• net-imap (0.4.16)
• net-imap (0.4.17)
• net-imap (0.4.18)
• net-imap (0.4.19)
• net-imap (0.4.20)
• net-imap (0.4.21)
• net-imap (0.4.22)
• net-imap (0.4.23)
• net-imap (0.5.0)
• net-imap (0.5.1)
• net-imap (0.5.2)
• net-imap (0.5.3)
• net-imap (0.5.4)
• net-imap (0.5.5)
• net-imap (0.5.6)
• net-imap (0.5.7)
• net-imap (0.5.8)
• net-imap (0.5.9)
• net-imap (0.5.10)
• net-imap (0.5.11)
• net-imap (0.5.12)
• net-imap (0.5.13)
• net-imap (0.6.0)
• net-imap (0.6.1)
• net-imap (0.6.2)
• net-imap (0.6.3)
• AUTHENTICATE SCRAM-SHA-1
• AUTHENTICATE SCRAM-SHA-256
• SCRAM-SHA-1
• SCRAM-SHA-256
• i=999999999
• i=2147483647
• TCP/143
• TCP/993

What your security team should do

• Inventory Ruby applications, background workers, and containers that include the net-imap gem, especially systems that retrieve or process email.
• Upgrade affected dependency lines to net-imap 0.4.24, 0.5.14, 0.6.4, or later, and redeploy all running workloads.
• Prioritize systems that accept user-configured IMAP server settings, connect to third-party mailboxes, or perform business-critical email ingestion.
• Restrict outbound IMAP/IMAPS traffic to approved mail servers and enforce TLS certificate validation to reduce exposure to hostile or impersonated servers.
• Monitor for unusual CPU spikes, long-running Ruby processes, authentication timeouts, and repeated IMAP connection attempts after deployment.
• Add dependency scanning or SBOM checks to CI/CD to prevent reintroduction of vulnerable net-imap versions.