CVE-2026-47242

What it actually does

This is an IMAP protocol command-injection flaw in the Ruby net-imap library. Before net-imap 0.6.5 and 0.5.15, Net::IMAP#id correctly quoted special characters in ID field values but failed to reject carriage-return/line-feed sequences, allowing an attacker-controlled value to terminate the current IMAP command and append another command. Net::IMAP#enable also accepted argument values whose string representation was sent verbatim without validating that they were legal IMAP atoms. If an application passes attacker-influenced data to either method, the attacker can inject arbitrary IMAP commands that execute in the context of the already-established IMAP session. This affects mailbox/session integrity and may cause limited availability impact; it is not an operating-system command execution vulnerability.

Why it matters to the business

Applications using affected net-imap versions can be tricked into sending unintended mail-server commands if they pass untrusted input into IMAP ID or ENABLE calls. The practical consequence is unauthorized mailbox changes, message deletion or flag manipulation, disruption of mail workflows, and possible abuse of the application’s mail account permissions. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no reported exploit maturity in the supplied data, but it should still be remediated because it is a library-level flaw that may be present in multiple Ruby applications and can be difficult to detect once bundled into downstream software.

How an attack unfolds

An attacker first identifies an application feature that ultimately calls Net::IMAP#id with a hash value or Net::IMAP#enable with extension names derived from user-controlled or externally supplied data. The attacker submits a crafted value containing CRLF characters or malformed atom content so that the generated IMAP wire command is split into multiple commands. When the Ruby application connects to the IMAP server and invokes the vulnerable method, net-imap transmits the attacker-controlled bytes as part of the authenticated IMAP session. The mail server then processes the injected command with the permissions of that session, allowing the attacker to manipulate mailbox state, alter flags, delete or append messages, select folders, or otherwise execute IMAP actions available to the application’s credentials. Successful exploitation generally requires application-specific data flow from attacker input into these methods and user/application interaction that causes the IMAP call to be made.

How to fix it

Upgrade the Ruby net-imap package to a fixed version: use net-imap 0.6.5 or later for the 0.6.x line, or net-imap 0.5.15 or later for the 0.5.x line. Regenerate and redeploy lockfiles so applications actually consume the patched gem. If immediate upgrade is not possible, ensure no untrusted or externally supplied data reaches Net::IMAP#id or Net::IMAP#enable; reject any ID values containing CR or LF characters; validate ENABLE arguments against a strict allowlist of expected IMAP extension atoms; and avoid calling these methods with arbitrary object values whose to_s output is not controlled. Apply least-privilege mailbox credentials so application IMAP accounts can only perform necessary operations.

How to confirm the fix worked

Confirm dependency state using package inventory and lockfiles, such as Gemfile.lock, gem list net-imap, bundle info net-imap, or software composition analysis output, and verify the resolved version is 0.6.5/0.5.15 or newer. Review code for calls to Net::IMAP#id and Net::IMAP#enable and confirm their arguments are either constants, trusted internal values, or strictly validated. Add regression tests that attempt to pass strings containing \r, \n, or \r\n into ID values and malformed ENABLE values, and confirm the patched library rejects them rather than emitting additional IMAP commands. Where feasible, capture IMAP traffic in a test environment and verify one application call produces only the intended IMAP command without embedded line breaks from user-controlled fields.

Typical attack path

1. Find a Ruby application or service that uses the net-imap gem for outbound IMAP client operations.
2. Identify an input path that influences values passed to Net::IMAP#id or arguments passed to Net::IMAP#enable.
3. Craft input containing CRLF command separators or invalid ENABLE atom content followed by an additional IMAP command.
4. Trigger the application workflow that opens an authenticated IMAP session and calls the vulnerable method.
5. The vulnerable library sends the injected IMAP command sequence to the mail server.
6. The IMAP server executes the injected command using the application’s authenticated mailbox permissions.
7. The attacker observes or benefits from modified mailbox state, deleted messages, altered flags, or disrupted mail processing.

How to detect it

To determine whether exploitation already occurred, review IMAP server logs, mail gateway telemetry, and application logs around workflows that invoke IMAP ID or ENABLE commands. Look for abnormal command sequences where an ID or ENABLE command is immediately followed by unexpected mailbox-changing commands from the same authenticated session, especially if those commands correlate with user-supplied metadata or request parameters. Useful log sources include IMAP authentication/session logs, protocol debug logs from Dovecot/Cyrus/Exchange-compatible IMAP services, Ruby application logs containing net-imap debug output, reverse proxy or web application logs for suspicious CRLF-encoded input, and mailbox audit logs showing unexpected DELETE, EXPUNGE, STORE, COPY, MOVE, APPEND, RENAME, or flag changes. Investigate any request values containing raw or URL-encoded carriage-return/line-feed sequences that occur shortly before unusual IMAP commands. There are no known public exploit artifacts in the supplied data, so detection should focus on protocol anomalies and suspicious input-to-mail-session correlation rather than a single fixed payload.

• %0d%0a
• %0D%0A
• \r\n
• ID .*\r\n
• ENABLE .*\r\n
• ID .*%0d%0a
• ENABLE .*%0d%0a
• ID .* EXPUNGE
• ID .* STORE
• ID .* DELETE
• ID .* APPEND
• ID .* RENAME
• ID .* MOVE
• ENABLE .* EXPUNGE
• ENABLE .* STORE
• ENABLE .* DELETE
• ENABLE .* APPEND
• ENABLE .* RENAME
• ENABLE .* MOVE
• Net::IMAP#id
• Net::IMAP#enable

What your security team should do

• Prioritize upgrading net-imap to 0.6.5 or later, or 0.5.15 or later for applications pinned to the 0.5.x branch.
• Search application repositories and dependency inventories for net-imap usage, especially direct calls to Net::IMAP#id and Net::IMAP#enable.
• Review data flow into those methods and remove, sanitize, or strictly allowlist any user-controlled values.
• Deploy patched builds and verify production artifacts use the fixed gem version rather than only updating source manifests.
• Monitor IMAP server logs for unusual command sequences immediately following ID or ENABLE commands from application clients.
• Restrict IMAP account permissions and mailbox scope used by applications to reduce the blast radius of injected commands.
• Because current EPSS is low and the CVE is not in KEV, schedule remediation through normal vulnerability management unless the application exposes attacker-controlled inputs to the affected methods, in which case treat as higher priority.