https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 21:12:09 +0000 https://vulnerability.circl.lu/vuln/ghsa-vcgp-9326-pqcp <p><strong>Affected:</strong> RubyGems: net-imap</p> <p>### Summary</p> <p>A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return &#34;successfully&#34;, without starting TLS.</p> <p>### Details</p> <p>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 &#34;successfully&#34; 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.</p> <p>This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.</p> <p>### Impact</p> <p>TLS bypass, leading to cleartext transmission of sensitive information.</p> <p>### Mitigation</p> <p>* 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 connec…</p> <p><strong>Affected:</strong> RubyGems: net-imap</p> <p>### Summary</p> <p>A man-in-the-middle attacker can cause `Net::IMAP#starttls` to return &#34;successfully&#34;, without starting TLS.</p> <p>### Details</p> <p>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 &#34;successfully&#34; 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.</p> <p>This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks `Net::IMAP#tls_verified?`.</p> <p>### Impact</p> <p>TLS bypass, leading to cleartext transmission of sensitive information.</p> <p>### Mitigation</p> <p>* 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 connec…</p> https://vulnerability.circl.lu/vuln/ghsa-vcgp-9326-pqcp