deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-8vqr-qjwx-82mw
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
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 parsing without Content-Length header allows unbounded chunked file uploads

Details:
## Summary

`Rack::Multipart::Parser` only wraps the request body in a `BoundedIO` when `CONTENT_LENGTH` is present. When a `multipart/form-data` request is sent without a `Content-Length` header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit.

For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space.

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

## Details

`Rack::Multipart::Parser.parse` applies `BoundedIO` only when `content_length` is not `nil`:

```ruby
io = BoundedIO.new(io, content_length) if content_length
```

When `CONTENT_LENGTH` is absent, the parser reads the multipart body until EOF without a global byte limit.

Although Rack enforces `BUFFERED_UPLOAD_BYTESIZE_LIMIT` for retained non-file parts, file uploads are handled differently. When a multipart part includes a filename, the body is streamed to a `Tempfile`, and the retained-size accounting is not applied to that file content. As a result, file parts are not subject to the same upload size bound.

An attacker can exploit this by sending a chunked `multipart/form-data` request containing a file part and continuously streaming data without declaring a `Content-Length`. Rack will continue writing the uploaded data to disk until the client stops or the server exhausts available storage.

## Impact

Any Rack application that accepts `multipart/form-data` uploads may be affected if no upstream component enforces a request body size limit.

An unauthenticated attacker can send a large chunked file upload to consume disk space on the application host. This may cause request failures, application instability, or broader service disruption if the host runs out of available storage.

The practical impact depends on deployment architecture. Reverse proxies or application servers that enforce upload limits may reduce or eliminate exploitability, but Rack itself does not impose a total multipart upload limit in this code path when `CONTENT_LENGTH` is absent.

## Mitigation

* Update to a patched version of Rack that enforces a total multipart upload size limit even when `CONTENT_LENGTH` is absent.
* Enforce request body size limits at the reverse proxy or application server.
* Isolate temporary upload storage and monitor disk consumption for multipart endpoints.
GitHub Security Advisory: GHSA-8vqr-qjwx-82mw
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
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 parsing without Content-Length header allows unbounded chunked file uploads

Details:
## Summary

`Rack::Multipart::Parser` only wraps the request body in a `BoundedIO` when `CONTENT_LENGTH` is present. When a `multipart/form-data` request is sent without a `Content-Length` header, such as with HTTP chunked transfer encoding, multipart parsing continues until end-of-stream with no total size limit.

For file parts, the uploaded body is written directly to a temporary file on disk rather than being constrained by the buffered in-memory upload limit. An unauthenticated attacker can therefore stream an arbitrarily large multipart file upload and consume unbounded disk space.

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

## Details

`Rack::Multipart::Parser.parse` applies `BoundedIO` only when `content_length` is not `nil`:

```ruby
io = BoundedIO.new(io, content_length) if content_length
```

When `CONTENT_LENGTH` is absent, the parser reads the multipart body until EOF without a global byte limit.

Although Rack enforces `BUFFERED_UPLOAD_BYTESIZE_LIMIT` for retained non-file parts, file uploads are handled differently. When a multipart part includes a filename, the body is streamed to a `Tempfile`, and the retained-size accounting is not applied to that file content. As a result, file parts are not subject to the same upload size bound.

An attacker can exploit this by sending a chunked `multipart/form-data` request containing a file part and continuously streaming data without declaring a `Content-Length`. Rack will continue writing the uploaded data to disk until the client stops or the server exhausts available storage.

## Impact

Any Rack application that accepts `multipart/form-data` uploads may be affected if no upstream component enforces a request body size limit.

An unauthenticated attacker can send a large chunked file upload to consume disk space on the application host. This may cause request failures, application instability, or broader service disruption if the host runs out of available storage.

The practical impact depends on deployment architecture. Reverse proxies or application servers that enforce upload limits may reduce or eliminate exploitability, but Rack itself does not impose a total multipart upload limit in this code path when `CONTENT_LENGTH` is absent.

## Mitigation

* Update to a patched version of Rack that enforces a total multipart upload size limit even when `CONTENT_LENGTH` is absent.
* Enforce request body size limits at the reverse proxy or application server.
* Isolate temporary upload storage and monitor disk consumption for multipart endpoints.
GitHub Security Advisory: GHSA-7mqq-6cf9-v2qp
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-625: Permissive Regular Expression
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack has a root directory disclosure via unescaped regex interpolation in Rack::Directory

