Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
10 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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 #tos 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…
Recommended action: Upgrade to 0.6.4.1 or 0.5.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.6.4.1 or 0.5.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.6.4.1 or 0.5.15 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Several Net::IMAP commands accept a raw string argument that is sent to the server without validation or escaping. If this string is derived from user-controlled input, it may contain contain CRLF sequences, which an attacker can use to inject arbitrary IMAP commands. Details Net::IMAP's generic argument handling, used by most command arguments, interprets string arguments as an IMAP astring. Depending on the string contents and the connection's UTF-8 support, this encodes strings as either a atom, quoted, or literal. These are safe from command or argument injection. But the following commands transform specific String arguments to Net::IMAP::RawData, which bypasses normal argument validation and encoding and prints the string directly to the socket: #uidsearch, #search, #uidsort, #sort, #uidthread, #thread when criteria is a String, it is sent raw #uidfetch, #fetch when attr is a String, it is sent raw when attr is an Array, each String in attr is sent raw #uidstore, #store…
Recommended action: Upgrade to 0.6.4, 0.5.14 or 0.4.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Symbol arguments to commands are vulnerable to a CRLF Injection / IMAP Command injection via Symbol arguments passed to IMAP commands. Details Symbol arguments represent IMAP "system flags", which are formatted as "atoms" (with no quoting) with a "\" prefix. Vulnerable versions of Net::IMAP sends the symbol name directly to the socket, with no validation. Because the Symbol input is unvalidated, it could contain invalid flag characters, including SP and CRLF, which could be used to finish the current command and inject new commands. Although IMAP flag arguments are only valid input for a few IMAP commands, most Net::IMAP commands use generic argument handling, and will allow Symbol (flag) inputs. Note also that the list of valid symbol inputs should be restricted to an enumerated set of standard RFC defined flag types, which have each been given specific defined semantics. Any user-provided values outside of that list of standard "system flags" needs to use the IMAP keyword…
Recommended action: Upgrade to 0.6.4, 0.5.14 or 0.4.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When authenticating a connection with SCRAM-SHA1 or SCRAM-SHA256, a hostile server can perform a computational denial-of-service attack on the client process by sending a big iteration count value. Details A hostile IMAP server can send an arbitrarily large PBKDF2 iteration count in the SCRAM server-first-message, causing the client to perform an expensive OpenSSL::KDF.pbkdf2hmac call. Because the PBKDF2 function is a blocking C extension and holds onto Ruby’s Global VM Lock, it can freeze the entire Ruby VM for the duration of the computation. OpenSSL enforces an effective maximum by using a 32-bit signed integer for the iteration count, Depending on hardware capabilities and OpenSSL version, this iteration count may be sufficient for to block all Ruby threads in the process for over seven minutes. This is listed as one of the "Security Considerations", in RFC 7804: A hostile server can perform a computational denial-of-service attack on clients by sending a big iteration…
Recommended action: Upgrade to 0.6.4, 0.5.14 or 0.4.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Net::IMAP::ResponseReader has quadratic time complexity when reading large responses containing many string literals. A hostile server can send responses which are crafted to exhaust the client's CPU for a denial of service attack. Details For each literal in a response, ResponseReader rescans the entire growing response buffer. The regular expression that is used to scan the response buffer runs in linear time. With many literals, this becomes O(n²) total work. The regular expression should run in constant time: it is anchored to the end and only the last 23 bytes of the buffer are relevant. Because the algorithmic complexity is super-linear, this bypasses protection from maxresponsesize: a response can stay well below the default size limit while still causing very large CPU cost. Net::IMAP::ResponseReader runs continuously in the receiver thread until the connection closes. Impact This consumes disproportionate CPU time in the client's receiver thread. A hostile server…
Recommended action: Upgrade to 0.6.4, 0.5.14 or 0.4.24 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A man-in-the-middle attacker can cause Net::IMAP#starttls to return "successfully", without starting TLS. Details When using Net::IMAP#starttls to upgrade a plaintext connection to use TLS, a man-in-the-middle attacker can inject a tagged OK response with an easily predictable tag. By sending the response before the client finishes sending the command, the command completes "successfully" before the response handler is registered. This allows #starttls to return without error, but the response handler is never invoked, the TLS connection is never established, and the socket remains unencrypted. This allows man-in-the-middle attackers to perform a STARTTLS stripping attack, unless the client code explicitly checks Net::IMAP#tlsverified?. Impact TLS bypass, leading to cleartext transmission of sensitive information. Mitigation Upgrade to a patched version of net-imap that raises an exception whenever #starttls does not establish TLS. Connect to an implicit TLS port, rather than…
Recommended action: Upgrade to 0.6.4, 0.5.14, 0.4.24 or 0.3.10 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is a possibility for denial of service by memory exhaustion when net-imap reads server responses. At any time while the client is connected, a malicious server can send can send a "literal" byte count, which is automatically read by the client's receiver thread. The response reader immediately allocates memory for the number of bytes indicated by the server response. This should not be an issue when securely connecting to trusted IMAP servers that are well-behaved. It can affect insecure connections and buggy, untrusted, or compromised servers (for example, connecting to a user supplied hostname). Details The IMAP protocol allows "literal" strings to be sent in responses, prefixed with their size in curly braces (e.g. {1234567890}\r\n). When Net::IMAP receives a response containing a literal string, it calls IO#read with that size. When called with a size, IO#read immediately allocates memory to buffer the entire string before processing continues. The server does not…
Recommended action: Upgrade to 0.5.7, 0.4.20, 0.3.9 or 0.2.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
There is a possibility for denial of service by memory exhaustion in net-imap's response parser. At any time while the client is connected, a malicious server can send can send highly compressed uid-set data which is automatically read by the client's receiver thread. The response parser uses Range#toa to convert the uid-set data into arrays of integers, with no limitation on the expanded size of the ranges. Details IMAP's uid-set and sequence-set formats can compress ranges of numbers, for example: "1,2,3,4,5" and "1:5" both represent the same set. When Net::IMAP::ResponseParser receives APPENDUID or COPYUID response codes, it expands each uid-set into an array of integers. On a 64 bit system, these arrays will expand to 8 bytes for each number in the set. A malicious IMAP server may send specially crafted APPENDUID or COPYUID responses with very large uid-set ranges. The Net::IMAP client parses each server response in a separate thread, as soon as each responses is received…
Recommended action: Upgrade to 0.5.6, 0.4.19 or 0.3.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.