deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-vfpf-xmwh-8m65
Package: prosemirror_to_html (RUBYGEMS)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: Duplicate Advisory: ProsemirrorToHtml has a Cross-Site Scripting (XSS) vulnerability through unescaped HTML attribute values

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-52c5-vh7f-26fx. This link is maintained to preserve external references.

## Original Description

### Impact

The prosemirror_to_html gem is vulnerable to Cross-Site Scripting
(XSS) attacks through malicious HTML attribute values. While tag
content is properly escaped, attribute values are not, allowing
attackers to inject arbitrary JavaScript code.

**Who is impacted:**

- Any application using prosemirror_to_html to convert ProseMirror
  documents to HTML
- Applications that process user-generated ProseMirror content are
  at highest risk
- End users viewing the rendered HTML output could have malicious
 JavaScript executed in their browsers

**Attack vectors include:**

- `href` attributes with `javascript:` protocol:
  `<a href="javascript:alert(document.cookie)">`
- Event handlers: `<div onclick="maliciousCode()">`
- `onerror` attributes on images: `<img src=x onerror="alert('XSS')">`
- Other HTML attributes that can execute JavaScript

### Patches

A fix is currently in development. Users should upgrade to version
**0.2.1** or later once released.

The patch escapes all HTML attribute values using `CGI.escapeHTML`
to prevent injection attacks.

### Workarounds

Until a patched version is available, users can implement one or
more of these mitigations:

