deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-33qg-7wpp-89cq
Package: rack-session (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-287: Improper Authentication, CWE-345: Insufficient Verification of Data Authenticity, CWE-502: Deserialization of Untrusted Data, CWE-565: Reliance on Cookies without Validation and Integrity Checking
Vulnerable versions: >= 2.0.0, < 2.1.2
Patched in: 2.1.2

Summary: Rack::Session::Cookie secrets: decrypt failure fallback enables secretless session forgery and Marshal deserialization

Details:
`Rack::Session::Cookie` incorrectly handles decryption failures when configured with `secrets:`. If cookie decryption fails, the implementation falls back to a default decoder instead of rejecting the cookie. This allows an unauthenticated attacker to supply a crafted session cookie that is accepted as valid session data without knowledge of any configured secret.

Because this mechanism is used to load session state, an attacker can manipulate session contents and potentially gain unauthorized access.

## Details

When `secrets:` is configured, `Rack::Session::Cookie` attempts to decrypt incoming session cookies using one of the configured encryptors. If all decrypt attempts fail, the implementation does not reject the cookie. Instead, it falls back to decoding the cookie using a default coder.

This fallback path processes attacker-controlled cookie data as trusted session state. The behavior is implicit and occurs even when encrypted cookies are expected.

The fallback decoder is applied automatically and does not require the application to opt into a non-encrypted session format. As a result, a client can send a specially crafted cookie value that bypasses the intended integrity protections provided by `secrets:`.

This issue affects both default configurations and those using alternative serializers for encrypted payloads.

## Impact

Any Rack application using `Rack::Session::Cookie` with `secrets:` may be affected.

> [!NOTE]
> Rails applications are typically not affected — Rails uses `ActionDispatch::Session::CookieStore`, which is a separate implementation backed by `ActiveSupport::MessageEncryptor` and does not share the vulnerable code path.

An unauthenticated attacker can supply a crafted session cookie that is accepted as valid session data. This can lead to authentication bypass or privilege escalation in applications that rely on session values for identity or authorization decisions.

Depending on application behavior and available runtime components, processing of untrusted session data may also expose additional risks.

## Mitigation

* Update to a patched version of`rack-session` that rejects cookies when decryption fails under the `secrets:` configuration.
  * After updating, rotate session secrets to invalidate existing session cookies, since attacker-supplied session data may have been accepted and re-issued prior to the fix.
GitHub Security Advisory: GHSA-6r34-94wq-jhrc
Package: rdiscount (RUBYGEMS)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-125: Out-of-bounds Read
Vulnerable versions: >= 1.3.1.1, < 2.2.7.4
Patched in: 2.2.7.4

Summary: rdiscount has an Out-of-bounds Read

Details:
### Summary

A signed length truncation bug causes an out-of-bounds read in the default Markdown parse path. Inputs larger than `INT_MAX` are truncated to a signed `int` before entering the native parser, allowing the parser to read past the end of the supplied buffer and crash the process

### Details

In both public entry points:

- `ext/rdiscount.c:97`
- `ext/rdiscount.c:136`

`RSTRING_LEN(text)` is passed directly into `mkd_string()`:

```c
MMIOT *doc = mkd_string(RSTRING_PTR(text), RSTRING_LEN(text), flags);
```

`mkd_string()` accepts `int len`:

- `ext/mkdio.c:174`

```c
Document * mkd_string(const char *buf, int len, mkd_flag_t flags)
{
    struct string_stream about;

    about.data = buf;
    about.size = len;

    return populate((getc_func)__mkd_io_strget, &about, flags & INPUT_MASK);
}
```

The parser stores the remaining input length in a signed `int`:

- `ext/markdown.h:205`

```c
struct string_stream {
    const char *data;
    int   size;
};
```

The read loop stops only when `size == 0`:

- `ext/mkdio.c:161`

```c
int __mkd_io_strget(struct string_stream *in)
{
    if ( !in->size ) return EOF;

    --(in->size);

    return *(in->data)++;
}
```

If the Ruby string length exceeds `INT_MAX`, the value can truncate to a negative `int`. In that state, the parser continues incrementing `data` and reading past the end of the original Ruby string, causing an out-of-bounds read and native crash.

Affected APIs:

- `RDiscount.new(input).to_html`
- `RDiscount.new(input).toc_content`

### PoC

Crash via `to_html`:

```sh
RUBYLIB=lib:ext ruby -e 'require "rdiscount"; n=2_200_000_000; s = "a" * n; warn "built=#{s.bytesize}"; RDiscount.new(s).to_html"'
```
result:

- `built=[PII_REDACTED]`
- Ruby terminates with `[BUG] Segmentation fault`
- top control frame: `CFUNC :to_html`

same result with `toc_content`

### Impact

This is an out-of-bounds read with the main issue being reliable denial-of-service. Impacted is limited to deployments parses attacker-controlled Markdown and permits multi-GB inputs.

### Fix

just add a checked length guard before the `mkd_string()` call in both public entry points:

- `ext/rdiscount.c:97`
- `ext/rdiscount.c:136`
ex: 
```c
VALUE text = rb_funcall(self, rb_intern("text"), 0);
long text_len = RSTRING_LEN(text);
VALUE buf = rb_str_buf_new(1024);
Check_Type(text, T_STRING);

if (text_len > INT_MAX) {
    rb_raise(rb_eArgError, "markdown input too large");
}

MMIOT *doc = mkd_string(RSTRING_PTR(text), (int)text_len, flags);
```

The same guard should be applied in `rb_rdiscount_toc_content()` before its `mkd_string()` call.
GitHub Security Advisory: GHSA-g2pf-xv49-m2h5
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-1286: Improper Validation of Syntactic Correctness of Input
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack::Request accepts invalid Host characters, enabling host allowlist bypass

Details:
## Summary

`Rack::Request` parses the `Host` header using an `AUTHORITY` regular expression that accepts characters not permitted in RFC-compliant hostnames, including `/`, `?`, `#`, and `@`. Because `req.host` returns the full parsed value, applications that validate hosts using naive prefix or suffix checks can be bypassed.

For example, a check such as `req.host.start_with?("myapp.com")` can be bypassed with `Host: myapp.com@evil.com`, and a check such as `req.host.end_with?("myapp.com")` can be bypassed with `Host: evil.com/myapp.com`.

This can lead to host header poisoning in applications that use `req.host`, `req.url`, or `req.base_url` for link generation, redirects, or origin validation.

## Details

`Rack::Request` parses the authority component using logic equivalent to:

```ruby
AUTHORITY = /
  \A
  (?<host>
    \[(?<address>#{ipv6})\]
    |
    (?<address>[[[:graph:]&&[^\[\]]]]*?)
  )
  (:(?<port>\d+))?
  \z
/x
```

The character class used for non-IPv6 hosts accepts nearly all printable characters except `[` and `]`. This includes reserved URI delimiters such as `@`, `/`, `?`, and `#`, which are not valid hostname characters under RFC 3986 host syntax.

As a result, values such as the following are accepted and returned through `req.host`:

```text
myapp.com@evil.com
evil.com/myapp.com
evil.com#myapp.com
```

Applications that attempt to allowlist hosts using string prefix or suffix checks may therefore treat attacker-controlled hosts as trusted. For example:

```ruby
req.host.start_with?("myapp.com")
```

accepts:

```text
myapp.com@evil.com
```

and:

```ruby
req.host.end_with?("myapp.com")
```

accepts:

```text
evil.com/myapp.com
```

When those values are later used to build absolute URLs or enforce origin restrictions, the application may produce attacker-controlled results.

## Impact

Applications that rely on `req.host`, `req.url`, or `req.base_url` may be affected if they perform naive host validation or assume Rack only returns RFC-valid hostnames.

In affected deployments, an attacker may be able to bypass host allowlists and poison generated links, redirects, or origin-dependent security decisions. This can enable attacks such as password reset link poisoning or other host header injection issues.

The practical impact depends on application behavior. If the application or reverse proxy already enforces strict host validation, exploitability may be reduced or eliminated.

## Mitigation

* Update to a patched version of Rack that rejects invalid authority characters in `Host`.
* Enforce strict `Host` header validation at the reverse proxy or load balancer.
* Do not rely on prefix or suffix string checks such as `start_with?` or `end_with?` for host allowlisting.
* Use exact host allowlists, or exact subdomain boundary checks, after validating that the host is syntactically valid.
GitHub Security Advisory: GHSA-g2pf-xv49-m2h5
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-1286: Improper Validation of Syntactic Correctness of Input
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack::Request accepts invalid Host characters, enabling host allowlist bypass

Details:
## Summary

`Rack::Request` parses the `Host` header using an `AUTHORITY` regular expression that accepts characters not permitted in RFC-compliant hostnames, including `/`, `?`, `#`, and `@`. Because `req.host` returns the full parsed value, applications that validate hosts using naive prefix or suffix checks can be bypassed.

For example, a check such as `req.host.start_with?("myapp.com")` can be bypassed with `Host: myapp.com@evil.com`, and a check such as `req.host.end_with?("myapp.com")` can be bypassed with `Host: evil.com/myapp.com`.

This can lead to host header poisoning in applications that use `req.host`, `req.url`, or `req.base_url` for link generation, redirects, or origin validation.

## Details

`Rack::Request` parses the authority component using logic equivalent to:

```ruby
AUTHORITY = /
  \A
  (?<host>
    \[(?<address>#{ipv6})\]
    |
    (?<address>[[[:graph:]&&[^\[\]]]]*?)
  )
  (:(?<port>\d+))?
  \z
/x
```

The character class used for non-IPv6 hosts accepts nearly all printable characters except `[` and `]`. This includes reserved URI delimiters such as `@`, `/`, `?`, and `#`, which are not valid hostname characters under RFC 3986 host syntax.

As a result, values such as the following are accepted and returned through `req.host`:

```text
myapp.com@evil.com
evil.com/myapp.com
evil.com#myapp.com
```

Applications that attempt to allowlist hosts using string prefix or suffix checks may therefore treat attacker-controlled hosts as trusted. For example:

```ruby
req.host.start_with?("myapp.com")
```

accepts:

```text
myapp.com@evil.com
```

and:

```ruby
req.host.end_with?("myapp.com")
```

accepts:

```text
evil.com/myapp.com
```

When those values are later used to build absolute URLs or enforce origin restrictions, the application may produce attacker-controlled results.

## Impact

Applications that rely on `req.host`, `req.url`, or `req.base_url` may be affected if they perform naive host validation or assume Rack only returns RFC-valid hostnames.

In affected deployments, an attacker may be able to bypass host allowlists and poison generated links, redirects, or origin-dependent security decisions. This can enable attacks such as password reset link poisoning or other host header injection issues.

The practical impact depends on application behavior. If the application or reverse proxy already enforces strict host validation, exploitability may be reduced or eliminated.

## Mitigation

* Update to a patched version of Rack that rejects invalid authority characters in `Host`.
* Enforce strict `Host` header validation at the reverse proxy or load balancer.
* Do not rely on prefix or suffix string checks such as `start_with?` or `end_with?` for host allowlisting.
* Use exact host allowlists, or exact subdomain boundary checks, after validating that the host is syntactically valid.
GitHub Security Advisory: GHSA-q2ww-5357-x388
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-135: Incorrect Calculation of Multi-Byte String Length
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack has Content-Length mismatch in Rack::Files error responses

Details:
## Summary

`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.

Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.

This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.

## Details

`Rack::Files#fail` constructs error responses using logic equivalent to:

```ruby
def fail(status, body, headers = {})
  body += "\n"
  [
    status,
    {
      "content-type" => "text/plain",
      "content-length" => body.size.to_s,
      "x-cascade" => "pass"
    }.merge!(headers),
    [body]
  ]
end
```

Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.

`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.

As a result, the server can send more bytes than declared in the response headers.

This violates HTTP message framing requirements, which define `Content-Length` as the number of octets in the message body.

## Impact

Applications using `Rack::Files` may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.

In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on `Content-Length`, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.

Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.

## Mitigation

* Update to a patched version of Rack that computes `Content-Length` using `String#bytesize`.
* Avoid exposing `Rack::Files` directly to untrusted traffic until a fix is available, if operationally feasible.
* Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
* Prefer closing backend connections on error paths if response framing anomalies are a concern.
GitHub Security Advisory: GHSA-q2ww-5357-x388
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-135: Incorrect Calculation of Multi-Byte String Length
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack has Content-Length mismatch in Rack::Files error responses

Details:
## Summary

`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.

Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.

This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.

## Details

`Rack::Files#fail` constructs error responses using logic equivalent to:

```ruby
def fail(status, body, headers = {})
  body += "\n"
  [
    status,
    {
      "content-type" => "text/plain",
      "content-length" => body.size.to_s,
      "x-cascade" => "pass"
    }.merge!(headers),
    [body]
  ]
end
```

Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.

`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.

As a result, the server can send more bytes than declared in the response headers.

This violates HTTP message framing requirements, which define `Content-Length` as the number of octets in the message body.

## Impact

Applications using `Rack::Files` may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.

In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on `Content-Length`, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.

Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.

## Mitigation

* Update to a patched version of Rack that computes `Content-Length` using `String#bytesize`.
* Avoid exposing `Rack::Files` directly to untrusted traffic until a fix is available, if operationally feasible.
* Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
* Prefer closing backend connections on error paths if response framing anomalies are a concern.
GitHub Security Advisory: GHSA-q2ww-5357-x388
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 4.8)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency, CWE-135: Incorrect Calculation of Multi-Byte String Length
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack has Content-Length mismatch in Rack::Files error responses

