CVE-2026-42246
Received Received - Intake
Man-in-the-Middle TLS Bypass in Ruby Net::IMAP

Publication date: 2026-05-09

Last updated on: 2026-05-09

Assigner: GitHub, Inc.

Description
Net::IMAP implements Internet Message Access Protocol (IMAP) client functionality in Ruby. Prior to versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4, a man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS. This issue has been patched in versions 0.3.10, 0.4.24, 0.5.14, and 0.6.4.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-05-09
Last Modified
2026-05-09
Generated
2026-05-10
AI Q&A
2026-05-09
EPSS Evaluated
N/A
NVD
Affected Vendors & Products
Showing 6 associated CPEs
Vendor Product Version / Range
ruby net_imap to 0.3.10 (exc)
ruby net_imap to 0.6.4 (exc)
ruby net_imap 0.3.10
ruby net_imap 0.4.24
ruby net_imap 0.5.14
ruby net_imap 0.6.4
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-841 The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence.
CWE-754 The product does not check or incorrectly checks for unusual or exceptional conditions that are not expected to occur frequently during day to day operation of the product.
CWE-393 A function or operation returns an incorrect return value or status code that does not indicate the true result of execution, causing the product to modify its behavior based on the incorrect result.
CWE-636 When the product encounters an error condition or failure, its design requires it to fall back to a state that is less secure than other options that are available, such as selecting the weakest encryption algorithm or using the most permissive access control restrictions.
CWE-392 The product encounters an error but does not provide a status code or return value to indicate that an error has occurred.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

CVE-2026-42246 is a vulnerability in the Ruby net-imap library's implementation of the STARTTLS command, which is used to upgrade a plaintext IMAP connection to a secure TLS connection.

A man-in-the-middle attacker can exploit this vulnerability by sending a fake 'OK' response prematurely before the client finishes the STARTTLS handshake. This causes the Net::IMAP#starttls method to falsely report a successful TLS connection without actually establishing encryption.

As a result, the connection remains unencrypted, allowing the attacker to intercept or manipulate sensitive data transmitted over the connection.

The vulnerability arises because the client does not properly verify that the STARTTLS command was fully processed before accepting the 'OK' response, allowing the attacker to bypass the TLS negotiation.

This issue has been fixed by adding checks to ensure the STARTTLS command is properly handled and by disconnecting if suspicious or invalid responses are detected.


What immediate steps should I take to mitigate this vulnerability?

The primary mitigation is to upgrade the ruby/net-imap library to a patched version where this vulnerability is fixed. The patched versions are 0.3.10, 0.4.24, 0.5.14, and 0.6.4.

Alternatively, instead of using STARTTLS to upgrade a plaintext connection, connect directly to an implicit TLS port to ensure the connection is encrypted from the start.

Another recommended step is to explicitly verify the tls_verified? flag after calling the #starttls method to ensure that TLS negotiation was successful.

The patches also ensure that the client disconnects immediately if an invalid or unexpected response is detected during the STARTTLS handshake, preventing the connection from remaining unencrypted.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

CVE-2026-42246 allows a man-in-the-middle attacker to bypass the STARTTLS encryption in the Ruby net-imap library, causing the Net::IMAP#starttls method to falsely report a successful TLS connection without actually establishing it.

This vulnerability can lead to sensitive data being transmitted in cleartext over the network, exposing it to interception and unauthorized access.

Such exposure of sensitive data can negatively impact compliance with data protection standards and regulations like GDPR and HIPAA, which require encryption of data in transit to protect confidentiality and integrity.

Failure to properly secure communications could result in violations of these regulations, potentially leading to legal and financial consequences.


How can this vulnerability impact me? :

This vulnerability can have serious security impacts by allowing a man-in-the-middle attacker to intercept or manipulate data that is supposed to be protected by TLS encryption.

  • Sensitive information such as login credentials, emails, and other private data can be exposed in plaintext.
  • The attacker can eavesdrop on or alter communications without detection.
  • It undermines the confidentiality and integrity of the IMAP connection.

Because the vulnerability is relatively easy to exploit over a network and requires no privileges or user interaction, it poses a high risk to users relying on the net-imap library for secure email communication.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves a man-in-the-middle attacker causing the Net::IMAP#starttls method to falsely report a successful TLS connection without actually establishing it. Detection involves monitoring for unexpected or premature 'OK' responses from the IMAP server during the STARTTLS handshake.

Specifically, the patched versions add a method to detect tagged OK responses sent before the client finishes the STARTTLS command, which could indicate a STARTTLS stripping attack.

While no explicit network or system commands are provided in the resources, detection could involve capturing and analyzing IMAP traffic to check if the STARTTLS command is followed by a proper TLS handshake or if an 'OK' response is sent prematurely.

For example, using packet capture tools like tcpdump or Wireshark to monitor IMAP sessions and verify that the STARTTLS command is properly negotiated and that TLS handshake packets follow.

Additionally, inspecting application logs for errors related to InvalidResponseError or unexpected disconnections during STARTTLS attempts could help detect exploitation attempts.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart