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 `}`.
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?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| Cohere | rubygems | >= 0.6.0, <= 0.6.4 | 0.6.4.1 |
Do you use Cohere? You're affected.
How severe is it?
What should I do?
5 steps-
Upgrade net-imap to 0.6.4.1 (patched release).
-
If immediate upgrade is blocked, validate that user-supplied input to
criteria,search_keys, andattrdoes not end with}. -
Apply connection-level timeouts (
open_timeout,read_timeout) to bound the hang window. -
Audit all Gemfiles and lock files for net-imap versions in the affected range (>= 0.6.0, <= 0.6.4).
-
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:
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
MITRE ATLAS Techniques
AML.T0029 Denial of AI Service AML.T0049 Exploit Public-Facing Application Compliance Controls Affected
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.
Weaknesses (CWE)
References
Timeline
Related Vulnerabilities
CVE-2026-33660 10.0 TensorFlow: type confusion NPD in tensor conversion
Same attack type: DoS CVE-2023-25668 9.8 TensorFlow: unauthenticated RCE via heap buffer overflow
Same attack type: DoS CVE-2022-23587 9.8 TensorFlow: integer overflow in Grappler enables RCE
Same attack type: DoS CVE-2022-35939 9.8 TensorFlow: ScatterNd OOB write enables RCE/crash
Same attack type: DoS CVE-2022-41900 9.8 TensorFlow: heap OOB RCE in FractionalMaxPool op
Same attack type: DoS