CVE-2026-42257

What it actually does

Net::IMAP versions before 0.4.24, 0.5.14, and 0.6.4 allow raw string arguments in several IMAP client commands to be sent to the mail server without validation or escaping. If an application passes attacker-controlled input into one of those arguments, carriage-return/line-feed sequences can terminate the intended IMAP command and inject additional commands on the same authenticated IMAP connection. The injected commands execute with the privileges of the mailbox account used by the application, enabling unauthorized mailbox manipulation such as changing message flags, moving/copying mail, creating or deleting mailboxes, appending messages, or expunging messages. Impact depends on which Net::IMAP methods are reachable with user-controlled data and what mailbox permissions the application’s IMAP credentials have.

Why it matters to the business

Applications that use vulnerable Net::IMAP versions may allow attackers to misuse the organization’s mailbox access from inside a trusted application workflow. This can lead to email deletion, tampering with message state, unauthorized mailbox changes, disruption of mail-processing jobs, corruption of ticketing or workflow queues backed by email, and potential exposure of sensitive mail content if application responses or logs reveal injected command output. Because Net::IMAP is a common Ruby library component, risk may exist indirectly through applications or dependencies even when teams did not intentionally build low-level IMAP protocol handling.

How an attack unfolds

An attacker first finds an application feature that uses Ruby Net::IMAP to interact with an IMAP server and that places user-controlled data into an affected raw string argument, such as a mailbox name, search expression, message-set value, or other command parameter. The attacker submits input containing CRLF characters so the IMAP server treats the remainder as a new command rather than as data for the intended command. The application then opens or reuses an authenticated IMAP session and sends the constructed command string to the server. The IMAP server processes the attacker-injected command in the context of the application’s mailbox credentials. Depending on those privileges, the attacker may alter flags, move or delete messages, create or rename mailboxes, append crafted email content, or trigger expunge operations. Exploitation generally requires a vulnerable application data path; the library flaw is not directly reachable unless untrusted input reaches the affected Net::IMAP command arguments.

How to fix it

Upgrade Net::IMAP to a patched release: 0.4.24 or later for the 0.4.x line, 0.5.14 or later for the 0.5.x line, or 0.6.4 or later for the 0.6.x line. In Ruby applications, update the dependency in Gemfile/Gemspec constraints and regenerate Gemfile.lock or the equivalent lockfile. If Net::IMAP is pulled in transitively, update the parent package or add an explicit safe version constraint. As defense in depth, do not pass untrusted strings into raw IMAP command arguments; validate mailbox names, message identifiers, search expressions, and command parameters against strict allowlists; reject CR, LF, and other protocol control characters; and prefer structured Net::IMAP APIs that quote or encode arguments correctly. Limit the IMAP account used by applications to the minimum mailbox permissions required and avoid using broadly privileged mail accounts for automated processing.

How to confirm the fix worked

Confirm dependency versions by reviewing Gemfile.lock, gem dependency output, software composition analysis results, and deployed container or package inventories for net-imap versions lower than 0.4.24, 0.5.14, or 0.6.4. Validate the fix with a negative test that submits user-controlled values containing CRLF sequences into any feature that reaches Net::IMAP and confirms the application rejects the input or sends it safely without generating an additional IMAP command. If IMAP protocol/debug logging is available in a test environment, verify that one application action results only in the intended IMAP command and no extra injected command. Review code for direct use of raw-string Net::IMAP command arguments and confirm input validation or safe encoding is applied before deployment.

Typical attack path

1. Identify a Ruby application or service that uses vulnerable Net::IMAP versions prior to 0.4.24, 0.5.14, or 0.6.4.
2. Find an application field, API parameter, webhook payload, or message-derived value that is passed into a Net::IMAP command as a raw string.
3. Submit a value containing CRLF command separators and an additional IMAP command payload.
4. The application sends the unescaped string to the IMAP server over an authenticated connection.
5. The IMAP server interprets the injected content as one or more separate IMAP commands.
6. The attacker achieves mailbox tampering, message deletion, message movement, flag manipulation, mailbox creation/deletion, or other actions allowed by the application’s IMAP account.

How to detect it

To determine whether exploitation already occurred, correlate application request logs, API logs, background job logs, and IMAP server audit logs for user-controlled values containing carriage-return/line-feed characters or URL-encoded equivalents followed by IMAP command words. Look for one application-level action producing multiple IMAP commands, especially unexpected STORE, COPY, MOVE, APPEND, CREATE, DELETE, RENAME, SUBSCRIBE, UNSUBSCRIBE, or EXPUNGE commands. Review mail server logs for unusual message flag changes, unexpected mailbox creation/deletion/renaming, abnormal expunge operations, or command sequences that do not match normal application behavior. If Net::IMAP debug logging was enabled, inspect raw protocol transcripts for embedded CRLF in arguments and additional commands appearing immediately after attacker-controlled strings. Also review web access logs, WAF logs, and API gateway logs for parameters containing %0d%0a, %0D%0A, literal CRLF, or double-encoded CRLF values. Because exploitation occurs through the application’s legitimate IMAP credentials, indicators may appear as authorized IMAP activity rather than authentication failures.

• %0d%0a
• %0D%0A
• %250d%250a
• %250D%250A
• \r\n STORE
• \r\n UID STORE
• \r\n EXPUNGE
• \r\n UID EXPUNGE
• \r\n DELETE
• \r\n CREATE
• \r\n RENAME
• \r\n APPEND
• \r\n COPY
• \r\n UID COPY
• \r\n MOVE
• \r\n UID MOVE
• \r\n SUBSCRIBE
• \r\n UNSUBSCRIBE
• net-imap (0.4.23)
• net-imap (0.5.13)
• net-imap (0.6.3)
• /gems/net-imap-0.4.23/
• /gems/net-imap-0.5.13/
• /gems/net-imap-0.6.3/

What your security team should do

• Inventory Ruby applications, background workers, mail ingestion services, and dependencies for Net::IMAP usage and prioritize internet-facing or externally influenced workflows.
• Upgrade Net::IMAP to 0.4.24, 0.5.14, 0.6.4, or newer according to the dependency branch in use.
• Search code for Net::IMAP calls that accept raw string parameters and trace whether any values originate from HTTP requests, APIs, webhooks, email content, queue messages, or other untrusted sources.
• Add centralized validation that rejects CR and LF characters in fields later used as IMAP command parameters unless they are explicitly expected and safely encoded.
• Review IMAP account permissions used by applications and reduce privileges to only required mailboxes and operations.
• Enable or temporarily increase IMAP server and application audit logging for mail-modifying commands while remediation is underway.
• Investigate unusual mailbox changes, message deletions, expunge activity, or abnormal command sequences around externally supplied application inputs.