🚨 [security] [ruby] Update net-imap 0.6.4 → 0.6.4.1 (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.6.4 → 0.6.4.1) · 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.

Commits

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

• 🔖 Bump version to 0.6.4.1
• 🔀 Merge pull request #701 from ruby/security/validate-non_sync_literal-support
• ✅ Fix flaky tests for MacOS, TruffleRuby
• 🔀 Merge pull request #700 from ruby/security/fix-raw_data-trailing-literal-marker-validation
• 🔀 Merge pull request #699 from ruby/security/validate-enable-arguments
• 🔀 Merge pull request #698 from ruby/security/validate-quoted-data
• ♻️ Use QuotedString internally to send quoted string
• ♻️ Extract str.bytesize lvar in send_literal
• 🐛 Prevent trailing `{0}` in RawData validation
• 🥅 Validate `#enable` arguments are all atoms
• 🥅 Validate QuotedString contains only valid bytes
• 🥅 Validate non-synchronizing literals support
• ♻️ Refactor RawText, add improve test coverage
• 🧵 Fix deadlock in `#disconnect`
• ⬆️ Bump step-security/harden-runner from 2.19.3 to 2.19.4 (#683)
• 🥅 Validate that Atom and Flag are not empty
• 🥅 Validate server's literal byte size format
• ⬆️ Bump step-security/harden-runner from 2.19.1 to 2.19.3 (#682)
• 🔀 Merge pull request #680 from ruby/less-strict-number-coersion
• 🐛 Less strict number coercion, to match RFCs
• ✅ Refactor NumValidatorTest some more
• ✅ Refactor NumValidatorTest
• 🔀 Merge pull request #679 from ruby/raw_data-improvements
• ♻️ Extract RawData.split(string)
• ♻️ Allow RawData.new to directly set parts array
• 🔀 Merge pull request #678 from ruby/test-server-improvements
• ✅ Allow test server td ignore abrupt EOF
• ✅ Handle "stream closed" as EOF (tests only)
• ✅🐛 Fix FakeServer CommandParseError (tests only)
• 📚⚠️ Boost visibility of raw data argument warnings
• 🥅 Ensure send_number_data input is an Integer
• 🏷 Allow 64-bit Integer arguments
• ⬆️ Bump step-security/harden-runner from 2.19.0 to 2.19.1 (#673)
• 🔍 Add more detail to `Net::IMAP#inspect` TLS info
• 🔧 Disallow max_non_synchronizing_literal = nil

---

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)