CVE-2026-47241: net-imap: IMAP command smuggling enables DoS

GHSA-c4fp-cxrr-mj66 LOW
Published June 9, 2026
CISO Take

Ruby's net-imap library (versions 0.6.0–0.6.4) contains a regex validation bypass that allows IMAP literal continuation markers (`{0}`, `{0+}`) to pass the `RawData` sanitization layer undetected in `search`, `fetch`, and `sort` operations. An attacker who can influence IMAP command arguments — such as user-defined search criteria or fetch attributes flowing into a Ruby email-processing backend — can force those commands to hang indefinitely, causing thread exhaustion and application-level denial of service. With 653 downstream Ruby dependents and an OpenSSF score of 5.2/10, the indirect blast radius for AI platform components relying on Ruby for email notification, breaking alert dispatch, or incident ingestion is non-trivial. No public exploits exist, this is absent from CISA KEV, and no EPSS data is available, placing active exploitation risk as low. Patch to net-imap 0.6.4.1; if immediate upgrade is not feasible, validate that user-controlled IMAP arguments do not end with `}`.

Sources: NVD GitHub Advisory OpenSSF ATLAS

What is the risk?

Low overall risk. No CVSS score has been assigned, exploitation is not observed in the wild, and the vulnerability is not in CISA KEV. Exploitation requires attacker-controlled data to reach IMAP command arguments — a narrower attack surface than typical injection flaws. Impact is limited to availability; there is no direct path to confidentiality or integrity compromise. The 653 downstream dependents warrant a gem audit, but this is a patch-at-next-cycle item for most organizations unless Ruby IMAP is actively used with user-supplied search or fetch criteria in a latency-sensitive or multi-threaded context.

How does the attack unfold?

Input Injection
Attacker supplies a user-controlled string ending in `{0}` or `{0+}` as an IMAP search criterion, fetch attribute, or sort key in a Ruby application using net-imap.
AML.T0049
Validation Bypass
The flawed `RawData` regex in net-imap 0.6.0–0.6.4 fails to reject the trailing literal-continuation marker, and the malformed string is sent verbatim to the IMAP server.
Command Smuggling
The IMAP server interprets `{0}\r\n` as a literal prefix, consuming the next client command as an argument and leaving both the original and subsequent commands in a hung state.
Denial of Service
Hung threads block until IMAP connection timeout, exhausting connection pools and disabling email-dependent AI service components such as alert dispatch or incident notification pipelines.
AML.T0029

What systems are affected?

Package Ecosystem Vulnerable Range Patched
Cohere rubygems >= 0.6.0, <= 0.6.4 0.6.4.1
387 OpenSSF 5.2 653 dependents Pushed 8d ago 100% patched ~0d to patch Full package profile →

Do you use Cohere? You're affected.

How severe is it?

CVSS 3.1
N/A
EPSS
N/A
Exploitation Status
No known exploitation
Sophistication
Moderate

What should I do?

5 steps
  1. Upgrade net-imap to 0.6.4.1 (patched release).

  2. If immediate upgrade is blocked, validate that user-supplied input to criteria, search_keys, and attr does not end with }.

  3. Apply connection-level timeouts (open_timeout, read_timeout) to bound the hang window.

  4. Audit all Gemfiles and lock files for net-imap versions in the affected range (>= 0.6.0, <= 0.6.4).

  5. In multi-threaded contexts, add explicit synchronization around IMAP command sequences to reduce cascading thread failures.

How is it classified?

Which compliance frameworks are affected?

This CVE is relevant to:

ISO 42001
A.6.2 - AI system resources
NIST AI RMF
MS-2.5 - AI System Reliability and Robustness

Frequently Asked Questions

What is CVE-2026-47241?

Ruby's net-imap library (versions 0.6.0–0.6.4) contains a regex validation bypass that allows IMAP literal continuation markers (`{0}`, `{0+}`) to pass the `RawData` sanitization layer undetected in `search`, `fetch`, and `sort` operations. An attacker who can influence IMAP command arguments — such as user-defined search criteria or fetch attributes flowing into a Ruby email-processing backend — can force those commands to hang indefinitely, causing thread exhaustion and application-level denial of service. With 653 downstream Ruby dependents and an OpenSSF score of 5.2/10, the indirect blast radius for AI platform components relying on Ruby for email notification, breaking alert dispatch, or incident ingestion is non-trivial. No public exploits exist, this is absent from CISA KEV, and no EPSS data is available, placing active exploitation risk as low. Patch to net-imap 0.6.4.1; if immediate upgrade is not feasible, validate that user-controlled IMAP arguments do not end with `}`.

Is CVE-2026-47241 actively exploited?

No confirmed active exploitation of CVE-2026-47241 has been reported, but organizations should still patch proactively.

How to fix CVE-2026-47241?

