deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-wpv5-97wm-hp9c
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 2.2.19
Patched in: 2.2.19

Summary: Rack's multipart parser buffers unbounded per-part headers, enabling DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` can accumulate unbounded data when a multipart part’s header block never terminates with the required blank line (`CRLFCRLF`). The parser keeps appending incoming bytes to memory without a size cap, allowing a remote attacker to exhaust memory and cause a denial of service (DoS).

## Details

While reading multipart headers, the parser waits for `CRLFCRLF` using:

```ruby
@sbuf.scan_until(/(.*?\r\n)\r\n/m)
```

If the terminator never appears, it continues appending data (`@sbuf.concat(content)`) indefinitely. There is no limit on accumulated header bytes, so a single malformed part can consume memory proportional to the request body size.

## Impact

Attackers can send incomplete multipart headers to trigger high memory use, leading to process termination (OOM) or severe slowdown. The effect scales with request size limits and concurrency. All applications handling multipart uploads may be affected.

## Mitigation

* Upgrade to a patched Rack version that caps per-part header size (e.g., 64 KiB).
* Until then, restrict maximum request sizes at the proxy or web server layer (e.g., Nginx `client_max_body_size`).
GitHub Security Advisory: GHSA-w9pc-fmgc-vxvw
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.2, < 3.2.2
Patched in: 3.2.2

Summary: Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).

## Details

During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory:

```ruby
body = String.new  # non-file → in-RAM buffer
@mime_parts[mime_index].body << content
```

There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to `params`.

## Impact

Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB).
* **Workarounds:**
  * Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx `client_max_body_size`).
  * Validate and reject unusually large form fields at the application level.
GitHub Security Advisory: GHSA-w9pc-fmgc-vxvw
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.1, < 3.1.17
Patched in: 3.1.17

Summary: Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).

## Details

During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory:

```ruby
body = String.new  # non-file → in-RAM buffer
@mime_parts[mime_index].body << content
```

There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to `params`.

## Impact

Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB).
* **Workarounds:**
  * Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx `client_max_body_size`).
  * Validate and reject unusually large form fields at the application level.
GitHub Security Advisory: GHSA-w9pc-fmgc-vxvw
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 2.2.19
Patched in: 2.2.19

Summary: Rack: Multipart parser buffers large non‑file fields entirely in memory, enabling DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` stores non-file form fields (parts without a `filename`) entirely in memory as Ruby `String` objects. A single large text field in a multipart/form-data request (hundreds of megabytes or more) can consume equivalent process memory, potentially leading to out-of-memory (OOM) conditions and denial of service (DoS).

## Details

During multipart parsing, file parts are streamed to temporary files, but non-file parts are buffered into memory:

```ruby
body = String.new  # non-file → in-RAM buffer
@mime_parts[mime_index].body << content
```

There is no size limit on these in-memory buffers. As a result, any large text field—while technically valid—will be loaded fully into process memory before being added to `params`.

## Impact

Attackers can send large non-file fields to trigger excessive memory usage. Impact scales with request size and concurrency, potentially leading to worker crashes or severe garbage-collection overhead. All Rack applications processing multipart form submissions are affected.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a reasonable size cap for non-file fields (e.g., 2 MiB).
* **Workarounds:**
  * Restrict maximum request body size at the web-server or proxy layer (e.g., Nginx `client_max_body_size`).
  * Validate and reject unusually large form fields at the application level.
GitHub Security Advisory: GHSA-p543-xpfm-54cp
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.2, < 3.2.2
Patched in: 3.2.2

Summary: Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.

## Details

While searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern:

```ruby
@sbuf.scan_until(@body_regex)
```

If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.

## Impact

Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).
* **Workarounds:**
  * Limit total request body size at the proxy or web server level.
  * Monitor memory and set per-process limits to prevent OOM conditions.
GitHub Security Advisory: GHSA-p543-xpfm-54cp
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.1, < 3.1.17
Patched in: 3.1.17

Summary: Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.

## Details

While searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern:

```ruby
@sbuf.scan_until(@body_regex)
```

If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.

## Impact

Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).
* **Workarounds:**
  * Limit total request body size at the proxy or web server level.
  * Monitor memory and set per-process limits to prevent OOM conditions.
GitHub Security Advisory: GHSA-p543-xpfm-54cp
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 2.2.19
Patched in: 2.2.19

Summary: Rack's unbounded multipart preamble buffering enables DoS (memory exhaustion)

Details:
## Summary

`Rack::Multipart::Parser` buffers the entire multipart **preamble** (bytes before the first boundary) in memory without any size limit. A client can send a large preamble followed by a valid boundary, causing significant memory use and potential process termination due to out-of-memory (OOM) conditions.

## Details

While searching for the first boundary, the parser appends incoming data into a shared buffer (`@sbuf.concat(content)`) and scans for the boundary pattern:

```ruby
@sbuf.scan_until(@body_regex)
```

If the boundary is not yet found, the parser continues buffering data indefinitely. There is no trimming or size cap on the preamble, allowing attackers to send arbitrary amounts of data before the first boundary.

## Impact

Remote attackers can trigger large transient memory spikes by including a long preamble in multipart/form-data requests. The impact scales with allowed request sizes and concurrency, potentially causing worker crashes or severe slowdown due to garbage collection.

## Mitigation

* **Upgrade:** Use a patched version of Rack that enforces a preamble size limit (e.g., 16 KiB) or discards preamble data entirely per [RFC 2046 § 5.1.1](https://www.rfc-editor.org/rfc/rfc2046.html#section-5.1.1).
* **Workarounds:**
  * Limit total request body size at the proxy or web server level.
  * Monitor memory and set per-process limits to prevent OOM conditions.
GitHub Security Advisory: GHSA-29mw-wpgm-hmr9
Package: lodash-rails (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 4.0.0, < 4.17.21
Patched in: 4.17.21

Summary: Regular Expression Denial of Service (ReDoS) in lodash

Details:
All versions of package lodash prior to 4.17.21 are vulnerable to Regular Expression Denial of Service (ReDoS) via the `toNumber`, `trim` and `trimEnd` functions. 

Steps to reproduce (provided by reporter Liyuan Chen):
```js
var lo = require('lodash');

