deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-v6x5-cg8r-vv6x
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-407: Inefficient Algorithmic Complexity, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters

Details:
## Summary

`Rack::Multipart::Parser#handle_mime_head` parses quoted multipart parameters such as `Content-Disposition: form-data; name="..."` using repeated `String#index` searches combined with `String#slice!` prefix deletion. For escape-heavy quoted values, this causes super-linear processing.

An unauthenticated attacker can send a crafted `multipart/form-data` request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing.

This results in a denial of service condition in Rack applications that accept multipart form data.

## Details

`Rack::Multipart::Parser#handle_mime_head` parses quoted parameter values by repeatedly:

1. Searching for the next quote or backslash,
2. Copying the preceding substring into a new buffer, and
3. Removing the processed prefix from the original string with `slice!`.

An attacker can exploit this by sending a multipart request with many parts whose `name` parameters contain long escape-heavy values such as:

```text
name="a\\a\\a\\a\\a\\..."
```

Under default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.

## Impact

Any Rack application that accepts `multipart/form-data` requests may be affected, including file upload endpoints and standard HTML form handlers.

An unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.

## Mitigation

* Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.
* Apply request throttling or rate limiting to multipart upload endpoints.
* Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume endpoints.
GitHub Security Advisory: GHSA-v6x5-cg8r-vv6x
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-407: Inefficient Algorithmic Complexity, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack's multipart header parsing allows Denial of Service via escape-heavy quoted parameters

Details:
## Summary

`Rack::Multipart::Parser#handle_mime_head` parses quoted multipart parameters such as `Content-Disposition: form-data; name="..."` using repeated `String#index` searches combined with `String#slice!` prefix deletion. For escape-heavy quoted values, this causes super-linear processing.

An unauthenticated attacker can send a crafted `multipart/form-data` request containing many parts with long backslash-escaped parameter values to trigger excessive CPU usage during multipart parsing.

This results in a denial of service condition in Rack applications that accept multipart form data.

## Details

`Rack::Multipart::Parser#handle_mime_head` parses quoted parameter values by repeatedly:

1. Searching for the next quote or backslash,
2. Copying the preceding substring into a new buffer, and
3. Removing the processed prefix from the original string with `slice!`.

An attacker can exploit this by sending a multipart request with many parts whose `name` parameters contain long escape-heavy values such as:

```text
name="a\\a\\a\\a\\a\\..."
```

Under default Rack limits, a request can contain up to 4095 parts. If many of those parts use long quoted values with dense escape characters, the parser performs disproportionately expensive CPU work while remaining within normal request size and part-count limits.

## Impact

Any Rack application that accepts `multipart/form-data` requests may be affected, including file upload endpoints and standard HTML form handlers.

An unauthenticated attacker can send crafted multipart requests that consume excessive CPU time during request parsing. Repeated requests can tie up application workers, reduce throughput, and degrade or deny service availability.

## Mitigation

* Update to a patched version of Rack that parses quoted multipart parameters without repeated rescanning and destructive prefix deletion.
* Apply request throttling or rate limiting to multipart upload endpoints.
* Where operationally feasible, restrict or isolate multipart parsing on untrusted high-volume endpoints.
GitHub Security Advisory: GHSA-x8cg-fq8g-mxfx
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack's multipart byte range processing allows denial of service via excessive overlapping ranges

Details:
## Summary

`Rack::Utils.get_byte_ranges` parses the HTTP `Range` header without limiting the number of individual byte ranges. Although the existing fix for CVE-2024-26141 rejects ranges whose total byte coverage exceeds the file size, it does not restrict the count of ranges. An attacker can supply many small overlapping ranges such as `0-0,0-0,0-0,...` to trigger disproportionate CPU, memory, I/O, and bandwidth consumption per request.

This results in a denial of service condition in Rack file-serving paths that process multipart byte range responses.

## Details

`Rack::Utils.get_byte_ranges` accepts a comma-separated list of byte ranges and validates them based on their aggregate size, but does not impose a limit on how many individual ranges may be supplied.

