CVE-2026-42246
ADVISORY - githubSummary
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
#starttlsdoes not establish TLS. - Connect to an implicit TLS port, rather than use
STARTTLSwith a cleartext port. This is strongly recommended anyway:- RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access
- NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context
- Explicitly verify
Net::IMAP#tls_verified?istrue, before using the connection after#starttls.
Sign in to Docker Scout
See which of your images are affected by this CVE and how to fix them by signing into Docker Scout.
Sign in