🚨 [security] Update net-imap 0.5.14 → 0.5.15 (minor)

[depfu]

---

🚨 Your current dependencies have known security vulnerabilities 🚨

This dependency update fixes known security vulnerabilities. Please see the details below and assess their impact carefully. We recommend to merge and deploy this as soon as possible!

---

Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request.

What changed?

↗️ net-imap (indirect, 0.5.14 → 0.5.15) · Repo · Changelog

Security Advisories 🚨

🚨 Net::IMAP: Command Injection via non-synchronizing literal in "raw" argument

Several Net::IMAP commands accept a "raw data" argument that is sent verbatim after validation to prevent command injection. However, if a server does not support non-synchronizing literals, it may still be possible to inject arbitrary IMAP commands inside non-synchronizing literals.

Details

Raw data arguments support embedded literal values, both synchronizing and non-synchronizing. Non-synchronizing literals can only be safely sent when the server advertises any of the LITERAL+, LITERAL-, or IMAP4rev2 capabilities. But raw data arguments do not verify server support for non-synchronizing literals prior to sending.

Servers without support for non-synchronizing literals could handle them in several different ways: If a server sees a "}\r\n" byte sequence but can't parse the literal bytesize, it may cautiously decide to close the connection, blocking any command injection attacks. However, a server without support for non-synchronizing literals may instead interpret the "+}\r\n" as the end of a malformed command line and respond with a tagged BAD. In that case, the contents of the literal will be interpreted as one or more new pipelined commands, allowing a CRLF command injection attack to succeed.

This affects the following commands' string arguments:

• criteria for #search and #uid_search
• search_keys for #sort, #thread, #uid_sort, and #uid_thread
• attr for #fetch and #uid_fetch

Prior to net-imap v0.6.4, v0.5.14, and v0.4.24, raw data arguments were not validated in any way, so they were also vulnerable to this attack. See CVE-2026-42257 (GHSA-hm49-wcqc-g2xg).

Impact

Fortunately, LITERAL- is supported by most modern IMAP servers. Even without support for non-synchronizing literals, cautious servers may handle invalid literal bytesize by closing the connection . However, servers which handle a non-synchronizing literal just like any other malformed command will enable this vulnerability.

If a developer passes an unvalidated user-controlled input for one of these method arguments, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

Mitigation

Update to a version of net-imap which validates server support for non-synchronizing literals before sending them.

If upgrading net-imap is not possible:

• Explicitly validate user-controlled inputs to prevent embedded non-synchronizing literals unless the server supports them.
• For a simpler, more cautious approach: all embedded literals can be unconditionally prohibited, by checking that string inputs do not contain any CR or LF bytes.
• Verify that the server advertises any of the LITERAL+, LITERAL-, or IMAP4rev2 capabilities before using untrusted string inputs for the affected "raw data" arguments.

🚨 Net::IMAP: Denial of Service via incomplete raw argument validation

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.

🚨 Net::IMAP: Command Injection via ID command argument

Summary

Two Net::IMAP commands, #id and #enable, do not validate their arguments. Arguments to either command could be used by an attacker to inject arbitrary IMAP commands.

Please note that passing untrusted inputs to these commands is usually inappropriate and expected to be uncommon.

Details

When Net::IMAP#id is called with a hash argument, although the ID field value strings are correctly quoted (escaping quoted specials), they were not validated to prohibit CRLF sequences.

While Net::IMAP#enable does process its arguments for aliases, it does not validate them as valid atoms (or as a list of valid atoms). The #to_s value is sent verbatim.

Impact

This is expected to impact very few users: use of untrusted user input for either command is expected to be very uncommon.

The documentation for #enable explicitly warns that using any arguments that are not in the explicitly supported list may result in undocumented behavior. Using arbitrary untrusted user input for #enable will always be inappropriate.

Although client ID field values will most commonly be static and hardcoded, dynamic input sources may be used. For example, client ID fields may be set by configuration or version numbers. Using untrusted user inputs for client ID fields is expected to be uncommon. But any untrusted inputs to client ID can trivially exploit this vulnerability.

Untrusted inputs to either command may include a CRLF sequence followed by a new IMAP command (like DELETE mailbox). Although this does not directly enable data exfiltration, it could be combined with other attack vectors or knowledge of the target system's attributes, e.g.: shared mail folders or the application's installed response handlers.

Mitigation

Update to a version of net-imap which validates #id and #enable arguments.

Untrusted inputs should never be used for #enable arguments.

If net-imap cannot be upgraded:

• do not use untrusted inputs for client ID field values
• or add validation that client ID field values must not contain any CR or LF bytes.

Commits

See the full diff on Github. The new version differs by 23 commits:

• 🔖 Bump version to 0.5.15
• 🔀 Merge pull request #703 from ruby/backport/v0.5/security-patches
• 🍒 pick 0ea9eba3 (#701): ✅ Fix flaky tests for MacOS, TruffleRuby
• 🍒 pick ae9f83b5 (#701): ♻️ Extract str.bytesize lvar in send_literal
• 🍒 pick 62a0da6d (#701): 🥅 Validate non-synchronizing literals support
• 🍒 pick d6ddd294 (#700): 🐛 Prevent trailing `{0}` in RawData validation
• 🍒 pick 1f97168b (#699): 🥅 Validate `#enable` arguments are all atoms
• 🍒 pick 8d9397ab (#698): 🥅 Validate QuotedString contains only valid bytes
• 🍒 pick e3c50fad (#698): ♻️ Refactor RawText, add improve test coverage
• 🍒 pick aab64f92 (#686): 🧵 Fix deadlock in `#disconnect`
• 🔀 Merge pull request #696 from ruby/backport/v0.5-multiple
• 🔀 Merge branch 'backport/v0.5/pr679/raw_data-improvements' into v0.5-stable
• 🔀 Merge branch 'backport/v0.5-678-improvements-to-fake_server' into v0.5-stable
• 🍒 pick 257e51d0 (#679): ♻️ Extract RawData.split(string)
• 🍒 pick 95afda8f (#679): ♻️ Allow RawData.new to directly set parts array
• 🍒 pick a27a0022 (#678): ✅ Allow test server td ignore abrupt EOF
• 🍒 pick ef6fde3b (#678): ✅ Handle "stream closed" as EOF (tests only)
• 🍒 pick b02182ce (#678): ✅🐛 Fix FakeServer CommandParseError (tests only)
• 🍒 pick 0d508fa7 (#681): 🥅 Validate server's literal byte size format
• 🍒 pick 94c79576 (#677): 📚⚠️ Boost visibility of raw data argument warnings
• 🍒 pick 3fe06a4c (#676): 🥅 Ensure send_number_data input is an Integer
• 🍒 pick 5c213ab7 (#675): 🏷️ Allow 64-bit Integer arguments
• 🍒 pick e224fd67: 🥅 Validate that Atom and Flag are not empty

---

Depfu will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with @depfu rebase.

All Depfu comment commands

@​depfu rebase

Rebases against your default branch and redoes this update

@​depfu recreate

Recreates this PR, overwriting any edits that you've made to it

@​depfu merge

Merges this PR once your tests are passing and conflicts are resolved

@​depfu cancel merge

Cancels automatic merging of this PR

@​depfu close

Closes this PR and deletes the branch

@​depfu reopen

Restores the branch and reopens this PR (if it's closed)

@​depfu pause

Ignores all future updates for this dependency and closes this PR

@​depfu pause [minor|major]

Ignores all future minor/major updates for this dependency and closes this PR

@​depfu resume

Future versions of this dependency will create PRs again (leaves this PR as is)