function build_blank(n) {
    var ret = "1"
    for (var i = 0; i < n; i++) {
        ret += " "
    }
    return ret + "1";
}
var s = build_blank(50000) var time0 = Date.now();
lo.trim(s) 
var time_cost0 = Date.now() - time0;
console.log("time_cost0: " + time_cost0);
var time1 = Date.now();
lo.toNumber(s) var time_cost1 = Date.now() - time1;
console.log("time_cost1: " + time_cost1);
var time2 = Date.now();
lo.trimEnd(s);
var time_cost2 = Date.now() - time2;
console.log("time_cost2: " + time_cost2);
```
GitHub Security Advisory: GHSA-x5rq-j2xg-h7qm
Package: lodash-rails (RUBYGEMS)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 4.7.0, < 4.17.11
Patched in: 4.17.11

Summary: Regular Expression Denial of Service (ReDoS) in lodash

Details:
lodash prior to 4.7.11 is affected by: CWE-400: Uncontrolled Resource Consumption. The impact is: Denial of service. The component is: Date handler. The attack vector is: Attacker provides very long strings, which the library attempts to match using a regular expression. The fixed version is: 4.7.11.
GitHub Security Advisory: GHSA-625h-95r8-8xpm
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.18
Patched in: 2.2.18

Summary: Rack has an unsafe default in Rack::QueryParser allows params_limit bypass via semicolon-separated parameters

Details:
## Summary

`Rack::QueryParser` in version `< 2.2.18` enforces its `params_limit` only for parameters separated by `&`, while still splitting on both `&` and `;`. As a result, attackers could use `;` separators to bypass the parameter count limit and submit more parameters than intended.

## Details

The issue arises because `Rack::QueryParser#check_query_string` counts only `&` characters when determining the number of parameters, but the default separator regex `DEFAULT_SEP = /[&;] */n` splits on both `&` and `;`. This mismatch means that queries using `;` separators were not included in the parameter count, allowing `params_limit` to be bypassed.

Other safeguards (`bytesize_limit` and `key_space_limit`) still applied, but did not prevent this particular bypass.

## Impact

Applications or middleware that directly invoke `Rack::QueryParser` with its default configuration (no explicit delimiter) could be exposed to increased CPU and memory consumption. This can be abused as a limited denial-of-service vector.

`Rack::Request`, the primary entry point for typical Rack applications, uses `QueryParser` in a safe way and does not appear vulnerable by default. As such, the severity is considered **low**, with the impact limited to edge cases where `QueryParser` is used directly.

## Mitigation