As a result, a request such as:

```http
Range: bytes=0-0,0-0,0-0,0-0,...
```

can contain thousands of overlapping one-byte ranges while still satisfying the total-size check added for CVE-2024-26141.

When such a header is processed by Rack’s file-serving code, each range causes additional work, including multipart response generation, per-range iteration, file seek and read operations, and temporary string allocation for response size calculation and output. This allows a relatively small request header to trigger disproportionately expensive processing and a much larger multipart response.

The issue is distinct from CVE-2024-26141. That fix prevents range sets whose total byte coverage exceeds the file size, but does not prevent a large number of overlapping ranges whose summed size remains within that limit.

## Impact

Applications that expose file-serving paths with byte range support may be vulnerable to denial of service.

An unauthenticated attacker can send crafted `Range` headers containing many small overlapping ranges to consume excessive CPU time, memory, file I/O, and bandwidth. Repeated requests may reduce application availability and increase pressure on workers and garbage collection.

## Mitigation

* Update to a patched version of Rack that limits the number of accepted byte ranges.
* Reject or normalize multipart byte range requests containing excessive range counts.
* Consider disabling multipart range support where it is not required.
* Apply request filtering or header restrictions at the reverse proxy or application boundary to limit abusive `Range` headers.
GitHub Security Advisory: GHSA-x8cg-fq8g-mxfx
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack's multipart byte range processing allows denial of service via excessive overlapping ranges

Details:
## Summary

`Rack::Utils.get_byte_ranges` parses the HTTP `Range` header without limiting the number of individual byte ranges. Although the existing fix for CVE-2024-26141 rejects ranges whose total byte coverage exceeds the file size, it does not restrict the count of ranges. An attacker can supply many small overlapping ranges such as `0-0,0-0,0-0,...` to trigger disproportionate CPU, memory, I/O, and bandwidth consumption per request.

This results in a denial of service condition in Rack file-serving paths that process multipart byte range responses.

## Details

`Rack::Utils.get_byte_ranges` accepts a comma-separated list of byte ranges and validates them based on their aggregate size, but does not impose a limit on how many individual ranges may be supplied.

As a result, a request such as:

```http
Range: bytes=0-0,0-0,0-0,0-0,...
```

can contain thousands of overlapping one-byte ranges while still satisfying the total-size check added for CVE-2024-26141.

When such a header is processed by Rack’s file-serving code, each range causes additional work, including multipart response generation, per-range iteration, file seek and read operations, and temporary string allocation for response size calculation and output. This allows a relatively small request header to trigger disproportionately expensive processing and a much larger multipart response.

The issue is distinct from CVE-2024-26141. That fix prevents range sets whose total byte coverage exceeds the file size, but does not prevent a large number of overlapping ranges whose summed size remains within that limit.

## Impact

Applications that expose file-serving paths with byte range support may be vulnerable to denial of service.

An unauthenticated attacker can send crafted `Range` headers containing many small overlapping ranges to consume excessive CPU time, memory, file I/O, and bandwidth. Repeated requests may reduce application availability and increase pressure on workers and garbage collection.

## Mitigation

* Update to a patched version of Rack that limits the number of accepted byte ranges.
* Reject or normalize multipart byte range requests containing excessive range counts.
* Consider disabling multipart range support where it is not required.
* Apply request filtering or header restrictions at the reverse proxy or application boundary to limit abusive `Range` headers.
GitHub Security Advisory: GHSA-x8cg-fq8g-mxfx
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack's multipart byte range processing allows denial of service via excessive overlapping ranges

Details:
## Summary

`Rack::Utils.get_byte_ranges` parses the HTTP `Range` header without limiting the number of individual byte ranges. Although the existing fix for CVE-2024-26141 rejects ranges whose total byte coverage exceeds the file size, it does not restrict the count of ranges. An attacker can supply many small overlapping ranges such as `0-0,0-0,0-0,...` to trigger disproportionate CPU, memory, I/O, and bandwidth consumption per request.