1. **Sanitize output**: Pass the HTML output through a sanitization
   library like [Sanitize](https://github.com/rgrove/sanitize) or
   [Loofah](https://github.com/flavorjones/loofah):

```ruby
   html = ProsemirrorToHtml.render(document)
   safe_html = Sanitize.fragment(html, Sanitize::Config::RELAXED)
```

2. **Implement Content Security Policy (CSP)**: Add strict CSP
   headers to prevent inline JavaScript execution:
```
   Content-Security-Policy: default-src 'self'; script-src 'self'
```

3. **Input validation**: If possible, validate and sanitize
   ProseMirror documents before conversion to prevent malicious
   content from entering the system.

### References

- Vulnerable code: https://github.com/etaminstudio/prosemirror_to_html/blob/ea8beb32f6c37f29f042ba4155ccf18504da716e/lib/prosemirror_to_html.rb#L249
- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
GitHub Security Advisory: GHSA-9c5q-w6gr-fxcq
Package: mqtt (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-29: Path Traversal: '..filename'
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: MQTT does not validate hostnames

Details:
A flaw was found in Rubygem MQTT. By default, the package used to not have hostname validation, resulting in possible Man-in-the-Middle (MITM) attack.
GitHub Security Advisory: GHSA-52c5-vh7f-26fx
Package: prosemirror_to_html (RUBYGEMS)
Severity: HIGH (CVSS 7.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.2.1
Patched in: 0.2.1

Summary: Cross-Site Scripting (XSS) vulnerability through unescaped HTML attribute values

Details:
### Impact

The prosemirror_to_html gem is vulnerable to Cross-Site Scripting (XSS) attacks through malicious HTML attribute values. While tag content is properly escaped, attribute values are not, allowing attackers to inject arbitrary JavaScript code.

**Who is impacted:**
- Any application using prosemirror_to_html to convert ProseMirror documents to HTML
- Applications that process user-generated ProseMirror content are at highest risk
- End users viewing the rendered HTML output could have malicious JavaScript executed in their browsers

**Attack vectors include:**
- `href` attributes with `javascript:` protocol: `<a href="javascript:alert(document.cookie)">`
- Event handlers: `<div onclick="maliciousCode()">`
- `onerror` attributes on images: `<img src=x onerror="alert('XSS')">`
- Other HTML attributes that can execute JavaScript

### Patches

A fix is currently in development. Users should upgrade to version **0.2.1** or later once released.

The patch escapes all HTML attribute values using `CGI.escapeHTML` to prevent injection attacks.

### Workarounds

Until a patched version is available, users can implement one or more of these mitigations:

1. **Sanitize output**: Pass the HTML output through a sanitization library like [Sanitize](https://github.com/rgrove/sanitize) or [Loofah](https://github.com/flavorjones/loofah):
```ruby
   html = ProsemirrorToHtml.render(document)
   safe_html = Sanitize.fragment(html, Sanitize::Config::RELAXED)
```

2. **Implement Content Security Policy (CSP)**: Add strict CSP headers to prevent inline JavaScript execution:
```
   Content-Security-Policy: default-src 'self'; script-src 'self'
```

3. **Input validation**: If possible, validate and sanitize ProseMirror documents before conversion to prevent malicious content from entering the system.

### References

- Vulnerable code: https://github.com/etaminstudio/prosemirror_to_html/blob/ea8beb32f6c37f29f042ba4155ccf18504da716e/lib/prosemirror_to_html.rb#L249
- [OWASP XSS Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html)
- [CWE-79: Improper Neutralization of Input During Web Page Generation](https://cwe.mitre.org/data/definitions/79.html)
GitHub Security Advisory: GHSA-h6w6-xmqv-7q78
Package: activerecord (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 3.1.0.beta1, < 3.1.0.rc5
Patched in: 3.1.0.rc5

Summary: activerecord vulnerable to SQL Injection

Details:
Multiple SQL injection vulnerabilities in the `quote_table_name` method in the ActiveRecord adapters in `activerecord/lib/active_record/connection_adapters/` in Ruby on Rails before 2.3.13, 3.0.x before 3.0.10, and 3.1.x before 3.1.0.rc5 allow remote attackers to execute arbitrary SQL commands via a crafted column name.
GitHub Security Advisory: GHSA-h6w6-xmqv-7q78
Package: activerecord (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 3.0.0.beta, < 3.0.10
Patched in: 3.0.10

Summary: activerecord vulnerable to SQL Injection

Details:
Multiple SQL injection vulnerabilities in the `quote_table_name` method in the ActiveRecord adapters in `activerecord/lib/active_record/connection_adapters/` in Ruby on Rails before 2.3.13, 3.0.x before 3.0.10, and 3.1.x before 3.1.0.rc5 allow remote attackers to execute arbitrary SQL commands via a crafted column name.
GitHub Security Advisory: GHSA-mr3q-g2mv-mr4q
Package: sinatra (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 4.2.0
Patched in: 4.2.0

Summary: Sinatra is vulnerable to ReDoS through ETag header value generation

Details:
### Summary

There is a denial of service vulnerability in the `If-Match` and `If-None-Match` header parsing component of Sinatra, if the `etag` method is used when constructing the response and you are using Ruby < 3.2.

### Details

Carefully crafted input can cause `If-Match` and `If-None-Match` header parsing in Sinatra to take an unexpected amount of time, possibly resulting in a denial of service attack vector. This header is typically involved in generating the `ETag` header value. Any applications that use the `etag` method when generating a response are impacted if they are using Ruby below version 3.2.

### Resources

* https://github.com/sinatra/sinatra/issues/2120 (report)
* https://github.com/sinatra/sinatra/pull/2121 (fix)
* https://github.com/sinatra/sinatra/pull/1823 (older ReDoS vulnerability)
* https://bugs.ruby-lang.org/issues/19104 (fix in Ruby >= 3.2)
GitHub Security Advisory: GHSA-6xw4-3v39-52mm
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.2, < 3.2.3
Patched in: 3.2.3

Summary: Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

Details:
## Summary

`Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

## Details

When handling non-multipart form submissions, Rack’s request parser performs:

```ruby
form_vars = get_header(RACK_INPUT).read
```

Since `read` is called with no argument, the entire request body is loaded into a Ruby `String`. This occurs before query parameter parsing or enforcement of any `params_limit`. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.

## Impact

Attackers can send large `application/x-www-form-urlencoded` bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs *before* those limits are enforced.

## Mitigation

* Update to a patched version of Rack that enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies.
* Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
GitHub Security Advisory: GHSA-6xw4-3v39-52mm
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 3.0, < 3.1.18
Patched in: 3.1.18

Summary: Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

Details:
## Summary

`Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

## Details

When handling non-multipart form submissions, Rack’s request parser performs:

```ruby
form_vars = get_header(RACK_INPUT).read
```

Since `read` is called with no argument, the entire request body is loaded into a Ruby `String`. This occurs before query parameter parsing or enforcement of any `params_limit`. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.

## Impact

Attackers can send large `application/x-www-form-urlencoded` bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs *before* those limits are enforced.

## Mitigation

* Update to a patched version of Rack that enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies.
* Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
GitHub Security Advisory: GHSA-6xw4-3v39-52mm
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 2.2.20
Patched in: 2.2.20

Summary: Rack is vulnerable to a memory-exhaustion DoS through unbounded URL-encoded body parsing

Details:
## Summary

`Rack::Request#POST` reads the entire request body into memory for `Content-Type: application/x-www-form-urlencoded`, calling `rack.input.read(nil)` without enforcing a length or cap. Large request bodies can therefore be buffered completely into process memory before parsing, leading to denial of service (DoS) through memory exhaustion.

## Details

When handling non-multipart form submissions, Rack’s request parser performs:

```ruby
form_vars = get_header(RACK_INPUT).read
```

Since `read` is called with no argument, the entire request body is loaded into a Ruby `String`. This occurs before query parameter parsing or enforcement of any `params_limit`. As a result, Rack applications without an upstream body-size limit can experience unbounded memory allocation proportional to request size.

## Impact

Attackers can send large `application/x-www-form-urlencoded` bodies to consume process memory, causing slowdowns or termination by the operating system (OOM). The effect scales linearly with request size and concurrency. Even with parsing limits configured, the issue occurs *before* those limits are enforced.

## Mitigation

* Update to a patched version of Rack that enforces form parameter limits using `query_parser.bytesize_limit`, preventing unbounded reads of `application/x-www-form-urlencoded` bodies.
* Enforce strict maximum body size at the proxy or web server layer (e.g., Nginx `client_max_body_size`, Apache `LimitRequestBody`).
GitHub Security Advisory: GHSA-r657-rxjc-j557
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: >= 3.2, < 3.2.3
Patched in: 3.2.3

Summary: Rack has a Possible Information Disclosure Vulnerability

Details:
## Summary

A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

## Details

When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was **not subject to the proxy's access controls**.

An attacker could exploit this by:
1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.
2. Setting a crafted `x-accel-mapping` header.
3. Requesting a path that qualifies for proxy-based acceleration.

## Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

* The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx).
* The proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers.
* The application exposed an endpoint that returned a body responding to `.to_path`.

## Mitigation

* Upgrade to a fixed version of Rack which requires explicit configuration to enable `x-accel-redirect`:

  ```ruby
  use Rack::Sendfile, "x-accel-redirect"
  ```

* Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

  ```nginx
  proxy_set_header x-sendfile-type x-accel-redirect;
  proxy_set_header x-accel-mapping /var/www/=/files/;
  ```

* Or in Rails applications, disable sendfile completely:

  ```ruby
  config.action_dispatch.x_sendfile_header = nil
  ```
GitHub Security Advisory: GHSA-r657-rxjc-j557
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: >= 3.0, < 3.1.18
Patched in: 3.1.18

Summary: Rack has a Possible Information Disclosure Vulnerability

Details:
## Summary

A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

## Details

When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was **not subject to the proxy's access controls**.

An attacker could exploit this by:
1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.
2. Setting a crafted `x-accel-mapping` header.
3. Requesting a path that qualifies for proxy-based acceleration.

## Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

* The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx).
* The proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers.
* The application exposed an endpoint that returned a body responding to `.to_path`.

## Mitigation

* Upgrade to a fixed version of Rack which requires explicit configuration to enable `x-accel-redirect`:

  ```ruby
  use Rack::Sendfile, "x-accel-redirect"
  ```

* Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

  ```nginx
  proxy_set_header x-sendfile-type x-accel-redirect;
  proxy_set_header x-accel-mapping /var/www/=/files/;
  ```

* Or in Rails applications, disable sendfile completely:

  ```ruby
  config.action_dispatch.x_sendfile_header = nil
  ```
GitHub Security Advisory: GHSA-r657-rxjc-j557
Package: rack (RUBYGEMS)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-441: Unintended Proxy or Intermediary ('Confused Deputy'), CWE-913: Improper Control of Dynamically-Managed Code Resources
Vulnerable versions: < 2.2.20
Patched in: 2.2.20

Summary: Rack has a Possible Information Disclosure Vulnerability

Details:
## Summary

A possible information disclosure vulnerability existed in `Rack::Sendfile` when running behind a proxy that supports `x-sendfile` headers (such as Nginx). Specially crafted headers could cause `Rack::Sendfile` to miscommunicate with the proxy and trigger unintended internal requests, potentially bypassing proxy-level access restrictions.

## Details

When `Rack::Sendfile` received untrusted `x-sendfile-type` or `x-accel-mapping` headers from a client, it would interpret them as proxy configuration directives. This could cause the middleware to send a "redirect" response to the proxy, prompting it to reissue a new internal request that was **not subject to the proxy's access controls**.

An attacker could exploit this by:
1. Setting a crafted `x-sendfile-type: x-accel-redirect` header.
2. Setting a crafted `x-accel-mapping` header.
3. Requesting a path that qualifies for proxy-based acceleration.

## Impact

Attackers could bypass proxy-enforced restrictions and access internal endpoints intended to be protected (such as administrative pages). The vulnerability did not allow arbitrary file reads but could expose sensitive application routes.

This issue only affected systems meeting all of the following conditions:

* The application used `Rack::Sendfile` with a proxy that supports `x-accel-redirect` (e.g., Nginx).
* The proxy did **not** always set or remove the `x-sendfile-type` and `x-accel-mapping` headers.
* The application exposed an endpoint that returned a body responding to `.to_path`.

## Mitigation

* Upgrade to a fixed version of Rack which requires explicit configuration to enable `x-accel-redirect`:

  ```ruby
  use Rack::Sendfile, "x-accel-redirect"
  ```

* Alternatively, configure the proxy to always set or strip the headers (you should be doing this!):

  ```nginx
  proxy_set_header x-sendfile-type x-accel-redirect;
  proxy_set_header x-accel-mapping /var/www/=/files/;
  ```

* Or in Rails applications, disable sendfile completely:

  ```ruby
  config.action_dispatch.x_sendfile_header = nil
  ```
GitHub Security Advisory: GHSA-wpv5-97wm-hp9c
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 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-wpv5-97wm-hp9c
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 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`).