Details

A buffer overflow vulnerability exists in Zlib::GzipReader.

The zstreambufferungets function prepends caller-provided bytes ahead of previously produced output but fails to guarantee the backing Ruby string has enough capacity before the memmove shifts the existing data. This can lead to memory corruption when the buffer length exceeds capacity.

Recommended action

We recommend to update the zlib gem to version 3.2.3 or later. In order to ensure compatibility with bundled version in older Ruby series, you may update as follows instead:

For Ruby 3.2 users: Update to zlib 3.0.1 For Ruby 3.3 users: Update to zlib 3.1.2

You can use gem update zlib to update it. If you are using bundler, please add gem "zlib", ">= 3.2.3" to your Gemfile.

Affected versions

zlib gem 3.2.2 or lower

Credits

calysteon

References

https://hackerone.com/reports/3467067

Summary 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 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 when attr is a String, it is sent raw #setquota: limit is interpolated with #tos and that string is sent raw

Because these string arguments are sent without any neutralization, they serve as a direct vector for command splitting. Any user controlled data interpolated into these strings can be used to break out of the intended command context.

Using "raw data" arguments for #uidstore, #store, and #setquota I both inappropriate and unnecessary. Net::IMAP's generic argument handling is sufficient to safely validate and encode their arguments. Users of the library probably do not expect arguments to these commands to be sent raw and might not be wary of passing unvalidated input.

The API for search criteria and fetch attributes is intentionally low-level and "close to the wire". It allows developers to use some IMAP extensions without requiring explicit support from the library and allows developers to use complex IMAP grammar without complex argument translation. Even so, basic validation is appropriate and could neutralize command injection.

Although this was explicitly documented for search criteria, it was insufficiently documented for fetch attr. So developers may not have realized that the attr argument to #fetch and #uidfetch is sent as "raw data".

Impact

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.

The SEARCH, STORE, and FETCH commands, and their UID variants are some of the most commonly used features of the library. Applications that build search queries or fetch attributes dynamically based on user input (e.g., mail clients or archival tools) may be at significant risk.

Expected use of Net::IMAP#setquota is much more limited: SETQUOTA is often only usable by users with special administrative privileges. Depending on the server, quota administration might be managed through server configuration rather than via the IMAP protocol SETQUOTA command. It is expected to be uncommonly used in system administration scripts or in interactive sessions, it should be completely controlled by trusted users, and should only use trusted inputs. Calling #setquota with untrusted user input is expected to be a very uncommon use case. Please note however this might be combined with other attacks, for example CSRF, which provide unauthorized access to trusted inputs, and may specifically target users or scripts with administrator privileges.

Mitigation - Update to a patched version of net-imap which: - validates that Net::IMAP::RawData is composed of well-formed IMAP text, literal, and literal8 values, with no unescaped NULL, CR, or LF bytes. - does not use Net::IMAP::RawData for #store, #uidstore, or #setquota. - Prefer to send search criteria as an array of key value pairs. Avoid sending it as an interpolated string. - If an immediate upgrade is not possible: - String inputs to search criteria and fetch attributes can be validated against command injection by checking for \r and \n characters. - Hard-coding the store attr argument is often appropriate. Alternatively, user controlled inputs can be restricted to a small enumerated list which is valid for the calling application. - Use Kernel#Integer to coerce and validate user controlled inputs to #setquota limit.

Summary

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 count value. In order to defend against that, a client implementation can pick a maximum iteration count that it is willing to use and reject any values that exceed that threshold (in such cases, the client, of course, has to fail the authentication).

Impact

During SCRAM authentication to a hostile server, the entire Ruby VM will be locked for the duration of the computation. Depending on hardware capabilities and OpenSSL version, this may take many minutes.

OpenSSL::KDF.pbkdf2hmac is a blocking C function, so Timeout cannot be used to guard against this. And it retains the Global VM lock, so other ruby threads will also be unable to run.

Mitigation

Upgrade to a patched version of net-imap that adds the maxiterations option to the SASL- authenticators, and call Net::IMAP#authenticate with a maxiterations keyword argument.

NOTE: The default maxiterations is 2³¹ - 1, the maximum signed 32 bit integer, the maximum allowed by OpenSSL. To prevent a denial of service attack, this must be set to a safe value, depending on hardware and version of OpenSSL. It is the user's responsibility to enforce minimum and maximum iteration counts that are appropriate for their security context. Alternatively, avoid SCRAM- mechanisms when authenticating to untrusted servers.

Summary

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 use STARTTLS with a cleartext port. This is strongly recommended anyway: RFC 8314: Cleartext Considered Obsolete: Use of Transport Layer Security (TLS) for Email Submission and Access NO STARTTLS: Why TLS is better without STARTTLS, A Security Analysis of STARTTLS in the Email Context Explicitly verify Net::IMAP#tlsverified? is true, before using the connection after #starttls.

Summary

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 syntax, which are sent as atoms, i.e: string inputs. Under no circumstances should #tosym ever be called on unvetted user-provided input: that will always be a bug in the calling code for the simple reason that userinputatom is as \userinputatom.

For forward compatibility with future IMAP extentions, Net::IMAP, does not restrict flag inputs to an enumerated list. That is the responsibility of the calling application code, which knows which flag semantics are valid for its context.

Impact

If a developer passes user-controlled input as a Symbol to most Net::IMAP commands, an attacker can append CRLF sequence followed by a new IMAP command (like DELETE mailbox).

Mitigation Upgrade to a version of Net::IMAP that validates Symbols are valid as an IMAP flag. User-provided input should never be able to control calling #tosym on string arguments.

For example, do not unsafely serialize and deserialize command arguments (e.g. with YAML or Marshal) in a way that could create unvetted Symbol arguments. For the few IMAP commands which do allow flag arguments, it may be appropriate to hard-code Symbol arguments or restrict them to an enumerated list which is valid for the calling application.

An operating system command injection flaw was found in RDoc. Using the rdoc command to generate documentation for a malicious Ruby source code could lead to execution of arbitrary commands with the privileges of the user running rdoc.

An issue was discovered in Ruby through 2.5.8, 2.6.x through 2.6.6, and 2.7.x through 2.7.1. WEBrick, a simple HTTP server bundled with Ruby, had not checked the transfer-encoding header value rigorously. An attacker may potentially exploit this issue to bypass a reverse proxy (which also has a poor header check), which may lead to an HTTP Request Smuggling attack.

A flaw was found in rubygem-json. While parsing certain JSON documents, the json gem (including the one bundled with Ruby) can be coerced into creating arbitrary objects in the target system. This is the same issue as CVE-2013-0269.

Summary

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 could use this to exhaust the client's CPU for a denial of service attack.

For a response near the default maxresponsesize, each individual regexp scan could take between 100 to 200ms on common modern hardware, and this may be repeated 200k times per megabyte of response. While the regexp is scanning, it retains the Global VM lock, preventing other threads from running.

Although other threads should not be completely blocked, their run time will be significantly impacted.

Mitigation

Upgrade to a patched version of net-imap that reads responses more efficiently. Do not connect to untrusted IMAP servers. When connecting to untrusted servers, a much smaller maxresponsesize (for example: 8KiB) will limit the impact. Although this is too small for fetching unpaginated message bodies, it should be enough for most other operations.

An issue was discovered in Ruby 4 before 4.0.5. A race condition leading to a use-after-free in the pthread-based getaddrinfo timeout handler (rbgetaddrinfo in ext/socket/raddrinfo.c) allows a remote attacker who can delay DNS responses near the user-specified timeout to crash a Ruby process that calls Addrinfo.getaddrinfo(..., timeout:) or Socket.tcp(..., resolvtimeout:). Memory-corruption-based exploitation is theoretically possible. The attack could, for example, be carried out through a crafted authoritative DNS server or recursive resolver.

Impact

A format string injection vulnerability than that lead to denial of service attacks or information disclosure, when the allowduplicatekey: false parsing option is used to parse user supplied documents.

This option isn't the default, if you didn't opt-in to use it, you are not impacted.

Patches

Patched in 2.19.2.

Workarounds

The issue can be avoided by not using the allowduplicatekey: false parsing option.

Impact

The REXML gem before 3.3.6 has a DoS vulnerability when it parses an XML that has many deep elements that have same local name attributes.

If you need to parse untrusted XMLs with tree parser API like REXML::Document.new, you may be impacted to this vulnerability. If you use other parser APIs such as stream parser API and SAX2 parser API, this vulnerability is not affected.

Patches

The REXML gem 3.3.6 or later include the patch to fix the vulnerability.

Workarounds

Don't parse untrusted XMLs with tree parser API.

References

https://www.ruby-lang.org/en/news/2024/08/22/dos-rexml-cve-2024-43398/ : An announce on www.ruby-lang.org

Impact

The REXML gem before 3.3.9 has a ReDoS vulnerability when it parses an XML that has many digits between &# and x...; in a hex numeric character reference (&#x...;).

This does not happen with Ruby 3.2 or later. Ruby 3.1 is the only affected maintained Ruby. Note that Ruby 3.1 will reach EOL on 2025-03.

Patches

The REXML gem 3.3.9 or later include the patch to fix the vulnerability.

Workarounds

Use Ruby 3.2 or later instead of Ruby 3.1.

References

https://www.ruby-lang.org/en/news/2024/10/28/redos-rexml-cve-2024-49761/: An announce on www.ruby-lang.org

Admin Framework. A logic issue was addressed with improved checks.

In the CGI gem before 0.4.2 for Ruby, the CGI::Cookie.parse method in the CGI library contains a potential Denial of Service (DoS) vulnerability. The method does not impose any limit on the length of the raw cookie value it processes. This oversight can lead to excessive resource consumption when parsing extremely large cookies.

In the CGI gem before 0.4.2 for Ruby, a Regular Expression Denial of Service (ReDoS) vulnerability exists in the Util#escapeElement method.

Impact

A specially crafted document could cause an out of bound read, most likely resulting in a crash.

Versions 2.10.0 and 2.10.1 are impacted. Older versions are not.

Patches

Version 2.10.2 fixes the problem.

Workarounds

None.

In the URI gem before 1.0.3 for Ruby, the URI handling methods (URI.join, URI#merge, URI#+) have an inadvertent leakage of authentication credentials because userinfo is retained even after changing the host.

Possible ReDoS vulnerability in Accept header parsing in Action Dispatch

There is a possible ReDoS vulnerability in the Accept header parsing routines of Action Dispatch. This vulnerability has been assigned the CVE identifier CVE-2024-26142.

Versions Affected: >= 7.1.0, < 7.1.3.1 Not affected: < 7.1.0 Fixed Versions: 7.1.3.1

Impact ------ Carefully crafted Accept headers can cause Accept header parsing in Action Dispatch to take an unexpected amount of time, possibly resulting in a DoS vulnerability. All users running an affected release should either upgrade or use one of the workarounds immediately.

Ruby 3.2 has mitigations for this problem, so Rails applications using Ruby 3.2 or newer are unaffected.

Releases -------- The fixed releases are available at the normal locations.

Workarounds ----------- There are no feasible workarounds for this issue.

Patches ------- To aid users who aren't able to upgrade immediately we have provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

7-1-accept-redox.patch - Patch for 7.1 series

Credits ------- Thanks svalkanov for the report and patch!

A ReDoS issue was discovered in the URI component before 0.12.2 for Ruby. The URI parser mishandles invalid URLs that have specific characters. There is an increase in execution time for parsing strings to URI objects with rfc2396parser.rb and rfc3986parser.rb.

NOTE: this issue exists becuse of an incomplete fix for CVE-2023-28755. Version 0.10.3 is also a fixed version.

The Ruby advisory recommends updating the uri gem to 0.12.2. In order to ensure compatibility with the bundled version in older Ruby series, you may update as follows instead: - For Ruby 3.0: Update to uri 0.10.3 - For Ruby 3.1 and 3.2: Update to uri 0.12.2.

You can use gem update uri to update it. If you are using bundler, please add gem uri, >= 0.12.2 (or other version mentioned above) to your Gemfile.

Last updated 25 August 2025

In Puma (RubyGem) before 4.3.2 and 3.12.3, if an application using Puma allows untrusted input in a response header, an attacker can use newline characters (i.e. CR, LF or/r, /n) to end the header and inject malicious content, such as additional headers or an entirely new response body. This vulnerability is known as HTTP Response Splitting.

While not an attack in itself, response splitting is a vector for several other attacks, such as cross-site scripting (XSS).

This is related to CVE-2019-16254, which fixed this vulnerability for the WEBrick Ruby web server.

This has been fixed in versions 4.3.2 and 3.12.3 by checking all headers for line endings and rejecting headers with those characters.

Dir.open, Dir.new, Dir.entries and Dir.empty? accept the path of the target directory as their parameter. If the parameter contains NUL (\0) bytes, these methods recognize that the path is completed before the NUL bytes. So, if a script accepts an external input as the argument of these methods, the attacker can make the unintentional directory traversal.

Affected versions:

Ruby 2.2 series: 2.2.9 and earlier Ruby 2.3 series: 2.3.6 and earlier Ruby 2.4 series: 2.4.3 and earlier Ruby 2.5 series: 2.5.0 and earlier

External References:

https://www.ruby-lang.org/en/news/2018/03/28/poisoned-nul-byte-dir-cve-2018-8780/

In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, the UNIXServer.open and UNIXSocket.open methods are not checked for null characters. It may be connected to an unintended socket.

If an attacker sends a large request which contains huge HTTP headers, WEBrick try to process it on memory, so the request causes the out-of-memory DoS attack.

Affected versions:

Ruby 2.2 series: 2.2.9 and earlier Ruby 2.3 series: 2.3.6 and earlier Ruby 2.4 series: 2.4.3 and earlier Ruby 2.5 series: 2.5.0 and earlier

External References:

https://www.ruby-lang.org/en/news/2018/03/28/large-request-dos-in-webrick-cve-2018-8777/

In Ruby before 2.2.10, 2.3.x before 2.3.7, 2.4.x before 2.4.4, 2.5.x before 2.5.1, and 2.6.0-preview1, an attacker controlling the unpacking format (similar to format string vulnerabilities) can trigger a buffer under-read in the String#unpack method, resulting in a massive and controlled information disclosure.

Dir.mktmpdir method introduced by tmpdir library accepts the prefix and the suffix of the directory which is created as the first parameter. The prefix can contain relative directory specifiers "../", so this method can be used to target any directory. So, if a script accepts an external input as the prefix, and the targeted directory has inappropriate permissions or the ruby process has inappropriate privileges, the attacker can create a directory or a file at any directory.

Affected versions:

Ruby 2.2 series: 2.2.9 and earlier Ruby 2.3 series: 2.3.6 and earlier Ruby 2.4 series: 2.4.3 and earlier Ruby 2.5 series: 2.5.0 and earlier

External References:

https://www.ruby-lang.org/en/news/2018/03/28/unintentional-file-and-directory-creation-with-directory-traversal-cve-2018-6914/

The parsecharclass function in regparse.c in the Onigmo (aka Oniguruma-mod) regular expression library, as used in Ruby 2.4.0, allows remote attackers to cause a denial of service (deep recursion and application crash) via a crafted regular expression.

DISPUTED The openssl extension in Ruby 2.x does not properly maintain the state of process memory after a file is reopened, which allows remote attackers to spoof signatures within the context of a Ruby script that attempts signature verification after performing a certain sequence of filesystem operations. NOTE: this issue has been disputed by the Ruby OpenSSL team and third parties, who state that the original demonstration PoC contains errors and redundant or unnecessarily-complex code that does not appear to be related to a demonstration of the issue. As of 20140502, CVE is not aware of any public comment by the original researcher.

ext/openssl/osslocsp.c in Ruby 1.8 and 1.9 does not properly check the return value from the OCSPbasicverify function, which might allow remote attackers to successfully present an invalid X.509 certificate, possibly involving a revoked certificate.