This results in a denial of service condition in Rack file-serving paths that process multipart byte range responses.

## Details

`Rack::Utils.get_byte_ranges` accepts a comma-separated list of byte ranges and validates them based on their aggregate size, but does not impose a limit on how many individual ranges may be supplied.

As a result, a request such as:

```http
Range: bytes=0-0,0-0,0-0,0-0,...
```

can contain thousands of overlapping one-byte ranges while still satisfying the total-size check added for CVE-2024-26141.

When such a header is processed by Rack’s file-serving code, each range causes additional work, including multipart response generation, per-range iteration, file seek and read operations, and temporary string allocation for response size calculation and output. This allows a relatively small request header to trigger disproportionately expensive processing and a much larger multipart response.

The issue is distinct from CVE-2024-26141. That fix prevents range sets whose total byte coverage exceeds the file size, but does not prevent a large number of overlapping ranges whose summed size remains within that limit.

## Impact

Applications that expose file-serving paths with byte range support may be vulnerable to denial of service.

An unauthenticated attacker can send crafted `Range` headers containing many small overlapping ranges to consume excessive CPU time, memory, file I/O, and bandwidth. Repeated requests may reduce application availability and increase pressure on workers and garbage collection.

## Mitigation

* Update to a patched version of Rack that limits the number of accepted byte ranges.
* Reject or normalize multipart byte range requests containing excessive range counts.
* Consider disabling multipart range support where it is not required.
* Apply request filtering or header restrictions at the reverse proxy or application boundary to limit abusive `Range` headers.
GitHub Security Advisory: GHSA-q4qf-9j86-f5mh
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack:: Static header_rules bypass via URL-encoded paths

Details:
## Summary

`Rack::Static#applicable_rules` evaluates several `header_rules` types against the raw URL-encoded `PATH_INFO`, while the underlying file-serving path is decoded before the file is served. As a result, a request for a URL-encoded variant of a static path can serve the same file without the headers that `header_rules` were intended to apply.

In deployments that rely on `Rack::Static` to attach security-relevant response headers to static content, this can allow an attacker to bypass those headers by requesting an encoded form of the path.

## Details

`Rack::Static#applicable_rules` matches rule types such as `:fonts`, `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:

```ruby
when :fonts
  /\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
