CVE-2026-42246

HIGH7.4EPSS 0.02%

net-imap vulnerable to STARTTLS stripping via invalid response timing

Published: 5/4/2026Modified: 5/14/2026
Also known as:GHSA-vcgp-9326-pqcpCGA-p9hp-3w6c-h3pq

Description

### 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`.

Affected packages (4)

CVSS scores

SourceVersionSeverityVector
osvCVSS 4.0—CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N
osvCVSS 3.1HIGH7.4CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N

References (15)