What is the CVSS score of CVE-2026-42258?

CVE-2026-42258 has a CVSS 4.0 base score of 5.8 (Medium). CVSS vector: CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N. EPSS exploitation probability: 0.1%.

Is there a patch available for CVE-2026-42258?

Yes, a patch is available for CVE-2026-42258. Update the affected software to the latest version immediately.

Net::IMAP CVE-2026-42258

MEDIUM

Command Injection (CWE-77)

2026-05-04 https://github.com/ruby/net-imap

GHSA-75xq-5h9v-w6px

Command Injection

5.8

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

Recon

User provides malicious flag name
Delivery

Application calls to_sym on unvalidated input
Exploit

Symbol passed to Net::IMAP command (e.g., STORE)
Install

Net::IMAP sends symbol without validation to socket
C2

CRLF characters in symbol terminate current command and inject new IMAP command
Execute

IMAP server parses injected command
Impact

Arbitrary IMAP operation executed (DELETE, EXPUNGE, or other destructive action)

Vulnerability Assessment

Weakness	CWE CWE-77 OWASP Top 10:2025 A05:2025 - Injection ASVS 5.0 V1 - Encoding and Sanitization Command injection prevention MITRE ATT&CK 1 technique across 1 tactic: Execution The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. Sign in to read
Exploitation Conditions	Exploitation requires a specific developer coding error: the application must pass user-controlled input (or data derived from user input via unsafe deserialization) as a Symbol argument to Net::IMAP commands that accept flag parameters (primarily STORE, but also any command using generic argument handling that permits Symbol inputs). The vulnerability does not manifest in applications that (1) restrict flag inputs to hard-coded symbols defined in source code, (2) validate user input against an enumerated whitelist of standard IMAP flags before conversion to symbols, or (3) do not call #to_sym on user input at all. Default Net::IMAP deployments without such unsafe coding patterns are not vulnerable. The attacker must have network access to interact with the application's IMAP client, but does not require authentication to the IMAP server itself if the vulnerability exists in the application's client-side flag handling. The condition is not a non-default configuration of Net::IMAP itself, but rather a non-secure coding pattern in applications using it.
Impact	Risk assessment is constrained by the absence of CVSS score and vector data in the advisory. However, the vulnerability exhibits high real-world severity due to three factors: (1) Attack vector is network-accessible through IMAP protocol, (2) no authentication is required if the attacker can inject symbols into a developer's IMAP command chain, and (3) technical impact is critical-successful exploitation grants arbitrary command execution on the IMAP server, potentially enabling mailbox deletion, unauthorized flag modification, or other destructive operations. The prerequisite for exploitation is developer-level misuse (passing unsanitized user input as a Symbol), which is not a zero-day exploitation risk for production systems using well-written applications, but represents a code-quality vulnerability that could be exploited in applications that deserialize untrusted data into symbols or receive user input and call #to_sym on it. The SSVC framework would classify this as Relevant Scope Impact (changes authorization boundary - attacker escapes developer's intended flag argument context to execute arbitrary commands), triggering a high remediation priority. Patch availability and the relatively narrow exploitation pathway (must be a coding error in the calling application) reduce real-world urgency for most deployments, but any application using Net::IMAP with user-influenced Symbol flags requires immediate patching.
Exploit ScenarioDerived	An attacker crafts an application request (e.g., a web form or API call) that tags a mailbox with a user-supplied label. The vulnerable application calls `imap.store(mailbox_id, '+FLAGS', user_label.to_sym)` to set a flag based on the user input. The attacker submits a malicious label such as `Seen\r\nDELETE INBOX` (represented as a symbol after to_sym conversion). When Net::IMAP sends this to the IMAP server without validation, the unquoted symbol becomes `\Seen\r\nDELETE INBOX`, and the CRLF characters terminate the STORE command and inject a DELETE INBOX command, deleting the user's inbox.