1. Upgrade net-imap to 0.6.4.1 (patched release). 2. If immediate upgrade is blocked, validate that user-supplied input to `criteria`, `search_keys`, and `attr` does not end with `}`. 3. Apply connection-level timeouts (`open_timeout`, `read_timeout`) to bound the hang window. 4. Audit all Gemfiles and lock files for net-imap versions in the affected range (>= 0.6.0, <= 0.6.4). 5. In multi-threaded contexts, add explicit synchronization around IMAP command sequences to reduce cascading thread failures.

What systems are affected by CVE-2026-47241?

This vulnerability affects the following AI/ML architecture patterns: email notification pipelines, Ruby-based AI application backends, multi-threaded IMAP email processing.

What is the CVSS score for CVE-2026-47241?

No CVSS score has been assigned yet.

What is the AI security impact?

Affected AI Architectures

email notification pipelinesRuby-based AI application backendsmulti-threaded IMAP email processing

MITRE ATLAS Techniques

AML.T0029 Denial of AI Service
AML.T0049 Exploit Public-Facing Application

Compliance Controls Affected

ISO 42001: A.6.2
NIST AI RMF: MS-2.5

What are the technical details?

Original Advisory

### Summary Several Net::IMAP commands accept a raw string argument which is only validated to prevent CRLF injection and then sent verbatim. If this string is derived from user-controlled input, an attacker can force the next command to be absorbed as a continuation of the first command. This will cause the first command to eventually fail, but also prevents it from returning until another command is sent (from another thread). That other command will not return until the connection is closed. ### Details `Net::IMAP::RawData` was hardened in v0.6.4, v0.5.14, and v0.4.24 to reject string arguments that would smuggle an invalid literal-continuation marker onto the wire (CVE-2026-42257, GHSA-hm49-wcqc-g2xg). But the trailing-marker check uses an incorrect regex which does not match `{0}` or `{0+}`, so an attacker-controlled seach `criteria` or fetch `attr` string ending in `{0}` or `{0+}` passes validation and is sent verbatim. Since these arguments are sent as the last argument in the command, they will be followed by CRLF. Although the CRLF was intended to end the command, the server will interpret it as part of a literal prefix. This consumes the next command the client puts on the socket as additional arguments to the current command. This affects the following command's arguments: * `criteria` for `#search` and `#uid_search` * `search_keys` for `#sort`, `#thread`, `#uid_sort`, and `#uid_thread` * `attr` for `#fetch` and `#uid_fetch` The command which contained the attacker's raw data will not be able to complete until the _next_ command is issued. If commands are only sent from single thread, the first command will hang until the connection times out (most likely by the server closing the connection). If a second command is sent _(from another thread)_, this would allow the server to respond to the first command. This combined command _will_ be invalid: * The `{0}\r\n` literal prohibits other arguments (such as a quoted string) from spanning both commands * It will be sent without the space delimiter which is required between arguments. * The second command's tag will not be a valid argument to any of the vulnerable commands. So the server _should_ respond to the first command with a `BAD` response, which will raise a `BadResponseError`. But, since the server never saw a second command, the second command will never receive a tagged response and the thread that sent it will hang until the connection is closed. ### Impact This will result in unexpected crashes and timeouts, which could be used to create a simple denial of service attack. This attack will present very similarly to common network issues or server issues which also result in commands hanging or unexpectedly raising exceptions. By itself, this does not allow command injection. But the confusion caused by these errors could lead to other downstream issues, especially in a multi-threaded environment. ### Mitigation Update to a patched version of `net-imap` which validates that `RawData` arguments may not end with literal continuation markers. If `net-imap` cannot be upgraded: * Validate that user input to the affected command arguments does not end with `"}"`. * Use of `Timeout` or other standard strategies for slow connections and misbehaving servers will also mitigate the effects of this. _Extra caution is required when issuing commands from multiple threads._ While `net-imap` does have rudimentary support for issuing commands from multiple threads, the user is responsible for synchronizing that commands are issued in a logically coherent order, and for ensuring that commands are only pipelined when it is safe to do so. Practically, this means that many commands cannot be safely pipelined together, and user code will often need to wait for state changing commands to successfully complete before issuing commands that rely on that state change.

Exploitation Scenario

An attacker targeting a Ruby-based AI platform's email notification service crafts a search criterion ending in `{0}` — for example, a CVE alert keyword or newsletter filter string. The malformed input bypasses net-imap's `RawData` regex check and is sent verbatim to the IMAP server. The server interprets the trailing `{0}\r\n` as a literal prefix rather than command termination and waits for additional data, leaving the client command hung. If the application spawns a second thread to issue another IMAP command (a concurrent alert query or inbox poll), the server consumes that command as an argument to the first, returning a `BAD` response to the first and leaving the second thread blocked until the connection is forcibly closed. Repeated across a thread pool, this constitutes a sustained denial of service against the email processing component without requiring any server-side credentials.

Timeline

Published
June 9, 2026
Last Modified
June 9, 2026
First Seen
June 9, 2026

Related Vulnerabilities