when Array
  /\.(#{rule.join('|')})\z/.match?(path)
when Regexp
  rule.match?(path)
```

These checks operate on the raw request path. If the request contains encoded characters such as `%2E` in place of `.`, the rule may fail to match even though the file path is later decoded and served successfully by the static file server.

For example, both of the following requests may resolve to the same file on disk:

```text
/fonts/test.woff
/fonts/test%2Ewoff
```

but only the unencoded form may receive the headers configured through `header_rules`.

This creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.

## Impact

Applications that rely on `Rack::Static` `header_rules` to apply security-relevant headers to static files may be affected.

In affected deployments, an attacker can request an encoded variant of a static file path and receive the same file without the intended headers. Depending on how `header_rules` are used, this may bypass protections such as clickjacking defenses, content restrictions, or other response policies applied to static content.

The practical impact depends on the configured rules and the types of files being served. If `header_rules` are only used for non-security purposes such as caching, the issue may have limited security significance.

## Mitigation

* Update to a patched version of Rack that applies `header_rules` to a decoded path consistently with static file resolution.
* Do not rely solely on `Rack::Static` `header_rules` for security-critical headers where encoded path variants may reach the application.
* Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.
* Normalize or reject encoded path variants for static content at the edge, where feasible.
GitHub Security Advisory: GHSA-q4qf-9j86-f5mh
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack:: Static header_rules bypass via URL-encoded paths

Details:
## Summary

`Rack::Static#applicable_rules` evaluates several `header_rules` types against the raw URL-encoded `PATH_INFO`, while the underlying file-serving path is decoded before the file is served. As a result, a request for a URL-encoded variant of a static path can serve the same file without the headers that `header_rules` were intended to apply.

In deployments that rely on `Rack::Static` to attach security-relevant response headers to static content, this can allow an attacker to bypass those headers by requesting an encoded form of the path.

## Details

`Rack::Static#applicable_rules` matches rule types such as `:fonts`, `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:

```ruby
when :fonts
  /\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
when Array
  /\.(#{rule.join('|')})\z/.match?(path)
when Regexp
  rule.match?(path)
```

These checks operate on the raw request path. If the request contains encoded characters such as `%2E` in place of `.`, the rule may fail to match even though the file path is later decoded and served successfully by the static file server.

For example, both of the following requests may resolve to the same file on disk:

```text
/fonts/test.woff
/fonts/test%2Ewoff
```

but only the unencoded form may receive the headers configured through `header_rules`.

This creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.

## Impact

Applications that rely on `Rack::Static` `header_rules` to apply security-relevant headers to static files may be affected.

In affected deployments, an attacker can request an encoded variant of a static file path and receive the same file without the intended headers. Depending on how `header_rules` are used, this may bypass protections such as clickjacking defenses, content restrictions, or other response policies applied to static content.

The practical impact depends on the configured rules and the types of files being served. If `header_rules` are only used for non-security purposes such as caching, the issue may have limited security significance.

## Mitigation

* Update to a patched version of Rack that applies `header_rules` to a decoded path consistently with static file resolution.
* Do not rely solely on `Rack::Static` `header_rules` for security-critical headers where encoded path variants may reach the application.
* Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.
* Normalize or reject encoded path variants for static content at the edge, where feasible.
GitHub Security Advisory: GHSA-q4qf-9j86-f5mh
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-180: Incorrect Behavior Order: Validate Before Canonicalize
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack:: Static header_rules bypass via URL-encoded paths

Details:
## Summary

`Rack::Static#applicable_rules` evaluates several `header_rules` types against the raw URL-encoded `PATH_INFO`, while the underlying file-serving path is decoded before the file is served. As a result, a request for a URL-encoded variant of a static path can serve the same file without the headers that `header_rules` were intended to apply.

In deployments that rely on `Rack::Static` to attach security-relevant response headers to static content, this can allow an attacker to bypass those headers by requesting an encoded form of the path.

## Details

`Rack::Static#applicable_rules` matches rule types such as `:fonts`, `Array`, and `Regexp` directly against the incoming `PATH_INFO`. For example:

```ruby
when :fonts
  /\.(?:ttf|otf|eot|woff2|woff|svg)\z/.match?(path)
when Array
  /\.(#{rule.join('|')})\z/.match?(path)
when Regexp
  rule.match?(path)
```

These checks operate on the raw request path. If the request contains encoded characters such as `%2E` in place of `.`, the rule may fail to match even though the file path is later decoded and served successfully by the static file server.

For example, both of the following requests may resolve to the same file on disk:

```text
/fonts/test.woff
/fonts/test%2Ewoff
```

but only the unencoded form may receive the headers configured through `header_rules`.

This creates a canonicalization mismatch between the path used for header policy decisions and the path ultimately used for file serving.

## Impact

Applications that rely on `Rack::Static` `header_rules` to apply security-relevant headers to static files may be affected.

In affected deployments, an attacker can request an encoded variant of a static file path and receive the same file without the intended headers. Depending on how `header_rules` are used, this may bypass protections such as clickjacking defenses, content restrictions, or other response policies applied to static content.

The practical impact depends on the configured rules and the types of files being served. If `header_rules` are only used for non-security purposes such as caching, the issue may have limited security significance.

## Mitigation

* Update to a patched version of Rack that applies `header_rules` to a decoded path consistently with static file resolution.
* Do not rely solely on `Rack::Static` `header_rules` for security-critical headers where encoded path variants may reach the application.
* Prefer setting security headers at the reverse proxy or web server layer so they apply consistently to both encoded and unencoded path forms.
* Normalize or reject encoded path variants for static content at the edge, where feasible.