deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-h2jq-g4cq-5ppq
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-187: Partial String Comparison, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 3.2.0, < 3.2.6
Patched in: 3.2.6

Summary: Rack::Static prefix matching can expose unintended files under the static root

Details:
## Summary

`Rack::Static` determines whether a request should be served as a static file using a simple string prefix check. When configured with URL prefixes such as `"/css"`, it matches any request path that begins with that string, including unrelated paths such as `"/css-config.env"` or `"/css-backup.sql"`.

As a result, files under the static root whose names merely share the configured prefix may be served unintentionally, leading to information disclosure.

## Details

`Rack::Static#route_file` performs static-route matching using logic equivalent to:

```ruby
@urls.any? { |url| path.index(url) == 0 }
```

This checks only whether the request path starts with the configured prefix string. It does not require a path segment boundary after the prefix.

For example, with:

```ruby
use Rack::Static, urls: ["/css", "/js"], root: "public"
```

the following path is matched as intended:

```text
/css/style.css
```

but these paths are also matched:

```text
/css-config.env
/css-backup.sql
/csssecrets.yml
```

If such files exist under the configured static root, Rack forwards the request to the file server and serves them as static content.

This means a configuration intended to expose only directory trees such as `/css/...` and `/js/...` may also expose sibling files whose names begin with those same strings.

## Impact

An attacker can request files under the configured static root whose names share a configured URL prefix and obtain their contents.

In affected deployments, this may expose configuration files, secrets, backups, environment files, or other unintended static content located under the same root directory.

## Mitigation

* Update to a patched version of Rack that enforces a path boundary when matching configured static URL prefixes.
* Match only paths that are either exactly equal to the configured prefix or begin with `prefix + "/"`.
* Avoid placing sensitive files under the `Rack::Static` root directory.
* Prefer static URL mappings that cannot overlap with sensitive filenames.
GitHub Security Advisory: GHSA-h2jq-g4cq-5ppq
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-187: Partial String Comparison, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: >= 3.0.0.beta1, < 3.1.21
Patched in: 3.1.21

Summary: Rack::Static prefix matching can expose unintended files under the static root

Details:
## Summary

`Rack::Static` determines whether a request should be served as a static file using a simple string prefix check. When configured with URL prefixes such as `"/css"`, it matches any request path that begins with that string, including unrelated paths such as `"/css-config.env"` or `"/css-backup.sql"`.

As a result, files under the static root whose names merely share the configured prefix may be served unintentionally, leading to information disclosure.

## Details

`Rack::Static#route_file` performs static-route matching using logic equivalent to:

```ruby
@urls.any? { |url| path.index(url) == 0 }
```

This checks only whether the request path starts with the configured prefix string. It does not require a path segment boundary after the prefix.

For example, with:

```ruby
use Rack::Static, urls: ["/css", "/js"], root: "public"
```

the following path is matched as intended:

```text
/css/style.css
```

but these paths are also matched:

```text
/css-config.env
/css-backup.sql
/csssecrets.yml
```

If such files exist under the configured static root, Rack forwards the request to the file server and serves them as static content.

This means a configuration intended to expose only directory trees such as `/css/...` and `/js/...` may also expose sibling files whose names begin with those same strings.

## Impact

An attacker can request files under the configured static root whose names share a configured URL prefix and obtain their contents.

In affected deployments, this may expose configuration files, secrets, backups, environment files, or other unintended static content located under the same root directory.

## Mitigation