Details:
## Summary

`Rack::Directory` interpolates the configured `root` path directly into a regular expression when deriving the displayed directory path. If `root` contains regex metacharacters such as `+`, `*`, or `.`, the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output.

## Details

`Rack::Directory::DirectoryBody#each` computes the visible path using code equivalent to:

```ruby
show_path = Utils.escape_html(path.sub(/\A#{root}/, ''))
```

Here, `root` is a developer-configured filesystem path. It is normalized earlier with `File.expand_path(root)` and then inserted directly into a regular expression without escaping.

Because the value is treated as regex syntax rather than as a literal string, metacharacters in the configured path can change how the prefix match behaves. When that happens, the expected root prefix is not removed from `path`, and the absolute filesystem path is rendered into the HTML directory listing.

## Impact

If `Rack::Directory` is configured to serve a directory whose absolute path contains regex metacharacters, the generated directory listing may disclose the full server filesystem path instead of only the request-relative path.

This can expose internal deployment details such as directory layout, usernames, mount points, or naming conventions that would otherwise not be visible to clients.

## Mitigation

* Update to a patched version of Rack in which the root prefix is removed using an escaped regular expression.
* Avoid using `Rack::Directory` with a root path that contains regular expression metacharacters.
GitHub Security Advisory: GHSA-7mqq-6cf9-v2qp
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-625: Permissive Regular Expression
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack has a root directory disclosure via unescaped regex interpolation in Rack::Directory

Details:
## Summary

`Rack::Directory` interpolates the configured `root` path directly into a regular expression when deriving the displayed directory path. If `root` contains regex metacharacters such as `+`, `*`, or `.`, the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output.

## Details

`Rack::Directory::DirectoryBody#each` computes the visible path using code equivalent to:

```ruby
show_path = Utils.escape_html(path.sub(/\A#{root}/, ''))
```

Here, `root` is a developer-configured filesystem path. It is normalized earlier with `File.expand_path(root)` and then inserted directly into a regular expression without escaping.

Because the value is treated as regex syntax rather than as a literal string, metacharacters in the configured path can change how the prefix match behaves. When that happens, the expected root prefix is not removed from `path`, and the absolute filesystem path is rendered into the HTML directory listing.

## Impact

If `Rack::Directory` is configured to serve a directory whose absolute path contains regex metacharacters, the generated directory listing may disclose the full server filesystem path instead of only the request-relative path.

This can expose internal deployment details such as directory layout, usernames, mount points, or naming conventions that would otherwise not be visible to clients.

## Mitigation

* Update to a patched version of Rack in which the root prefix is removed using an escaped regular expression.
* Avoid using `Rack::Directory` with a root path that contains regular expression metacharacters.
GitHub Security Advisory: GHSA-7mqq-6cf9-v2qp
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-625: Permissive Regular Expression
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack has a root directory disclosure via unescaped regex interpolation in Rack::Directory

Details:
## Summary

`Rack::Directory` interpolates the configured `root` path directly into a regular expression when deriving the displayed directory path. If `root` contains regex metacharacters such as `+`, `*`, or `.`, the prefix stripping can fail and the generated directory listing may expose the full filesystem path in the HTML output.

## Details

`Rack::Directory::DirectoryBody#each` computes the visible path using code equivalent to:

```ruby
show_path = Utils.escape_html(path.sub(/\A#{root}/, ''))
```

Here, `root` is a developer-configured filesystem path. It is normalized earlier with `File.expand_path(root)` and then inserted directly into a regular expression without escaping.

Because the value is treated as regex syntax rather than as a literal string, metacharacters in the configured path can change how the prefix match behaves. When that happens, the expected root prefix is not removed from `path`, and the absolute filesystem path is rendered into the HTML directory listing.

## Impact

If `Rack::Directory` is configured to serve a directory whose absolute path contains regex metacharacters, the generated directory listing may disclose the full server filesystem path instead of only the request-relative path.

This can expose internal deployment details such as directory layout, usernames, mount points, or naming conventions that would otherwise not be visible to clients.

## Mitigation

