Skip to main content

net-imap CVE-2026-42246

HIGH
Missing Report of Error Condition (CWE-392)
2026-05-04 https://github.com/ruby/net-imap GHSA-vcgp-9326-pqcp
Information Disclosure
7.6
CVSS 4.0 · Vendor: https://github.com/ruby/net-imap
Share

Severity by source

Vendor (https://github.com/ruby/net-imap) PRIMARY
7.6 HIGH
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
SUSE
7.4 HIGH
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N
Red Hat
7.4 HIGH
qualitative

Primary rating from Vendor (https://github.com/ruby/net-imap).

CVSS VectorVendor: https://github.com/ruby/net-imap

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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
P
Scope
X

Lifecycle Timeline

5
Analysis Updated
May 09, 2026 - 20:29 vuln.today
v2 (cvss_changed)
Re-analysis Queued
May 09, 2026 - 20:22 vuln.today
cvss_changed
CVSS changed
May 09, 2026 - 20:22 NVD
7.6 (HIGH)
Source Code Evidence Fetched
May 04, 2026 - 22:30 vuln.today
Analysis Generated
May 04, 2026 - 22:30 vuln.today

DescriptionCVE.org

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: 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? is true, before using the connection after #starttls.

AnalysisAI

Man-in-the-middle attackers can strip TLS protection from Ruby net-imap STARTTLS connections by injecting a premature tagged OK response with a predictable tag. The vulnerability allows attackers to bypass TLS encryption, forcing the client to transmit credentials and email content in cleartext while the application believes the connection is secure. Vendor-released patches (net-imap 0.6.4, 0.5.14, 0.4.24, 0.3.10) are available. CVSS 7.6 severity reflects network-accessible attack with low complexity but requires man-in-the-middle positioning. No public exploit code identified at time of analysis, though the attack mechanism is well-documented in security research (NO STARTTLS project).

Technical ContextAI

The vulnerability exists in Ruby's net-imap library implementation of the IMAP STARTTLS protocol upgrade mechanism (RFC 3501 section 6.2.1). STARTTLS allows an IMAP client to upgrade a plaintext connection to TLS encryption. The flaw stems from CWE-392 (Missing Report of Error Condition) - specifically, a race condition in response handling where Net::IMAP#starttls completes successfully even when TLS negotiation never occurred. The predictable tag-based protocol allows attackers to inject a 'RUBY0001 OK' response before the client finishes transmitting the STARTTLS command. Because the response handler registration happens after command transmission completes, the injected response is processed as a successful command completion, but the handler that actually negotiates TLS is never invoked. The socket remains unencrypted while the API returns success. This is a classic STARTTLS stripping attack vector affecting protocol upgrade mechanisms across multiple email protocols (SMTP, IMAP, POP3), documented in RFC 8314 which deprecates cleartext ports entirely. The fix adds explicit validation to ensure response handlers actually execute and raises InvalidResponseError if TLS verification fails, addressing the missing error reporting that enabled silent failures.

RemediationAI

Upgrade to patched net-imap versions: 0.6.4 for 0.6.x users, 0.5.14 for 0.5.x users, 0.4.24 for 0.4.x users, or 0.3.10 for 0.3.x and earlier users. Release tags are available at https://github.com/ruby/net-imap/releases. Patch commits (0ede4c40b, 24a4e770b, 97e2488fb, f79d35bf5) add explicit validation that raises Net::IMAP::InvalidResponseError if STARTTLS response handlers are bypassed, forcing connection termination rather than silent failure. For organizations unable to patch immediately, implement compensating controls: (1) Migrate to implicit TLS on port 993 instead of STARTTLS on port 143 - this is the strongest mitigation and aligns with RFC 8314 best practices for deprecating cleartext email protocols (https://www.rfc-editor.org/info/rfc8314), eliminating the vulnerable upgrade path entirely; (2) After calling Net::IMAP#starttls, explicitly verify Net::IMAP#tls_verified? returns true before transmitting credentials or sensitive data - this detects stripping attacks but requires code changes; (3) Deploy network-level TLS enforcement through VPN tunnels or dedicated encrypted links between IMAP clients and servers, reducing man-in-the-middle positioning opportunities but adding infrastructure complexity and potential performance overhead. Note that workaround (2) only detects attacks after connection establishment, potentially leaking initial handshake metadata, while workaround (3) requires significant infrastructure changes. Patching remains the recommended primary remediation.

Same weakness CWE-392 – Missing Report of Error Condition

View all
CVE-2025-32743 CRITICAL
9.0
CVE-2017-2342 HIGH
8.1
CVE-2025-26268 LOW POC
3.3
CVE-2024-12797 MEDIUM POC
6.3
CVE-2026-20005 MEDIUM
5.8
CVE-2023-48430 LOW
2.7
CVE-2025-59398 LOW
3.1

Same technique Information Disclosure

View all
CVE-2013-2251 CRITICAL POC
9.8
CVE-2017-5638 CRITICAL POC
9.8
CVE-2025-24813 CRITICAL POC
9.8
CVE-2015-1701 HIGH POC
7.8
CVE-2017-0147 HIGH POC
7.5
CVE-2014-6324 HIGH POC
8.8
CVE-2023-7028 CRITICAL POC
10.0
CVE-2017-0213 HIGH POC
7.3

Vendor StatusVendor

SUSE

Severity: Important
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 15 SP7 Not-Affected
SUSE Linux Enterprise High Availability Extension 16.0 Affected
SUSE Linux Enterprise High Availability Extension 16.1 Affected

Share

CVE-2026-42246 vulnerability details – vuln.today
Back

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy