Ruby/rack/1.6.0.beta2
Rack provides a minimal, modular and adaptable interface for developing web applications in Ruby. By wrapping HTTP requests and responses in the simplest way possible, it unifies and distills the API for web servers, web frameworks, and software in between (the so-called middleware) into a single method call.
https://rubygems.org/gems/rack
MIT
24 Security Vulnerabilities
Rack vulnerable to ReDoS in content type parsing (2nd degree polynomial)
- https://github.com/rack/rack/security/advisories/GHSA-22f2-v57c-j9cx
- https://github.com/rack/rack/commit/6efb2ceea003c4b195815a614e00438cbd543462
- https://github.com/rack/rack/commit/d9c163a443b8cadf4711d84bd2c58cb9ef89cf49
- https://discuss.rubyonrails.org/t/denial-of-service-vulnerability-in-rack-content-type-parsing/84941
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2024-25126.yml
- https://github.com/advisories/GHSA-22f2-v57c-j9cx
- https://nvd.nist.gov/vuln/detail/CVE-2024-25126
- https://lists.debian.org/debian-lts-announce/2024/04/msg00022.html
Summary
module Rack
class MediaType
SPLIT_PATTERN = %r{\s*[;,]\s*}
The above regexp is subject to ReDos. 50K blank characters as a prefix to the header will take over 10s to split.
PoC
A simple HTTP request with lots of blank characters in the content-type header:
request["Content-Type"] = (" " * 50_000) + "a,"
Impact
It's a very easy to craft ReDoS. Like all ReDoS the impact is debatable.
Rack has possible DoS Vulnerability in Multipart MIME parsing
- https://nvd.nist.gov/vuln/detail/CVE-2023-27530
- https://discuss.rubyonrails.org/t/cve-2023-27530-possible-dos-vulnerability-in-multipart-mime-parsing/82388
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2023-27530.yml
- https://github.com/advisories/GHSA-3h57-hmj3-gj3p
- https://lists.debian.org/debian-lts-announce/2023/04/msg00017.html
- https://www.debian.org/security/2023/dsa-5530
- https://security.netapp.com/advisory/ntap-20231208-0015/
There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.
Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3
Impact
The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
A proxy can be configured to limit the POST body size which will mitigate this issue.
Rack Header Parsing leads to Possible Denial of Service Vulnerability
- https://github.com/rack/rack/security/advisories/GHSA-54rr-7fvw-6x8f
- https://github.com/rack/rack/commit/30b8e39a578b25d4bdcc082c1c52c6f164b59716
- https://github.com/rack/rack/commit/6c5d90bdcec0949f7ba06db62fb740dab394b582
- https://github.com/rack/rack/commit/a227cd793778c7c3a827d32808058571569cda6f
- https://github.com/rack/rack/commit/e4c117749ba24a66f8ec5a08eddf68deeb425ccd
- https://discuss.rubyonrails.org/t/possible-denial-of-service-vulnerability-in-rack-header-parsing/84942
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2024-26146.yml
- https://github.com/advisories/GHSA-54rr-7fvw-6x8f
- https://nvd.nist.gov/vuln/detail/CVE-2024-26146
Possible Denial of Service Vulnerability in Rack Header Parsing
There is a possible denial of service vulnerability in the header parsing routines in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26146.
Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1
Impact
Carefully crafted headers can cause header parsing in Rack to take longer than expected resulting in a possible denial of service issue. Accept and Forwarded headers are impacted.
Ruby 3.2 has mitigations for this problem, so Rack 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.
- 2-0-header-redos.patch - Patch for 2.0 series
- 2-1-header-redos.patch - Patch for 2.1 series
- 2-2-header-redos.patch - Patch for 2.2 series
- 3-0-header-redos.patch - Patch for 3.0 series
Credits
Thanks to svalkanov for reporting this and providing patches!
Directory traversal in Rack::Directory app bundled with Rack
- https://nvd.nist.gov/vuln/detail/CVE-2020-8161
- https://github.com/advisories/GHSA-5f9h-9pjv-v6j7
- https://github.com/rack/rack/commit/dddb7ad18ed79ca6ab06ccc417a169fde451246e
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2020-8161.yml
- https://groups.google.com/forum/#!topic/ruby-security-ann/T4ZIsfRf2eA
- https://groups.google.com/g/rubyonrails-security/c/IOO1vNZTzPA
- https://hackerone.com/reports/434404
- https://lists.debian.org/debian-lts-announce/2020/07/msg00006.html
- https://usn.ubuntu.com/4561-1/
- https://lists.debian.org/debian-lts-announce/2023/01/msg00038.html
A directory traversal vulnerability exists in rack < 2.2.0 that allows an attacker perform directory traversal vulnerability in the Rack::Directory app that is bundled with Rack which could result in information disclosure.
Rack vulnerable to Cross-site Scripting
- https://nvd.nist.gov/vuln/detail/CVE-2018-16471
- https://github.com/advisories/GHSA-5r2p-j47h-mhpg
- https://groups.google.com/forum/#!topic/rubyonrails-security/GKsAFT924Ag
- https://lists.debian.org/debian-lts-announce/2018/11/msg00022.html
- https://usn.ubuntu.com/4089-1/
- http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00032.html
- http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00016.html
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2018-16471.yml
- https://groups.google.com/forum/#!topic/ruby-security-ann/NAalCee8n6o
There is a possible XSS vulnerability in Rack before 2.0.6 and 1.6.11. Carefully crafted requests can impact the data returned by the scheme
method on Rack::Request
. Applications that expect the scheme to be limited to 'http' or 'https' and do not escape the return value could be vulnerable to an XSS attack. Note that applications using the normal escaping mechanisms provided by Rails may not impacted, but applications that bypass the escaping mechanisms, or do not use them may be vulnerable.
Denial of service via header parsing in Rack
- https://github.com/rack/rack/releases/tag/v3.0.4.1
- https://github.com/advisories/GHSA-65f5-mfpf-vfhj
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2022-44570.yml
- https://nvd.nist.gov/vuln/detail/CVE-2022-44570
- https://discuss.rubyonrails.org/t/cve-2022-44570-possible-denial-of-service-vulnerability-in-racks-range-header-parsing/82125
- https://www.debian.org/security/2023/dsa-5530
- https://security.netapp.com/advisory/ntap-20231208-0010/
There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.
Versions Affected: >= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.0.1 Impact
Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted. 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.
2-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.0 series
2-1-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.1 series
2-2-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 2.2 series
3-0-Fix-ReDoS-in-Rack-Utils.get_byte_ranges.patch - Patch for 3.0 series
Possible Information Leak / Session Hijack Vulnerability in Rack
- https://github.com/rack/rack/security/advisories/GHSA-hrqr-hxpp-chr3
- https://nvd.nist.gov/vuln/detail/CVE-2019-16782
- https://github.com/advisories/GHSA-hrqr-hxpp-chr3
- https://github.com/rack/rack/commit/7fecaee81f59926b6e1913511c90650e76673b38
- http://www.openwall.com/lists/oss-security/2019/12/18/2
- http://www.openwall.com/lists/oss-security/2019/12/18/3
- http://www.openwall.com/lists/oss-security/2019/12/19/3
- https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/HZXMWILCICQLA2BYSP6I2CRMUG53YBLX/
- http://lists.opensuse.org/opensuse-security-announce/2020-02/msg00016.html
- http://www.openwall.com/lists/oss-security/2020/04/08/1
- http://www.openwall.com/lists/oss-security/2020/04/09/2
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2019-16782.yml
There's a possible information leak / session hijack vulnerability in Rack. Attackers may be able to find and hijack sessions by using timing attacks targeting the session id. Session ids are usually stored and indexed in a database that uses some kind of scheme for speeding up lookups of that session id. By carefully measuring the amount of time it takes to look up a session, an attacker may be able to find a valid session id and hijack the session.
The session id itself may be generated randomly, but the way the session is indexed by the backing store does not use a secure comparison.
Impact
The session id stored in a cookie is the same id that is used when querying the backing session storage engine. Most storage mechanisms (for example a database) use some sort of indexing in order to speed up the lookup of that id. By carefully timing requests and session lookup failures, an attacker may be able to perform a timing attack to determine an existing session id and hijack that session.
Releases
The 1.6.12 and 2.0.8 releases are available at the normal locations.
Workarounds
There are no known workarounds.
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.
- 1-6-session-timing-attack.patch - Patch for 1.6 series
- 2-0-session-timing-attack.patch - Patch for 2.6 series
Credits
Thanks Will Leinweber for reporting this!
Denial of Service Vulnerability in Rack Multipart Parsing
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2022-30122.yml
- https://groups.google.com/g/ruby-security-ann/c/L2Axto442qk
- https://github.com/advisories/GHSA-hxqx-xwvh-44m2
- https://nvd.nist.gov/vuln/detail/CVE-2022-30122
- https://discuss.rubyonrails.org/t/cve-2022-30122-denial-of-service-vulnerability-in-rack-multipart-parsing/80729
- https://www.debian.org/security/2023/dsa-5530
- https://security.gentoo.org/glsa/202310-18
- https://security.netapp.com/advisory/ntap-20231208-0012/
There is a possible denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30122.
Versions Affected: >= 1.2 Not affected: < 1.2 Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1
Impact
Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability.
Impacted code will use Rack's multipart parser to parse multipart posts. This includes directly using the multipart parser like this:
params = Rack::Multipart.parse_multipart(env)
But it also includes reading POST data from a Rack request object like this:
p request.POST # read POST data
p request.params # reads both query params and POST data
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
There are no feasible workarounds for this issue.
Rack allows Percent-encoded cookies to overwrite existing prefixed cookie names
- https://nvd.nist.gov/vuln/detail/CVE-2020-8184
- https://github.com/advisories/GHSA-j6w9-fv6q-3q52
- https://github.com/rack/rack/commit/1f5763de6a9fe515ff84992b343d63c88104654c
- https://hackerone.com/reports/895727
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2020-8184.yml
- https://groups.google.com/g/rubyonrails-security/c/OWtmozPH9Ak
- https://lists.debian.org/debian-lts-announce/2020/07/msg00006.html
- https://usn.ubuntu.com/4561-1/
- https://lists.debian.org/debian-lts-announce/2023/01/msg00038.html
A reliance on cookies without validation/integrity check security vulnerability exists in rack < 2.2.3, rack < 2.1.4 that makes it possible for an attacker to forge a secure or host-only cookie prefix.
Possible shell escape sequence injection vulnerability in Rack
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2022-30123.yml
- https://groups.google.com/g/ruby-security-ann/c/LWB10kWzag8
- https://github.com/advisories/GHSA-wq4h-7r42-5hrr
- https://github.com/rack/rack/commit/b426cc224908ec6ed6eb8729325392b048215d88
- https://nvd.nist.gov/vuln/detail/CVE-2022-30123
- https://discuss.rubyonrails.org/t/cve-2022-30123-possible-shell-escape-sequence-injection-vulnerability-in-rack/80728
- https://www.debian.org/security/2023/dsa-5530
- https://security.gentoo.org/glsa/202310-18
- https://security.netapp.com/advisory/ntap-20231208-0011/
There is a possible shell escape sequence injection vulnerability in the Lint and CommonLogger components of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30123.
Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1
Impact
Carefully crafted requests can cause shell escape sequences to be written to the terminal via Rack's Lint middleware and CommonLogger middleware. These escape sequences can be leveraged to possibly execute commands in the victim's terminal.
Impacted applications will have either of these middleware installed, and vulnerable apps may have something like this:
use Rack::Lint
Or
use Rack::CommonLogger
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
Remove these middleware from your application
Rack has possible DoS Vulnerability with Range Header
- https://github.com/rack/rack/security/advisories/GHSA-xj5v-6v4g-jfw6
- https://github.com/rack/rack/commit/4849132bef471adb21131980df745f4bb84de2d9
- https://github.com/rack/rack/commit/62457686b26d33a15a254c7768c2076e8e02b48b
- https://discuss.rubyonrails.org/t/possible-dos-vulnerability-with-range-header-in-rack/84944
- https://github.com/rubysec/ruby-advisory-db/blob/master/gems/rack/CVE-2024-26141.yml
- https://github.com/advisories/GHSA-xj5v-6v4g-jfw6
- https://nvd.nist.gov/vuln/detail/CVE-2024-26141
Possible DoS Vulnerability with Range Header in Rack
There is a possible DoS vulnerability relating to the Range request header in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141.
Versions Affected: >= 1.3.0. Not affected: < 1.3.0 Fixed Versions: 3.0.9.1, 2.2.8.1
Impact
Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue.
Vulnerable applications will use the Rack::File
middleware or the
Rack::Utils.byte_ranges
methods (this includes Rails applications).
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.
- 3-0-range.patch - Patch for 3.0 series
- 2-2-range.patch - Patch for 2.2 series
Credits
Thank you ooooooo_q for the report and patch
Potential Denial of Service Vulnerability in Rack
Carefully crafted requests can cause a SystemStackError
and potentially
cause a denial of service attack.
All users running an affected release should upgrade.
Directory traversal in Rack::Directory app bundled with Rack
There was a possible directory traversal vulnerability in the Rack::Directory app that is bundled with Rack.
Versions Affected: rack < 2.2.0 Not affected: Applications that do not use Rack::Directory. Fixed Versions: 2.1.3, >= 2.2.0
Impact
If certain directories exist in a director that is managed by
Rack::Directory
, an attacker could, using this vulnerability, read the
contents of files on the server that were outside of the root specified in the
Rack::Directory initializer.
Workarounds
Until such time as the patch is applied or their Rack version is upgraded, we recommend that developers do not use Rack::Directory in their applications.
Percent-encoded cookies can be used to overwrite existing prefixed cookie names
It is possible to forge a secure or host-only cookie prefix in Rack using an arbitrary cookie write by using URL encoding (percent-encoding) on the name of the cookie. This could result in an application that is dependent on this prefix to determine if a cookie is safe to process being manipulated into processing an insecure or cross-origin request. This vulnerability has been assigned the CVE identifier CVE-2020-8184.
Versions Affected: rack < 2.2.3, rack < 2.1.4 Not affected: Applications which do not rely on _Host- and _Secure- prefixes to determine if a cookie is safe to process Fixed Versions: rack >= 2.2.3, rack >= 2.1.4
Impact
An attacker may be able to trick a vulnerable application into processing an insecure (non-SSL) or cross-origin request if they can gain the ability to write arbitrary cookies that are sent to the application.
Workarounds
If your application is impacted but you cannot upgrade to the released versions or apply the provided patch, this issue can be temporarily addressed by adding the following workaround:
module Rack
module Utils
module_function def parse_cookies_header(header)
return {} unless header
header.split(/[;] */n).each_with_object({}) do |cookie, cookies|
next if cookie.empty?
key, value = cookie.split('=', 2)
cookies[key] = (unescape(value) rescue value) unless cookies.key?(key)
end
end
end
end
Denial of Service Vulnerability in Rack Multipart Parsing
There is a possible denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30122.
Versions Affected: >= 1.2 Not affected: < 1.2 Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1
Impact
Carefully crafted multipart POST requests can cause Rack's multipart parser to take much longer than expected, leading to a possible denial of service vulnerability.
Impacted code will use Rack's multipart parser to parse multipart posts. This includes directly using the multipart parser like this:
params = Rack::Multipart.parse_multipart(env)
But it also includes reading POST data from a Rack request object like this:
p request.POST # read POST data
p request.params # reads both query params and POST data
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
There are no feasible workarounds for this issue.
Possible shell escape sequence injection vulnerability in Rack
There is a possible shell escape sequence injection vulnerability in the Lint and CommonLogger components of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-30123.
Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.1, 2.1.4.1, 2.2.3.1
Impact
Carefully crafted requests can cause shell escape sequences to be written to the terminal via Rack's Lint middleware and CommonLogger middleware. These escape sequences can be leveraged to possibly execute commands in the victim's terminal.
Impacted applications will have either of these middleware installed, and vulnerable apps may have something like this:
use Rack::Lint
Or
use Rack::CommonLogger
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
Remove these middleware from your application
Denial of service via header parsing in Rack
There is a possible denial of service vulnerability in the Range header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44570.
Versions Affected: >= 1.5.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.2, 3.0.4.1
Impact
Carefully crafted input can cause the Range header parsing component in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that deal with Range requests (such as streaming applications, or applications that serve files) may be impacted.
Workarounds
There are no feasible workarounds for this issue.
Denial of Service Vulnerability in Rack Content-Disposition parsing
There is a denial of service vulnerability in the Content-Disposition parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44571.
Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1
Impact
Carefully crafted input can cause Content-Disposition header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is used typically used in multipart parsing. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.
Workarounds
There are no feasible workarounds for this issue.
Denial of service via multipart parsing in Rack
There is a denial of service vulnerability in the multipart parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2022-44572.
Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.0.9.2, 2.1.4.2, 2.2.6.1, 3.0.4.1
Impact
Carefully crafted input can cause RFC2183 multipart boundary parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse multipart posts using Rack (virtually all Rails applications) are impacted.
Workarounds
There are no feasible workarounds for this issue.
Possible DoS Vulnerability in Multipart MIME parsing
There is a possible DoS vulnerability in the Multipart MIME parsing code in Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27530.
Versions Affected: All. Not affected: None Fixed Versions: 3.0.4.2, 2.2.6.3, 2.1.4.3, 2.0.9.3
Impact
The Multipart MIME parsing code in Rack limits the number of file parts, but does not limit the total number of parts that can be uploaded. Carefully crafted requests can abuse this and cause multipart parsing to take longer than expected.
All users running an affected release should either upgrade or use one of the workarounds immediately.
Workarounds
A proxy can be configured to limit the POST body size which will mitigate this issue.
Possible Denial of Service Vulnerability in Rack’s header parsing
There is a denial of service vulnerability in the header parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2023-27539.
Versions Affected: >= 2.0.0 Not affected: None. Fixed Versions: 2.2.6.4, 3.0.6.1
Impact
Carefully crafted input can cause header parsing in Rack to take an unexpected amount of time, possibly resulting in a denial of service attack vector. Any applications that parse headers using Rack (virtually all Rails applications) are impacted.
Workarounds
Setting Regexp.timeout in Ruby 3.2 is a possible workaround.
Denial of Service Vulnerability in Rack Content-Type Parsing
There is a possible denial of service vulnerability in the content type parsing component of Rack. This vulnerability has been assigned the CVE identifier CVE-2024-25126.
Versions Affected: >= 0.4 Not affected: < 0.4 Fixed Versions: 3.0.9.1, 2.2.8.1
Impact
Carefully crafted content type headers can cause Rack’s media type parser to take much longer than expected, leading to a possible denial of service vulnerability.
Impacted code will use Rack’s media type parser to parse content type headers. This code will look like below:
request.media_type
## OR
request.media_type_params
## OR
Rack::MediaType.type(content_type)
Some frameworks (including Rails) call this code internally, so upgrading is recommended!
All users running an affected release should either upgrade or use one of the workarounds immediately.
Releases
The fixed releases are available at the normal locations.
Workarounds
There are no feasible workarounds for this issue.
Possible DoS Vulnerability with Range Header in Rack
There is a possible DoS vulnerability relating to the Range request header in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26141.
Versions Affected: >= 1.3.0. Not affected: < 1.3.0 Fixed Versions: 3.0.9.1, 2.2.8.1
Impact
Carefully crafted Range headers can cause a server to respond with an unexpectedly large response. Responding with such large responses could lead to a denial of service issue.
Vulnerable applications will use the Rack::File
middleware or the
Rack::Utils.byte_ranges
methods (this includes Rails applications).
Releases
The fixed releases are available at the normal locations.
Workarounds
There are no feasible workarounds for this issue.
Possible Denial of Service Vulnerability in Rack Header Parsing
There is a possible denial of service vulnerability in the header parsing routines in Rack. This vulnerability has been assigned the CVE identifier CVE-2024-26146.
Versions Affected: All. Not affected: None Fixed Versions: 2.0.9.4, 2.1.4.4, 2.2.8.1, 3.0.9.1
Impact
Carefully crafted headers can cause header parsing in Rack to take longer than
expected resulting in a possible denial of service issue. Accept
and
Forwarded
headers are impacted.
Ruby 3.2 has mitigations for this problem, so Rack 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.
128 Other Versions
Version | License | Security | Released | |
---|---|---|---|---|
2.2.3 | MIT | 20 | 2020-06-15 - 22:25 | almost 4 years |
2.2.2 | MIT | 22 | 2020-02-10 - 22:25 | over 4 years |
2.2.1 | MIT | 22 | 2020-02-09 - 06:20 | over 4 years |
2.2.0 | MIT | 22 | 2020-02-08 - 18:26 | over 4 years |
2.1.4 | MIT | 20 | 2020-06-15 - 22:24 | almost 4 years |
2.1.3 | MIT | 21 | 2020-05-12 - 21:44 | about 4 years |
2.1.2 | MIT | 22 | 2020-01-27 - 22:42 | over 4 years |
2.1.1 | MIT | 22 | 2020-01-11 - 22:18 | over 4 years |
2.1.0 | MIT | 22 | 2020-01-10 - 17:49 | over 4 years |
2.0.9 | MIT | 24 | 2020-02-08 - 18:21 | over 4 years |
2.0.8 | MIT | 24 | 2019-12-18 - 18:08 | over 4 years |
2.0.7 | MIT | 26 | 2019-04-02 - 16:54 | about 5 years |
2.0.6 | MIT | 26 | 2018-11-05 - 20:00 | over 5 years |
2.0.5 | MIT | 30 | 2018-04-23 - 17:47 | about 6 years |
2.0.4 | MIT | 30 | 2018-01-31 - 18:17 | over 6 years |
2.0.3 | MIT | 28 | 2017-05-15 - 16:50 | almost 7 years |
2.0.2 | MIT | 28 | 2017-05-08 - 17:08 | about 7 years |
2.0.1 | MIT | 28 | 2016-06-30 - 17:34 | almost 8 years |
2.0.0.rc1 | MIT | 23 | 2016-05-06 - 20:52 | about 8 years |
2.0.0.alpha | MIT | 23 | 2015-12-17 - 21:34 | over 8 years |
1.6.13 | MIT | 21 | 2020-02-08 - 18:19 | over 4 years |
1.6.12 | MIT | 21 | 2019-12-18 - 18:08 | over 4 years |
1.6.11 | MIT | 22 | 2018-11-05 - 20:00 | over 5 years |
1.6.10 | MIT | 23 | 2018-04-23 - 17:52 | about 6 years |
1.6.9 | MIT | 23 | 2018-02-27 - 17:19 | about 6 years |
1.6.8 | MIT | 23 | 2017-05-16 - 21:29 | almost 7 years |
1.6.7 | MIT | 23 | 2017-05-15 - 16:47 | almost 7 years |
1.6.6 | MIT | 23 | 2017-05-08 - 17:07 | about 7 years |
1.6.5 | MIT | 23 | 2016-11-10 - 21:55 | over 7 years |
1.6.4 | MIT | 23 | 2015-06-18 - 21:51 | almost 9 years |
1.6.3 | MIT | 23 | 2015-06-18 - 18:45 | almost 9 years |
1.6.2 | MIT | 23 | 2015-06-16 - 17:59 | almost 9 years |
1.6.1 | MIT | 26 | 2015-05-06 - 18:37 | about 9 years |
1.6.0 | MIT | 26 | 2014-12-18 - 22:45 | over 9 years |
1.6.0.beta2 | MIT | 24 | 2014-11-27 - 18:52 | over 9 years |
1.6.0.beta | MIT | 24 | 2014-08-18 - 19:02 | over 9 years |
1.5.5 | MIT | 25 | 2015-06-18 - 18:46 | almost 9 years |
1.5.4 | MIT | 25 | 2015-06-16 - 17:58 | almost 9 years |
1.5.3 | MIT | 27 | 2015-05-06 - 18:43 | about 9 years |
1.5.2 | MIT | 27 | 2013-02-08 - 03:14 | over 11 years |
3.0.4.2 | MIT | 8 | 2023-03-02 - 22:57 | about 1 year |
2.1.4.4 | MIT | 6 | 2024-02-21 - 19:21 | 3 months |
2.2.9 | MIT | 2024-03-21 - 01:19 | about 2 months | |
3.0.11 | MIT | 2024-05-09 - 22:34 | 3 days | |
2.0.9.4 | MIT | 10 | 2024-02-21 - 19:20 | 3 months |
3.0.10 | MIT | 2024-03-20 - 21:57 | about 2 months | |
2.2.7 | MIT | 6 | 2023-04-24 - 23:22 | about 1 year |
2.2.8.1 | MIT | 2024-02-21 - 19:23 | 3 months | |
3.0.9 | MIT | 6 | 2024-01-31 - 07:52 | 3 months |
3.0.9.1 | MIT | 2024-02-21 - 19:23 | 3 months | |
3.0.8 | MIT | 6 | 2023-06-14 - 02:01 | 11 months |
2.2.8 | MIT | 6 | 2023-07-31 - 02:43 | 10 months |
3.0.6 | MIT | 8 | 2023-03-13 - 06:00 | about 1 year |
3.0.7 | MIT | 6 | 2023-03-16 - 02:22 | about 1 year |
3.0.6.1 | MIT | 6 | 2023-03-13 - 18:10 | about 1 year |
2.2.6.4 | MIT | 6 | 2023-03-13 - 18:10 | about 1 year |
2.0.9.3 | MIT | 12 | 2023-03-02 - 22:57 | about 1 year |
3.0.5 | MIT | 8 | 2023-03-12 - 06:28 | about 1 year |
2.2.6.3 | MIT | 8 | 2023-03-02 - 22:57 | about 1 year |
2.1.4.3 | MIT | 8 | 2023-03-02 - 22:57 | about 1 year |
3.0.0.rc1 | MIT | 8 | 2022-09-04 - 23:52 | over 1 year |
2.2.4 | MIT | 16 | 2022-06-30 - 22:22 | almost 2 years |
2.2.3.1 | MIT | 16 | 2022-05-27 - 15:31 | almost 2 years |
2.0.9.1 | MIT | 20 | 2022-05-27 - 15:31 | almost 2 years |
2.2.6 | MIT | 16 | 2023-01-16 - 21:05 | over 1 year |
3.0.0.beta1 | MIT | 8 | 2022-08-08 - 20:34 | almost 2 years |
3.0.1 | MIT | 16 | 2022-11-18 - 20:59 | over 1 year |
2.1.4.1 | MIT | 16 | 2022-05-27 - 15:31 | almost 2 years |
2.0.9.2 | MIT | 14 | 2023-01-17 - 20:48 | over 1 year |
2.1.4.2 | MIT | 10 | 2023-01-17 - 20:48 | over 1 year |
2.2.5 | MIT | 16 | 2022-12-26 - 20:19 | over 1 year |
2.2.6.1 | MIT | 12 | 2023-01-17 - 20:48 | over 1 year |
3.0.4.1 | MIT | 10 | 2023-01-17 - 20:48 | over 1 year |
2.2.6.2 | MIT | 10 | 2023-01-17 - 21:22 | over 1 year |
3.0.4 | MIT | 16 | 2023-01-16 - 22:41 | over 1 year |
3.0.2 | MIT | 16 | 2022-12-05 - 05:13 | over 1 year |
3.0.0 | MIT | 16 | 2022-09-06 - 16:28 | over 1 year |
3.0.3 | MIT | 16 | 2022-12-26 - 20:20 | over 1 year |
1.3.0 | UNKNOWN | 32 | 2011-05-23 - 06:08 | almost 13 years |
1.3.1 | UNKNOWN | 32 | 2011-07-13 - 23:20 | almost 13 years |
1.3.0.beta2 | UNKNOWN | 25 | 2011-05-19 - 17:16 | almost 13 years |
1.3.3 | UNKNOWN | 32 | 2011-09-16 - 23:32 | over 12 years |
1.3.5 | UNKNOWN | 32 | 2011-10-18 - 05:33 | over 12 years |
1.3.6 | UNKNOWN | 31 | 2011-12-28 - 02:52 | over 12 years |
1.3.4 | UNKNOWN | 32 | 2011-10-01 - 20:50 | over 12 years |
0.9.0 | UNKNOWN | 30 | 2009-07-25 - 18:02 | almost 15 years |
1.0.0 | UNKNOWN | 30 | 2009-07-25 - 18:02 | almost 15 years |
0.3.0 | UNKNOWN | 28 | 2009-07-25 - 18:02 | almost 15 years |
0.2.0 | UNKNOWN | 28 | 2009-07-25 - 18:02 | almost 15 years |
0.1.0 | UNKNOWN | 28 | 2009-07-25 - 18:02 | almost 15 years |
1.0.1 | UNKNOWN | 30 | 2009-10-18 - 22:45 | over 14 years |
0.9.1 | UNKNOWN | 30 | 2009-07-25 - 18:02 | almost 15 years |
0.4.0 | UNKNOWN | 30 | 2009-07-25 - 18:02 | almost 15 years |
1.1.1 | UNKNOWN | 28 | 2011-03-01 - 06:04 | about 13 years |
1.1.3 | UNKNOWN | 27 | 2011-12-28 - 02:37 | over 12 years |
1.1.4 | UNKNOWN | 26 | 2013-01-07 - 02:21 | over 11 years |
1.1.2 | UNKNOWN | 28 | 2011-03-13 - 14:02 | about 13 years |
1.1.1.pre | UNKNOWN | 28 | 2011-02-10 - 03:12 | over 13 years |
1.2.0 | UNKNOWN | 30 | 2010-06-13 - 17:53 | almost 14 years |
1.2.1 | UNKNOWN | 30 | 2010-06-15 - 09:57 | almost 14 years |