* Upgrade to a patched version of Rack where both `&` and `;` are counted consistently toward `params_limit`.
* If upgrading is not immediately possible, configure `QueryParser` with an explicit delimiter (e.g., `&`) to avoid the mismatch.
* As a general precaution, enforce query string and request size limits at the web server or proxy layer (e.g., Nginx, Apache, or a CDN) to mitigate excessive parsing overhead.
GitHub Security Advisory: GHSA-c2f4-jgmc-q2r5
Package: rexml (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-776: Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion')
Vulnerable versions: >= 3.3.3, <= 3.4.1
Patched in: 3.4.2

Summary: REXML has DoS condition when parsing malformed XML file

Details:
### Impact

The REXML gems from 3.3.3 to 3.4.1 have a DoS vulnerability when parsing XML containing multiple XML declarations.
If you need to parse untrusted XMLs, you may be impacted to these vulnerabilities.

### Patches

REXML gems 3.4.2 or later include the patches to fix these vulnerabilities.

### Workarounds

Don't parse untrusted XMLs.

### References

* https://www.ruby-lang.org/en/news/2025/09/18/dos-rexml-cve-2025-58767/ : An announcement on www.ruby-lang.org
GitHub Security Advisory: GHSA-5jch-xhw4-r43v
Package: google_sign_in (RUBYGEMS)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 1.3.1
Patched in: 1.3.1

Summary: Google Sign-In for Rails allowed redirect to protocol-relative URI

Details:
## Summary

It is possible to redirect a user to another origin if the "proceed_to" value in the session store is set to a protocol-relative URL.

## Details

The google_sign_in gem persists an optional URL for redirection after authentication. If this URL is set to a protocol-relative URL, it improperly passes the "same origin" check, and it's possible for the user to be redirected to another origin after authentication, possibly resulting in exposure of authentication information if this attack is chained with other attacks.

Normally the value of this URL is only written and read by the library or the calling application. However, it may be possible to set this session value from a malicious site with a form submission.

## Impact

Any Rails applications using the google_sign_in gem may be vulnerable, if this vector can be chained with another attack that is able to modify the OAuth2 request parameters.

## Workarounds

No known workarounds.

## Credits

This issue was responsibly reported by Hackerone user [muntrive](https://hackerone.com/muntrive?type=user).
GitHub Security Advisory: GHSA-7pwc-wh6m-44q3
Package: google_sign_in (RUBYGEMS)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-601: URL Redirection to Untrusted Site ('Open Redirect')
Vulnerable versions: < 1.3.0
Patched in: 1.3.0

Summary: Google Sign-In for Rails allowed redirects to malformed URLs

Details:
### Summary

It is possible to craft a malformed URL that passes the "same origin" check, resulting in the user being redirected to another origin.

### Details

The google_sign_in gem persists an optional URL for redirection after authentication. If this URL is malformed, it's possible for the user to be redirected to another origin after authentication, possibly resulting in exposure of authentication information such as the token.

Normally the value of this URL is only written and read by the library. If applications are configured to store session information in a database, there is no known vector to exploit this vulnerability. However, applications may be configured to store this information in a session cookie, in which case it may be chained with a session cookie attack to inject a crafted URL.

### Impact

Rails applications configured to store the `flash` information in a session cookie may be vulnerable, if this can be chained with an attack that allows injection of arbitrary data into the session cookie.

### Workarounds

If you are unable to upgrade this library, then you may mitigate the chained attack by explicitly setting `SameSite=Lax` or `SameSite=Strict` on the application session cookie.

### Credits

This issue was responsibly reported by Hackerone user [muntrive](https://hackerone.com/muntrive?type=user).
GitHub Security Advisory: GHSA-r4mg-4433-c7g3
Package: activestorage (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 5.2.0, < 7.1.5.2
Patched in: 7.1.5.2

Summary: Active Storage allowed transformation methods that were potentially unsafe

Details:
Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.


Versions Affected:  >= 5.2.0
Not affected:       < 5.2.0
Fixed Versions:     7.1.5.2, 7.2.2.2, 8.0.2.1

Impact
------
This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

```
<%= image_tag blob.variant(params[:t] => params[:v]) %>
```

Where the transformation method or its arguments are untrusted arbitrary input.

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
-----------
Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong [ImageMagick security policy](https://imagemagick.org/script/security-policy.php) deployed.

Credits
-------

Thank you [lio346](https://hackerone.com/lio346) from Unit 515 of OPSWAT for reporting this!
GitHub Security Advisory: GHSA-r4mg-4433-c7g3
Package: activestorage (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: >= 7.2, < 7.2.2.2
Patched in: 7.2.2.2

Summary: Active Storage allowed transformation methods that were potentially unsafe

Details:
Active Storage attempts to prevent the use of potentially unsafe image transformation methods and parameters by default.

The default allowed list contains three methods allowing for the circumvention of the safe defaults which enables potential command injection vulnerabilities in cases where arbitrary user supplied input is accepted as valid transformation methods or parameters.

This has been assigned the CVE identifier CVE-2025-24293.


Versions Affected:  >= 5.2.0
Not affected:       < 5.2.0
Fixed Versions:     7.1.5.2, 7.2.2.2, 8.0.2.1

Impact
------
This vulnerability impacts applications that use Active Storage with the image_processing processing gem in addition to mini_magick as the image processor.

Vulnerable code will look something similar to this:

```
<%= image_tag blob.variant(params[:t] => params[:v]) %>
```

Where the transformation method or its arguments are untrusted arbitrary input.

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
-----------
Consuming user supplied input for image transformation methods or their parameters is unsupported behavior and should be considered dangerous.

Strict validation of user supplied methods and parameters should be performed as well as having a strong [ImageMagick security policy](https://imagemagick.org/script/security-policy.php) deployed.

Credits
-------

Thank you [lio346](https://hackerone.com/lio346) from Unit 515 of OPSWAT for reporting this!