* Update to a patched version of Rack in which the root prefix is removed using an escaped regular expression.
* Avoid using `Rack::Directory` with a root path that contains regular expression metacharacters.
GitHub Security Advisory: GHSA-rx22-g9mx-qrhv
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack's improper unfolding of folded multipart headers preserves CRLF in parsed parameter values

Details:
## Summary

`Rack::Multipart::Parser` unfolds folded multipart part headers incorrectly. When a multipart header contains an obs-fold sequence, Rack preserves the embedded CRLF in parsed parameter values such as `filename` or `name` instead of removing the folded line break during unfolding.

As a result, applications that later reuse those parsed values in HTTP response headers may be vulnerable to downstream header injection or response splitting.

## Details

`Rack::Multipart::Parser` accepts folded multipart header values and unfolds them during parsing. However, the unfolding behavior does not fully remove the embedded line break sequence from the parsed value.

This means a multipart part header such as:

```http
Content-Disposition: form-data; name="file"; filename="test\r\n foo.txt"
```

can result in a parsed parameter value that still contains CRLF characters.

The issue is not that Rack creates a second multipart header field. Rather, the problem is that CRLF remains embedded in the parsed metadata value after unfolding. If an application later uses that value in a security-sensitive context, such as constructing an HTTP response header, the preserved CRLF may alter downstream header parsing.

Affected values may include multipart parameters such as `filename`, `name`, or similar parsed header attributes.

## Impact

Applications that accept multipart form uploads may be affected if they later reuse parsed multipart metadata in HTTP headers or other header-sensitive contexts.

In affected deployments, an attacker may be able to supply a multipart parameter value containing folded line breaks and cause downstream header injection, response splitting, cache poisoning, or related response parsing issues.

The practical impact depends on application behavior. If parsed multipart metadata is not reused in HTTP headers, the issue may be limited to incorrect parsing behavior rather than a direct exploit path.

## Mitigation

* Update to a patched version of Rack that removes CRLF correctly when unfolding folded multipart header values.
* Avoid copying upload metadata such as `filename` directly into HTTP response headers without sanitization.
* Sanitize or reject carriage return and line feed characters in multipart-derived values before reusing them in response headers, logs, or downstream protocol contexts.
* Where feasible, normalize uploaded filenames before storing or reflecting them.
GitHub Security Advisory: GHSA-vgpv-f759-9wx3
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.

Details:
## Summary

`Rack::Multipart::Parser` extracts the `boundary` parameter from `multipart/form-data` using a greedy regular expression. When a `Content-Type` header contains multiple `boundary` parameters, Rack selects the last one rather than the first.

In deployments where an upstream proxy, WAF, or intermediary interprets the first `boundary` parameter, this mismatch can allow an attacker to smuggle multipart content past upstream inspection and have Rack parse a different body structure than the intermediary validated.

## Details

Rack identifies the multipart boundary using logic equivalent to:

```ruby
MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni
```

Because the expression is greedy, it matches the last `boundary=` parameter in a header such as:

```http
Content-Type: multipart/form-data; boundary=safe; boundary=malicious
```

As a result, Rack parses the request body using `malicious`, while another component may interpret the same header using `safe`.

This creates an interpretation conflict. If an upstream WAF or proxy inspects multipart parts using the first boundary and Rack later parses the body using the last boundary, a client may be able to place malicious form fields or uploaded content in parts that Rack accepts but the upstream component did not inspect as intended.

This issue is most relevant in layered deployments where security decisions are made before the request reaches Rack.

## Impact

Applications that accept `multipart/form-data` uploads behind an inspecting proxy or WAF may be affected.

In such deployments, an attacker may be able to bypass upstream filtering of uploaded files or form fields by sending a request with multiple `boundary` parameters and relying on the intermediary and Rack to parse the request differently.

The practical impact depends on deployment architecture. If no upstream component relies on a different multipart interpretation, this behavior may not provide meaningful additional attacker capability.

## Mitigation

* Update to a patched version of Rack that rejects ambiguous multipart `Content-Type` headers or parses duplicate `boundary` parameters consistently.
* Reject requests containing multiple `boundary` parameters.
* Normalize or regenerate multipart metadata at the trusted edge before forwarding requests to Rack.
* Avoid relying on upstream inspection of malformed multipart requests unless duplicate parameter handling is explicitly consistent across components.
GitHub Security Advisory: GHSA-vgpv-f759-9wx3
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.

