CVE-2026-42256
Denial-of-Service in Ruby Net::IMAP via SCRAM Authentication
Publication date: 2026-05-09
Last updated on: 2026-05-09
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| ruby | net_imap | to 0.4.24 (exc) |
| ruby | net_imap | to 0.5.14 (exc) |
| ruby | net_imap | to 0.6.4 (exc) |
| ruby | net_imap | 0.4.24 |
| ruby | net_imap | 0.5.14 |
| ruby | net_imap | 0.6.4 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-1322 | The product uses a non-blocking model that relies on a single threaded process for features such as scalability, but it contains code that can block when it is invoked. |
| CWE-770 | The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-42256 is a vulnerability in the Ruby net-imap library related to the SCRAM authentication mechanism. When authenticating using SCRAM-SHA1 or SCRAM-SHA256, a hostile IMAP server can send an excessively large iteration count value for the password-based key derivation function (PBKDF2). This causes the client to perform very computationally expensive operations, leading to a denial-of-service (DoS) attack by consuming excessive CPU resources and blocking the Ruby virtual machine.
The vulnerability arises because the default maximum iteration count is set extremely high (2^31 - 1), which does not effectively limit the iteration count sent by the server. Without proper limits, the client can be forced to perform long-running computations that block other Ruby threads and degrade system availability.
The issue has been addressed by introducing a configurable max_iterations parameter that enforces a ceiling on the iteration count during SCRAM authentication, along with validation to reject iteration counts outside safe bounds. However, users must explicitly configure appropriate iteration limits to fully mitigate the risk.
How can this vulnerability impact me? :
This vulnerability can impact you by causing a denial-of-service (DoS) condition on your client system when connecting to a malicious IMAP server using SCRAM-SHA1 or SCRAM-SHA256 authentication.
- A hostile server can send a very large iteration count, forcing your client to perform expensive cryptographic computations.
- These computations block the Ruby virtual machine for extended periods, potentially over seven minutes, preventing other Ruby threads from running.
- This results in high CPU usage and unresponsiveness, effectively causing a denial-of-service on your application or system.
- There is no direct loss of confidentiality or integrity, but the availability of your client application is severely impacted.
Mitigation involves upgrading to patched versions and configuring safe iteration count limits or avoiding SCRAM authentication with untrusted servers.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability occurs during SCRAM-SHA1 or SCRAM-SHA256 authentication in the Ruby net-imap client when a hostile server sends a large PBKDF2 iteration count, causing a computational denial-of-service. Detection involves monitoring for unusually long authentication delays or high CPU usage during IMAP authentication attempts.
Since the issue is triggered by the server sending a large iteration count, you can detect it by observing authentication logs or network traffic for SCRAM authentication exchanges with abnormally high iteration counts.
There are no specific commands provided in the resources, but general approaches include:
- Capture and inspect IMAP authentication traffic using tools like Wireshark or tcpdump to identify SCRAM authentication messages and check the iteration count values.
- Monitor Ruby process CPU usage and responsiveness during IMAP authentication to detect potential DoS conditions.
- Review application logs for authentication failures or unusually long authentication times.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, you should upgrade the Ruby net-imap library to a patched version: 0.4.24, 0.5.14, or 0.6.4 or later.
Additionally, configure the `ScramAuthenticator` class to set a safe `max_iterations` limit for PBKDF2 iteration counts during SCRAM authentication. The default maximum (2^31 - 1) is excessively high and can still allow denial-of-service attacks if not adjusted.
If upgrading or configuring iteration limits is not immediately possible, avoid using SCRAM-SHA1 or SCRAM-SHA256 authentication mechanisms with untrusted IMAP servers.
- Upgrade net-imap to version 0.4.24, 0.5.14, or 0.6.4 or newer.
- Set a reasonable `max_iterations` value in the `ScramAuthenticator` to limit PBKDF2 iteration counts.
- Avoid SCRAM authentication with untrusted servers until patched versions are deployed.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
CVE-2026-42256 is a denial-of-service vulnerability that affects the Ruby net-imap library during SCRAM authentication by allowing a hostile server to send an excessively high iteration count, causing significant computational load and blocking the Ruby VM.
While the vulnerability primarily impacts availability by causing denial-of-service conditions, it does not directly affect confidentiality or integrity of data.
From a compliance perspective, standards like GDPR and HIPAA emphasize the protection of data confidentiality, integrity, and availability. This vulnerability impacts availability, which is a component of these standards' security requirements.
Therefore, if exploited, this vulnerability could lead to service disruptions that might affect compliance with availability requirements under such regulations.
Mitigation involves upgrading to patched versions and configuring appropriate iteration limits to prevent denial-of-service attacks, which helps maintain compliance by ensuring system availability.