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
7.6
CVSS 4.0 · Vendor: https://github.com/ruby/net-imap
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Position on network path
  2. Delivery
    Intercept STARTTLS command transmission
  3. Exploit
    Inject premature tagged OK response
  4. Execution
    Client completes without TLS handler
  5. Impact
    Capture cleartext credentials and email

Vulnerability Assessment

Weakness
CWE
ASVS 5.0
V16 - Security Logging and Error Handling Missing error reporting
Exploitation Conditions

Requires man-in-the-middle network positioning between IMAP client and server. The attacker must intercept traffic on the specific network path used by the IMAP connection to inject the malicious tagged response. Affected deployments must use STARTTLS protocol upgrade on cleartext port 143 rather than implicit TLS on port 993. Attack complexity is low once MitM position is established because IMAP command tags (like RUBY0001) follow predictable patterns. User interaction is required in that a client application must initiate an IMAP connection and call Net::IMAP#starttls, though this is typically automatic during email client startup. Exploitation is limited to net-imap versions prior to patches (0.6.4, 0.5.14, 0.4.24, 0.3.10). Applications using implicit TLS ports or those explicitly verifying tls_verified? status after STARTTLS are not vulnerable. Network-level encryption (VPNs, encrypted links) prevents attacker positioning despite vulnerable client versions.

Impact

CVSS 7.6 (High) with vector AV:N/AC:L/AT:P indicates network-accessible attack with low complexity but requiring precise attack timing (man-in-the-middle positioning). The AT:P (Attack Requirements: Present) metric confirms attackers must intercept network traffic between client and IMAP server. Real-world risk is moderate-to-high for specific deployment scenarios: applications using STARTTLS on port 143 over untrusted networks (public Wi-Fi, compromised infrastructure) face credential theft and email content exposure. However, several factors limit widespread exploitation: requires active network interception rather than remote code execution, many modern deployments use implicit TLS (port 993) which is unaffected, and the attack is detectable through TLS monitoring. No EPSS score provided, no CISA KEV listing, and no public exploit code identified at time of analysis - suggesting targeted rather than opportunistic exploitation risk. The vulnerability is significant for legacy IMAP deployments still using STARTTLS, but RFC 8314 (published 2018) already recommends migrating away from STARTTLS entirely. Organizations should prioritize patching based on whether they expose IMAP STARTTLS connections over untrusted networks; those using implicit TLS or encrypted network paths can deprioritize. The CVSS User Interaction:Present metric (UI:P) indicates some client-side action triggers the vulnerability, though connection establishment is typically automatic.

Exploit ScenarioDerived

An attacker with man-in-the-middle network position intercepts an IMAP client initiating STARTTLS upgrade on port 143. As the client transmits the 'RUBY0001 STARTTLS' command, the attacker injects a spoofed 'RUBY0001 OK' response before the legitimate server responds. The net-imap library processes this premature OK response, completing the starttls() call successfully before the TLS negotiation handler is registered. The client application proceeds to transmit username, password, and email content believing the connection is encrypted, but all traffic remains in cleartext. The attacker captures credentials for account compromise and email content for espionage or competitive intelligence.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.1% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv2 – May 09, 2026

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).

Earlier versions of this analysis (1)
v1 May 04, 2026 - 22:30

STARTTLS stripping attack in Ruby net-imap library allows man-in-the-middle attackers to bypass TLS encryption by injecting early tagged OK responses, causing the starttls method to return successfully while leaving the IMAP connection in plaintext. This enables interception of email credentials and message content. Affects all versions of the net-imap RubyGem prior to patched releases 0.3.10, 0.4.24, 0.5.14, and 0.6.4. Vendor-released patches are available across all affected version branches.

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.

Affected Packages

rubygems net-imap fix: 0.3.10, 0.4.24, 0.5.14, 0.6.4

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 1 package in rubygems

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

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.

Know when the next one hits your stack

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

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
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

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

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

Attack Vector
Network
Attack Complexity
Low
Attack Requirements
Present
Privileges Required
None
User Interaction
Passive
Vulnerable system: Confidentiality
High
Vulnerable system: Integrity
High
Vulnerable system: Availability
None
Subsequent system: Confidentiality
None
Subsequent system: Integrity
None
Subsequent system: Availability
None

Lifecycle Timeline