* Update to a patched version of Rack that enforces a path boundary when matching configured static URL prefixes.
* Match only paths that are either exactly equal to the configured prefix or begin with `prefix + "/"`.
* Avoid placing sensitive files under the `Rack::Static` root directory.
* Prefer static URL mappings that cannot overlap with sensitive filenames.
GitHub Security Advisory: GHSA-h2jq-g4cq-5ppq
Package: rack (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-187: Partial String Comparison, CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 2.2.23
Patched in: 2.2.23

Summary: Rack::Static prefix matching can expose unintended files under the static root

Details:
## Summary

`Rack::Static` determines whether a request should be served as a static file using a simple string prefix check. When configured with URL prefixes such as `"/css"`, it matches any request path that begins with that string, including unrelated paths such as `"/css-config.env"` or `"/css-backup.sql"`.

As a result, files under the static root whose names merely share the configured prefix may be served unintentionally, leading to information disclosure.

## Details

`Rack::Static#route_file` performs static-route matching using logic equivalent to:

```ruby
@urls.any? { |url| path.index(url) == 0 }
```

This checks only whether the request path starts with the configured prefix string. It does not require a path segment boundary after the prefix.

For example, with:

```ruby
use Rack::Static, urls: ["/css", "/js"], root: "public"
```

the following path is matched as intended:

```text
/css/style.css
```

but these paths are also matched:

```text
/css-config.env
/css-backup.sql
/csssecrets.yml
```

If such files exist under the configured static root, Rack forwards the request to the file server and serves them as static content.

This means a configuration intended to expose only directory trees such as `/css/...` and `/js/...` may also expose sibling files whose names begin with those same strings.

## Impact

An attacker can request files under the configured static root whose names share a configured URL prefix and obtain their contents.

In affected deployments, this may expose configuration files, secrets, backups, environment files, or other unintended static content located under the same root directory.

## Mitigation

* Update to a patched version of Rack that enforces a path boundary when matching configured static URL prefixes.
* Match only paths that are either exactly equal to the configured prefix or begin with `prefix + "/"`.
* Avoid placing sensitive files under the `Rack::Static` root directory.
* Prefer static URL mappings that cannot overlap with sensitive filenames.
GitHub Security Advisory: GHSA-53p3-c7vp-4mcc
Package: action_text-trix (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.1.18
Patched in: 2.1.18

Summary: Trix is vulnerable to XSS through JSON deserialization bypass in drag-and-drop (Level0InputController)

Details:
### Impact

The Trix editor, in versions prior to 2.1.18, is vulnerable to XSS when a crafted `application/x-trix-document` JSON payload is dropped into the editor in environments using the fallback Level0InputController (e.g., embedded WebViews lacking Input Events Level 2 support).

The `StringPiece.fromJSON` method trusted `href` attributes from the JSON payload without sanitization. An attacker could craft a draggable element containing a `javascript:` URI in the href attribute that, when dropped into a vulnerable editor, would bypass DOMPurify sanitization and inject executable JavaScript into the DOM.

Exploitation requires a specific environment (Level0InputController fallback) and social engineering (victim must drag and drop attacker-controlled content into the editor). Applications using server-side HTML sanitization (such as Rails' built-in sanitizer) are additionally protected, as the payload is neutralized on save.

### Patches

Update Recommendation: Users should upgrade to Trix editor version 2.1.18 or later.


### References

The XSS vulnerability was responsibly reported by Hackerone researcher [newbiefromcoma](https://hackerone.com/newbiefromcoma).
GitHub Security Advisory: GHSA-c4r5-fxqw-vh93
Package: ruby-lsp (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 0.26.9
Patched in: 0.26.9

Summary: Ruby LSP has arbitrary code execution through branch setting

Details:
**Summary**

The `rubyLsp.branch` VS Code workspace setting was interpolated without sanitization into a generated Gemfile, allowing arbitrary Ruby code execution when a user opens a project containing a malicious `.vscode/settings.json`.

Other editors that support workspace setting that get automatically applied upon opening the editor and trusting the workspace are also impacted since the server is the component that performs the interpolation.

**Details**

The `branch` CLI argument passed to the `ruby-lsp` server was interpolated in the generated `.ruby-lsp/Gemfile` without sanitization. Editors that allow defining settings saved at the workspace level (e.g.: `.vscode/settings.json`) that gets automatically applied open the possibility to craft a malicious repository that once opened and trusted in the editor would run arbitrary code.

**Impact**

Code execution with the privileges of the user who opens the malicious project. Ruby LSP assumes workspace code is trusted and so opening the editor on an untrusted workspace can lead to executing potentially dangerous code.

**Remediation**

The `rubyLsp.branch` setting has been removed entirely. VS Code extensions auto-update by default, so most users will receive the fix without action. Users who have disabled auto-updates should update to extension version >= 0.10.2.

The `branch` CLI flag was also entirely removed from the `ruby-lsp` gem. For users that don't add `ruby-lsp` to their Gemfiles, the server should auto-update. Users with the `ruby-lsp` in the Gemfile and locked to a specific version should update to >= 0.26.9.
GitHub Security Advisory: GHSA-2j22-pr5w-6gq8
Package: loofah (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-116: Improper Encoding or Escaping of Output
Vulnerable versions: = 2.25.0
Patched in: 2.25.1

Summary: Loofah has improper detection of disallowed URIs via `allowed_uri?`

Details:
## Summary

`Loofah::HTML5::Scrub.allowed_uri?` does not correctly reject `javascript:` URIs when the scheme is split by HTML entity-encoded control characters such as `&#13;` (carriage return), `&#10;` (line feed), or `&#9;` (tab).

## Details

The `allowed_uri?` method strips literal control characters before decoding HTML entities. Payloads like `java&#13;script:alert(1)` survive the control character strip, then `&#13;` is decoded to a carriage return, producing `java\rscript:alert(1)`.

Note that the Loofah sanitizer's default `sanitize()` path is **not affected** because Nokogiri decodes HTML entities during parsing before Loofah evaluates the URI protocol. This issue only affects direct callers of the `allowed_uri?` string-level helper when passing HTML-encoded strings.

## Impact

Applications that call `Loofah::HTML5::Scrub.allowed_uri?` to validate user-controlled URLs and then render approved URLs into `href` or other browser-interpreted URI attributes may be vulnerable to cross-site scripting (XSS).

This only affects Loofah `2.25.0`.

## Mitigation

Upgrade to Loofah >= `2.25.1`.

## Credit

Responsibly reported by HackOne user @smlee.
GitHub Security Advisory: GHSA-p9fm-f462-ggrg
Package: activestorage (RUBYGEMS)
Severity: LOW (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 7.2.3.1
Patched in: 7.2.3.1

Summary: Rails Active Storage has a possible DoS vulnerability in proxy mode via multi-range requests

Details:
### Impact
Active Storage's proxy controller does not limit the number of byte ranges in an HTTP Range header. A request with thousands of small ranges causes disproportionate CPU usage compared to a normal request for the same file, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [thwin_htet](https://hackerone.com/thwin_htet).
GitHub Security Advisory: GHSA-p9fm-f462-ggrg
Package: activestorage (RUBYGEMS)
Severity: LOW (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.0.0, < 8.0.4.1
Patched in: 8.0.4.1

Summary: Rails Active Storage has a possible DoS vulnerability in proxy mode via multi-range requests

Details:
### Impact
Active Storage's proxy controller does not limit the number of byte ranges in an HTTP Range header. A request with thousands of small ranges causes disproportionate CPU usage compared to a normal request for the same file, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [thwin_htet](https://hackerone.com/thwin_htet).
GitHub Security Advisory: GHSA-p9fm-f462-ggrg
Package: activestorage (RUBYGEMS)
Severity: LOW (CVSS 6.5)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.1.0, < 8.1.2.1
Patched in: 8.1.2.1

Summary: Rails Active Storage has a possible DoS vulnerability in proxy mode via multi-range requests

Details:
### Impact
Active Storage's proxy controller does not limit the number of byte ranges in an HTTP Range header. A request with thousands of small ranges causes disproportionate CPU usage compared to a normal request for the same file, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [thwin_htet](https://hackerone.com/thwin_htet).
GitHub Security Advisory: GHSA-pv9c-9mfh-hvxq
Package: icalendar (RUBYGEMS)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-93: Improper Neutralization of CRLF Sequences ('CRLF Injection')
Vulnerable versions: >= 2.0.0, < 2.12.2
Patched in: 2.12.2

Summary: iCalendar has ICS injection via unsanitized URI property values

Details:
### Summary
.ics serialization does not properly sanitize URI property values, enabling ICS injection through attacker-controlled input, adding arbitrary calendar lines to the output.

### Details
`Icalendar::Values::Uri` falls back to the raw input string when `URI.parse` fails and later serializes it with `value.to_s` without removing or escaping `\r` or `\n` characters. That value is embedded directly into the final ICS line by the normal serializer, so a payload containing CRLF can terminate the original property and create a new ICS property or component. (It looks like you can inject via url, source, image, organizer, attach, attendee, conference, tzurl because of this)

Relevant code:
- `lib/icalendar/values/uri.rb:16`

### PoC
Run the following with the library loaded:

```ruby
require "icalendar/value"
require "icalendar/values/uri"

v = Icalendar::Values::Uri.new("https://a.example/ok\r\nATTENDEE:mailto:evil@example.com")
puts v.to_ical(Icalendar::Values::Text)
```

output:

```text
;VALUE=URI:https://a.example/ok
ATTENDEE:mailto:evil@example.com
```

### Impact
Applications that generate `.ics` files from partially untrusted metadata are impacted. As a result, downstream calendar clients or importers may process attacker-supplied content as if it were legitimate event data, such as added attendees, modified URLs, alarms, or other calendar fields.

## Fix
Reject raw CR and LF characters in `URI`-typed values before serialization, or escape/encode them so they cannot terminate the current ICS content line.
GitHub Security Advisory: GHSA-73f9-jhhh-hr5m
Package: activestorage (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 7.2.3.1
Patched in: 7.2.3.1

Summary: Rails Active Storage has possible glob injection in its DiskService

Details:
### Impact
Active Storage's `DiskService#delete_prefixed` passes blob keys directly to `Dir.glob` without escaping glob metacharacters. If a blob key contains attacker-controlled input or custom-generated keys with glob metacharacters, it may be possible to delete unintended files from the storage directory.

### Releases
The fixed releases are available at the normal locations.
GitHub Security Advisory: GHSA-73f9-jhhh-hr5m
Package: activestorage (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: >= 8.0.0.beta1, < 8.0.4.1
Patched in: 8.0.4.1

Summary: Rails Active Storage has possible glob injection in its DiskService

Details:
### Impact
Active Storage's `DiskService#delete_prefixed` passes blob keys directly to `Dir.glob` without escaping glob metacharacters. If a blob key contains attacker-controlled input or custom-generated keys with glob metacharacters, it may be possible to delete unintended files from the storage directory.

### Releases
The fixed releases are available at the normal locations.
GitHub Security Advisory: GHSA-73f9-jhhh-hr5m
Package: activestorage (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: >= 8.1.0.beta1, < 8.1.2.1
Patched in: 8.1.2.1

Summary: Rails Active Storage has possible glob injection in its DiskService

Details:
### Impact
Active Storage's `DiskService#delete_prefixed` passes blob keys directly to `Dir.glob` without escaping glob metacharacters. If a blob key contains attacker-controlled input or custom-generated keys with glob metacharacters, it may be possible to delete unintended files from the storage directory.

### Releases
The fixed releases are available at the normal locations.
GitHub Security Advisory: GHSA-9xrj-h377-fr87
Package: activestorage (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 7.2.3.1
Patched in: 7.2.3.1

Summary: Rails Active Storage has possible Path Traversal in DiskService

Details:
### Impact
Active Storage's `DiskService#path_for` does not validate that the resolved filesystem path remains within the storage root directory. If a blob key containing path traversal sequences (e.g. `../`) is used, it could allow reading, writing, or deleting arbitrary files on the server. Blob keys are expected to be trusted strings, but some applications could be passing user input as keys and would be affected.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [ksw9722](https://hackerone.com/ksw9722).
GitHub Security Advisory: GHSA-9xrj-h377-fr87
Package: activestorage (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 8.0.0.beta1, < 8.0.4.1
Patched in: 8.0.4.1

Summary: Rails Active Storage has possible Path Traversal in DiskService

Details:
### Impact
Active Storage's `DiskService#path_for` does not validate that the resolved filesystem path remains within the storage root directory. If a blob key containing path traversal sequences (e.g. `../`) is used, it could allow reading, writing, or deleting arbitrary files on the server. Blob keys are expected to be trusted strings, but some applications could be passing user input as keys and would be affected.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [ksw9722](https://hackerone.com/ksw9722).
GitHub Security Advisory: GHSA-9xrj-h377-fr87
Package: activestorage (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: >= 8.1.0.beta1, < 8.1.2.1
Patched in: 8.1.2.1

Summary: Rails Active Storage has possible Path Traversal in DiskService

Details:
### Impact
Active Storage's `DiskService#path_for` does not validate that the resolved filesystem path remains within the storage root directory. If a blob key containing path traversal sequences (e.g. `../`) is used, it could allow reading, writing, or deleting arbitrary files on the server. Blob keys are expected to be trusted strings, but some applications could be passing user input as keys and would be affected.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [ksw9722](https://hackerone.com/ksw9722).
GitHub Security Advisory: GHSA-2j26-frm8-cmj9
Package: activesupport (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 7.2.3.1
Patched in: 7.2.3.1

Summary: Rails Active Support has a possible DoS vulnerability in its number helpers

Details:
### Impact
Active Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which when converted to a string could be expanded into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [manun](https://hackerone.com/manun).
GitHub Security Advisory: GHSA-2j26-frm8-cmj9
Package: activesupport (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.0.0.beta1, < 8.0.4.1
Patched in: 8.0.4.1

Summary: Rails Active Support has a possible DoS vulnerability in its number helpers

Details:
### Impact
Active Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which when converted to a string could be expanded into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [manun](https://hackerone.com/manun).
GitHub Security Advisory: GHSA-2j26-frm8-cmj9
Package: activesupport (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 8.1.0.beta1, < 8.1.2.1
Patched in: 8.1.2.1

Summary: Rails Active Support has a possible DoS vulnerability in its number helpers

Details:
### Impact
Active Support number helpers accept strings containing scientific notation (e.g. `1e10000`), which when converted to a string could be expanded into extremely large decimal representations. This can cause excessive memory allocation and CPU consumption when the expanded number is formatted, possibly resulting in a DoS vulnerability.

### Releases
The fixed releases are available at the normal locations.

### Credit
This issue was responsibly reported by Hackerone researcher [manun](https://hackerone.com/manun).