Details:
## Summary

`Rack::Multipart::Parser` extracts the `boundary` parameter from `multipart/form-data` using a greedy regular expression. When a `Content-Type` header contains multiple `boundary` parameters, Rack selects the last one rather than the first.

In deployments where an upstream proxy, WAF, or intermediary interprets the first `boundary` parameter, this mismatch can allow an attacker to smuggle multipart content past upstream inspection and have Rack parse a different body structure than the intermediary validated.

## Details

Rack identifies the multipart boundary using logic equivalent to:

```ruby
MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni
```

Because the expression is greedy, it matches the last `boundary=` parameter in a header such as:

```http
Content-Type: multipart/form-data; boundary=safe; boundary=malicious
```

As a result, Rack parses the request body using `malicious`, while another component may interpret the same header using `safe`.

This creates an interpretation conflict. If an upstream WAF or proxy inspects multipart parts using the first boundary and Rack later parses the body using the last boundary, a client may be able to place malicious form fields or uploaded content in parts that Rack accepts but the upstream component did not inspect as intended.

This issue is most relevant in layered deployments where security decisions are made before the request reaches Rack.

## Impact

Applications that accept `multipart/form-data` uploads behind an inspecting proxy or WAF may be affected.

In such deployments, an attacker may be able to bypass upstream filtering of uploaded files or form fields by sending a request with multiple `boundary` parameters and relying on the intermediary and Rack to parse the request differently.

The practical impact depends on deployment architecture. If no upstream component relies on a different multipart interpretation, this behavior may not provide meaningful additional attacker capability.

## Mitigation

* Update to a patched version of Rack that rejects ambiguous multipart `Content-Type` headers or parses duplicate `boundary` parameters consistently.
* Reject requests containing multiple `boundary` parameters.
* Normalize or regenerate multipart metadata at the trusted edge before forwarding requests to Rack.
* Avoid relying on upstream inspection of malformed multipart requests unless duplicate parameter handling is explicitly consistent across components.
GitHub Security Advisory: GHSA-vgpv-f759-9wx3
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-436: Interpretation Conflict
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack's greedy multipart boundary parsing can cause parser differentials and WAF bypass.

Details:
## Summary

`Rack::Multipart::Parser` extracts the `boundary` parameter from `multipart/form-data` using a greedy regular expression. When a `Content-Type` header contains multiple `boundary` parameters, Rack selects the last one rather than the first.

In deployments where an upstream proxy, WAF, or intermediary interprets the first `boundary` parameter, this mismatch can allow an attacker to smuggle multipart content past upstream inspection and have Rack parse a different body structure than the intermediary validated.

## Details

Rack identifies the multipart boundary using logic equivalent to:

```ruby
MULTIPART = %r|\Amultipart/.*boundary=\"?([^\";,]+)\"?|ni
```

Because the expression is greedy, it matches the last `boundary=` parameter in a header such as:

```http
Content-Type: multipart/form-data; boundary=safe; boundary=malicious
```

As a result, Rack parses the request body using `malicious`, while another component may interpret the same header using `safe`.

This creates an interpretation conflict. If an upstream WAF or proxy inspects multipart parts using the first boundary and Rack later parses the body using the last boundary, a client may be able to place malicious form fields or uploaded content in parts that Rack accepts but the upstream component did not inspect as intended.

This issue is most relevant in layered deployments where security decisions are made before the request reaches Rack.

## Impact

Applications that accept `multipart/form-data` uploads behind an inspecting proxy or WAF may be affected.

In such deployments, an attacker may be able to bypass upstream filtering of uploaded files or form fields by sending a request with multiple `boundary` parameters and relying on the intermediary and Rack to parse the request differently.

The practical impact depends on deployment architecture. If no upstream component relies on a different multipart interpretation, this behavior may not provide meaningful additional attacker capability.

## Mitigation

* Update to a patched version of Rack that rejects ambiguous multipart `Content-Type` headers or parses duplicate `boundary` parameters consistently.
* Reject requests containing multiple `boundary` parameters.
* Normalize or regenerate multipart metadata at the trusted edge before forwarding requests to Rack.
* Avoid relying on upstream inspection of malformed multipart requests unless duplicate parameter handling is explicitly consistent across components.