2
Analysis Updated
May 09, 2026 - 20:29 vuln.today
v2 - CVSS changed
CVSS changed
May 09, 2026 - 20:22 NVD
7.6 (HIGH)

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.

Executive ViewAI

Why It Matters

Ruby net-imap versions before 0.6.4, 0.5.14, 0.4.24, and 0.3.10 are vulnerable to STARTTLS stripping attacks that allow network-positioned attackers to decrypt email credentials and message content despite applications believing connections are encrypted. Organizations using affected Ruby net-imap versions for email client functionality face credential theft and data exposure risks if they operate in or connect through untrusted networks.

Business Impact: High
Compensating Controls

Apply vendor patch. If immediate patching impossible: enforce mandatory TLS (disable STARTTLS fallback, require IMAPS on port 993), segment email clients to trusted networks only, and implement network monitoring for unencrypted IMAP traffic on port 143.

Threat Intelligence Overview

EPSS Score
0.1%
Top 84% exploitable
Threat Intel
1
1 sources
Data Quality
6 sources
Confidence: High
NVD CVE.org EPSS GHSA MSRC Vendor GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.1%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision· derived
Scheduled
Exploitation· derived
None
System Exposure· derived
Open
Automatable· derived
No
Human Impact
High

Priority Score

38
Low Medium High Critical
KEV: 0
EPSS: 0
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Information disclosure occurs when an application unintentionally exposes sensitive data that aids attackers in reconnaissance or directly compromises security.

Affected Products (CPE)CVE.org

pkg:rubygems/net-imap
pkg:rubygems/net-imap
pkg:rubygems/net-imap
pkg:rubygems/net-imap

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

References

Advisories & patches
PATCH https://github.com/ruby/net-imap/commit/0ede4c40b1523dfeaf95777b2678e54cc0fd9618 PATCH https://github.com/ruby/net-imap/commit/24a4e770b43230286a05aa2a9746cdbb3eb8485e PATCH https://github.com/ruby/net-imap/commit/97e2488fb5401a1783bddd959dde007d9fbce42c PATCH https://github.com/ruby/net-imap/commit/f79d35bf5833f186e81044c57c843eda30c873da ADVISORY https://github.com/ruby/net-imap/security/advisories/GHSA-vcgp-9326-pqcp ADVISORY https://ubuntu.com/security/notices/USN-8431-1 ADVISORY https://vuldb.com/vuln/362471 REF https://access.redhat.com/errata/RHSA-2026:33462 REF https://access.redhat.com/errata/RHSA-2026:33512 REF https://access.redhat.com/errata/RHSA-2026:33514 REF https://access.redhat.com/errata/RHSA-2026:33515 REF https://access.redhat.com/errata/RHSA-2026:33540 REF https://access.redhat.com/errata/RHSA-2026:33551 REF https://access.redhat.com/errata/RHSA-2026:33552 REF https://access.redhat.com/errata/RHSA-2026:33565 REF https://access.redhat.com/errata/RHSA-2026:33576 REF https://access.redhat.com/errata/RHSA-2026:33577 REF https://access.redhat.com/errata/RHSA-2026:33630 REF https://access.redhat.com/errata/RHSA-2026:33721 REF https://access.redhat.com/errata/RHSA-2026:34076 REF https://access.redhat.com/errata/RHSA-2026:35834 REF https://access.redhat.com/errata/RHSA-2026:35866 REF https://access.redhat.com/errata/RHSA-2026:35867 REF https://access.redhat.com/errata/RHSA-2026:35895 REF https://access.redhat.com/errata/RHSA-2026:36099 REF https://access.redhat.com/errata/RHSA-2026:37238 REF https://access.redhat.com/errata/RHSA-2026:37397 REF https://access.redhat.com/security/cve/CVE-2026-42246 REF https://bugzilla.redhat.com/show_bug.cgi?id=2468499 REF https://github.com/advisories/GHSA-vcgp-9326-pqcp REF https://github.com/ruby/net-imap/releases/tag/v0.3.10 REF https://github.com/ruby/net-imap/releases/tag/v0.4.24 REF https://github.com/ruby/net-imap/releases/tag/v0.5.14 REF https://github.com/ruby/net-imap/releases/tag/v0.6.4 REF https://nostarttls.secvuln.info REF https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-42246.json REF https://www.rfc-editor.org/info/rfc8314

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