CVE-2026-42246

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.

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.

### Summary A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS. ### Details When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted. This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`. ### Impact TLS bypass, leading to cleartext transmission of sensitive information. ### Mitigation * Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS. * Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port. This is strongly recommended anyway: * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context * Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.

### Summary A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return "successfully", without starting TLS. ### Details When using `Net::IMAP#starttls` to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged `OK` response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows `#starttls` to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted. This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`. ### Impact TLS bypass, leading to cleartext transmission of sensitive information. ### Mitigation * Upgrade to a patched version of net-imap that raises an exception whenever `#starttls` does not establish TLS. * Connect to an implicit TLS port, rather than use `STARTTLS` with a cleartext port. This is strongly recommended anyway: * [RFC 8314](https://www.rfc-editor.org/info/rfc8314): Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access * [NO STARTTLS](https://nostarttls.secvuln.info/): Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context * Explicitly verify `Net::IMAP#tls_verified?` is `true`, before using the connection after `#starttls`.