CVE-2026-47240

What it actually does

This is an IMAP command injection issue in the Ruby Net::IMAP client library. Certain methods accept raw IMAP data arguments and, in vulnerable versions, can send non-synchronizing literals in a way that is unsafe when the IMAP server does not support that capability. A crafted argument containing CRLF-delimited IMAP syntax can cause the server to treat the remainder of the literal as additional pipelined IMAP commands. Successful exploitation allows an attacker-influenced input value to issue unintended IMAP commands using the client’s authenticated mail session, potentially modifying mailbox contents, deleting messages, copying messages, changing flags, or disrupting mailbox access. The issue affects search, sort, thread, UID variants, and fetch-related arguments before Net::IMAP 0.6.5 and 0.5.15.

Why it matters to the business

Applications that use vulnerable Net::IMAP versions and pass attacker-controlled or insufficiently trusted values into affected IMAP operations could allow unauthorized mailbox actions. The most likely business consequences are email tampering, message deletion, unintended disclosure through server-side copy or fetch behavior, workflow disruption for mail-driven applications, and incident response effort around mailbox integrity. This is not listed in CISA KEV, has no reported ransomware association, and has a low EPSS score, but it should still be remediated because mailboxes often contain sensitive business data and the vulnerable pattern may exist in automation, helpdesk, ticketing, monitoring, or ingestion systems.

How an attack unfolds

An attacker first needs a path to influence data passed into vulnerable Net::IMAP methods such as search, uid_search, sort, thread, uid_sort, uid_thread, fetch, or uid_fetch. The vulnerable client sends this data as an IMAP literal. If the connected IMAP server does not support non-synchronizing literals, it may reject the malformed command line and then parse the literal body as subsequent IMAP commands. The attacker crafts input so that after the server returns a tagged BAD response, injected commands are interpreted in sequence under the already-authenticated client session. Depending on mailbox permissions and the injected commands, the attacker may mark messages as read, add deletion flags, expunge mail, copy messages to other folders, perform unauthorized searches, or interfere with application mail processing. There is currently no public exploit maturity reported and no known named threat actor activity tied to this vulnerability.

How to fix it

Upgrade the Ruby Net::IMAP package to a fixed version: 0.6.5 or later for the 0.6.x line, or 0.5.15 or later for the 0.5.x line. If Net::IMAP is bundled or pinned through a Ruby application dependency chain, update the lockfile and redeploy the application so the fixed gem is actually loaded at runtime. Review application code for use of search, uid_search, sort, thread, uid_sort, uid_thread, fetch, and uid_fetch where user-controlled input may be passed into criteria, search_keys, or attr arguments. As defense in depth, strictly validate or construct IMAP arguments from allowlisted tokens rather than concatenating raw user input, avoid connecting to untrusted IMAP servers, and restrict mailbox account permissions where possible. If immediate upgrade is not possible, block attacker-controlled values from reaching the affected arguments and disable features that accept arbitrary IMAP search, sort, thread, or fetch expressions.

How to confirm the fix worked

Confirm the deployed Net::IMAP version is 0.6.5 or later, or 0.5.15 or later, using dependency manifests, lockfiles, package inventory, and runtime checks such as `bundle exec ruby -r net/imap -e 'puts Net::IMAP::VERSION'` where applicable. Verify that application containers, build artifacts, and production runtimes do not retain older vendored gem copies. Review code paths to ensure affected methods do not receive raw untrusted input. Where safe testing is possible, use a controlled IMAP test server without non-synchronizing literal support and confirm that crafted CRLF-containing values are rejected or safely encoded rather than producing additional server-side IMAP commands. Monitor mail server logs after remediation to verify that unexpected BAD responses followed by state-changing IMAP commands no longer occur from application accounts.

Typical attack path

1. Identify an application or automation that uses Ruby Net::IMAP before 0.6.5 or 0.5.15.
2. Find an input path that is passed into affected Net::IMAP command arguments, such as search criteria, sort or thread keys, or fetch attributes.
3. Ensure or target an IMAP server behavior where non-synchronizing literals are unsupported or mishandled.
4. Submit a crafted value containing IMAP literal-breaking syntax and CRLF-delimited commands.
5. The vulnerable client sends the crafted value to the IMAP server during an authenticated IMAP operation.
6. The server rejects the malformed literal command and then interprets the injected content as additional pipelined IMAP commands.
7. Injected commands execute with the privileges of the authenticated IMAP session, affecting mailbox state or availability.

How to detect it

Look for evidence that an application account issued malformed IMAP commands followed immediately by unexpected valid IMAP commands in the same authenticated session. Useful sources include IMAP server logs, mailbox audit logs, application logs around Net::IMAP operations, reverse proxy or mail gateway logs if IMAP is proxied, endpoint telemetry from application hosts, and dependency inventories showing vulnerable gem versions. Focus on sessions from application service accounts where a tagged BAD response, malformed literal, or parse error is followed by state-changing commands such as STORE, UID STORE, COPY, UID COPY, EXPUNGE, CLOSE, MOVE, UID MOVE, or unexpected FETCH/UID FETCH activity. Investigate any request or application parameter containing CRLF sequences, IMAP literals ending in `+}`, or embedded IMAP commands. Because exploitation occurs over a normal authenticated IMAP session, network indicators may be subtle; session sequencing and mailbox audit anomalies are more reliable than IP-based detection. There are no known public threat actor campaigns for this issue as of the provided context.

• +}\r\n
• }\r\n
• BAD
• tagged BAD
• non-synchronizing literal
• malformed command line
• STORE +FLAGS \\Deleted
• UID STORE
• EXPUNGE
• UID EXPUNGE
• COPY
• UID COPY
• MOVE
• UID MOVE
• CLOSE
• UID FETCH
• Net::IMAP::BadResponseError
• Net::IMAP::ResponseParseError

What your security team should do

• Inventory Ruby applications and services that use Net::IMAP, including transitive or vendored gem usage.
• Prioritize upgrades to Net::IMAP 0.6.5 or later, or 0.5.15 or later, especially for internet-facing, multi-tenant, or mail-processing applications that accept user-supplied search or fetch parameters.
• Search source code for affected method calls: search, uid_search, sort, thread, uid_sort, uid_thread, fetch, and uid_fetch.
• Add input validation or allowlists for IMAP criteria, search keys, thread keys, sort keys, and fetch attributes instead of passing raw request parameters to Net::IMAP.
• Review IMAP server audit logs for application mailbox accounts for malformed commands, tagged BAD responses, unexpected EXPUNGE operations, deletion flag changes, mailbox copies, or unusual UID FETCH activity.
• Use least-privilege mailbox accounts for automation and avoid granting broad mailbox access where read-only access is sufficient.
• Add regression tests that exercise CRLF and IMAP metacharacter handling for all user-controlled mail query features.