This Month Plan within 30 days. Why: MEDIUM severity (CVSS 4.0-6.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

AnalysisAIv1 – May 04, 2026

Net::IMAP command injection via unvalidated Symbol arguments allows remote attackers to inject arbitrary IMAP commands by passing user-controlled input as Symbol flags, enabling attackers to append CRLF sequences followed by malicious commands like DELETE mailbox. The vulnerability affects Net::IMAP versions 0.4.23 and earlier, 0.5.0-0.5.13, and 0.6.0-0.6.3, and is remedied in versions 0.4.24, 0.5.14, and 0.6.4 respectively. No public exploit code or active exploitation has been reported at the time of analysis.

RemediationAI

Vendor-released patches are available: upgrade to Net::IMAP 0.4.24 (for legacy 0.4.x users), 0.5.14 (for 0.5.x users), or 0.6.4 (for 0.6.x and later users). Apply patches via Bundler with bundle update net-imap or manually install via gem install net-imap -v 0.6.4. For applications already using affected versions, do not pass user-supplied input to #to_sym or directly as Symbol arguments to IMAP commands; instead, restrict flag inputs to an enumerated list of standard RFC-defined system flags (\Seen, \Answered, \Flagged, \Deleted, \Draft, \Recent, and extensions like \Junk, \Important if supported by your server). Avoid unsafe serialization/deserialization (YAML.load, Marshal.load) of IMAP command arguments, as this can silently convert strings to symbols. For IMAP commands that do accept flag arguments (STORE, SELECT, etc.), hard-code symbol literals in source code rather than allowing dynamic flag specification from user input. Trade-off: restricting flags to an enumerated list may limit compatibility with server-specific or future IMAP extensions, but this is the correct defense-in-depth approach for security.

Affected Packages

rubygems net-imap fix: 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

Net::IMAP is Ruby's standard IMAP (Internet Message Access Protocol) client library. IMAP protocol uses atom-formatted system flags prefixed with a backslash (e.g., \Seen, \Flagged). The vulnerability stems from CWE-77 (Improper Neutralization of Special Elements used in a Command) - specifically, CRLF Injection. When developers pass user-controlled input converted to a Symbol (Ruby's immutable identifier type) to IMAP commands that accept flag arguments, Net::IMAP sends the symbol name directly to the socket without validating that it contains only valid IMAP flag characters. Since symbols bypass quoting in the IMAP protocol, an attacker can inject space (SP) and carriage-return/line-feed (CRLF) characters to terminate the current command and inject new IMAP commands. The root cause is the lack of input validation for symbol-formatted flags before transmission and the library's intentional decision not to restrict flag inputs to RFC-defined standard system flags (\Seen, \Answered, \Flagged, \Deleted, \Draft, \Recent, \Junk, \Important, etc.), delegating that responsibility to calling code.

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

Continue with Google Continue with GitHub

No credit card · 7-day full trial

Severity by source

Vendor (https://github.com/ruby/net-imap) PRIMARY 5.8 MEDIUM

CVSS:4.0/AV:L/AC:H/AT:P/PR:N/UI:P/VC:N/VI:H/VA:L/SC:N/SI:N/SA:N

SUSE 5.3 HIGH

AV:L/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:L

Red Hat 7.1 HIGH

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

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

Attack Vector

Local

Attack Complexity

High

Attack Requirements

Present

Privileges Required

None

User Interaction

Passive

Vulnerable system: Confidentiality

None

Vulnerable system: Integrity

High

Vulnerable system: Availability

Low

Subsequent system: Confidentiality

None

Subsequent system: Integrity

None

Subsequent system: Availability

None

Lifecycle Timeline

CVSS changed

May 09, 2026 - 20:22 NVD

5.8 (MEDIUM)

DescriptionCVE.org

Summary

Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands.

Details

Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a "\" prefix. Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation.

Because the Symbol input is unvalidated, it could contain invalid flag characters, including SP and CRLF, which could be used to finish the current command and inject new commands.

Although IMAP flag arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (flag) inputs.

Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics. Any user-provided values outside of that list of standard "system flags" needs to use the IMAP keyword syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should #to_sym ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that user_input_atom is as \user_input_atom.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list. That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox).

Mitigation

Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP flag.
User-provided input should never be able to control calling #to_sym on string arguments.

For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments.

For the few IMAP commands which do allow flag arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.

Threat Intelligence Overview

EPSS Score

0.1%

Top 74% exploitable

Threat Intel

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 MEDIUM

CISA KEV No

Public POC No

EPSS 0.1%

Patch available Yes

Active threat No

Deciding rule

MEDIUM severity (CVSS 4.0-6.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

Defer

Exploitation· derived

None

System Exposure· derived

Small

Automatable· derived

Human Impact· derived

Medium

Priority Score

Low Medium High Critical

KEV: 0

EPSS: 0

CVSS: +29

PoC: 0

Weaponized: 0

Threat intel: 0

Gov advisory: 0

Attack Technique

OS Command Injection CRITICAL

OS command injection occurs when an application passes unsanitized user input directly into system shell commands.

Affected Products (CPE)CVE.org

pkg:rubygems/net-imap

Same weakness CWE-77 – Command Injection

View all

CVE-2024-21887 CRITICAL POC

9.1

CVE-2016-3081 HIGH POC

8.1

CVE-2012-1823 CRITICAL POC

9.8

CVE-2016-1555 CRITICAL POC

9.8

CVE-2024-55956 CRITICAL POC

9.8

CVE-2015-2051 HIGH POC

8.8

CVE-2017-6327 HIGH POC

8.8

CVE-2023-34960 CRITICAL POC

9.8

Same technique Command Injection

View all

CVE-2019-15107 CRITICAL POC

9.8

CVE-2024-51378 CRITICAL POC

9.8

CVE-2014-6271 CRITICAL POC

9.8

Vendor StatusVendor

SUSE

Severity: Important

Product	Status
SUSE Linux Enterprise Desktop 15 SP7	Not-Affected
SUSE Linux Enterprise Desktop 15 SP7	Affected
SUSE Linux Enterprise Desktop 15 SP7	Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Affected
SUSE Linux Enterprise High Availability Extension 15 SP7	Affected

References

Advisories & patches

Search Externally

GitHub PoC

Exploit-DB PacketStorm Snyk Rapid7 Nuclei Templates Trickest PoC

Back