Details:
## Summary

`Rack::Files#fail` sets the `Content-Length` response header using `String#size` instead of `String#bytesize`. When the response body contains multibyte UTF-8 characters, the declared `Content-Length` is smaller than the number of bytes actually sent on the wire.

Because `Rack::Files` reflects the requested path in 404 responses, an attacker can trigger this mismatch by requesting a non-existent path containing percent-encoded UTF-8 characters.

This results in incorrect HTTP response framing and may cause response desynchronization in deployments that rely on the incorrect `Content-Length` value.

## Details

`Rack::Files#fail` constructs error responses using logic equivalent to:

```ruby
def fail(status, body, headers = {})
  body += "\n"
  [
    status,
    {
      "content-type" => "text/plain",
      "content-length" => body.size.to_s,
      "x-cascade" => "pass"
    }.merge!(headers),
    [body]
  ]
end
```

Here, `body.size` returns the number of characters, not the number of bytes. For multibyte UTF-8 strings, this produces an incorrect `Content-Length` value.

`Rack::Files` includes the decoded request path in 404 responses. A request containing percent-encoded UTF-8 path components therefore causes the response body to contain multibyte characters, while the `Content-Length` header still reflects character count rather than byte count.

As a result, the server can send more bytes than declared in the response headers.

This violates HTTP message framing requirements, which define `Content-Length` as the number of octets in the message body.

## Impact

Applications using `Rack::Files` may emit incorrectly framed error responses when handling requests for non-existent paths containing multibyte characters.

In some deployment topologies, particularly with keep-alive connections and intermediaries that rely on `Content-Length`, this mismatch may lead to response parsing inconsistencies or response desynchronization. The practical exploitability depends on the behavior of downstream proxies, clients, and connection reuse.

Even where no secondary exploitation is possible, the response is malformed and may trigger protocol errors in strict components.

## Mitigation

* Update to a patched version of Rack that computes `Content-Length` using `String#bytesize`.
* Avoid exposing `Rack::Files` directly to untrusted traffic until a fix is available, if operationally feasible.
* Where possible, place Rack behind a proxy or server that normalizes or rejects malformed backend responses.
* Prefer closing backend connections on error paths if response framing anomalies are a concern.
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.2.0, < 3.2.6
Patched in: 3.2.6

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.