deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-q66h-m87m-j2q6
Package: bitcoinrb (RUBYGEMS)
Severity: LOW (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: < 1.12.0
Patched in: 1.12.0

Summary: Bitcoinrb Vulnerable to Command injection via RPC 

Details:
### Summary: Remote Code Execution
Unsafe handling of request parameters in the RPC HTTP server results in command injection

### Details
In lib/bitcoin/rpc/http_server.rb line 30-39, the JSON body of a POST request is parsed into `command` and `args` variables. These values are then passed to `send`, which is used to call an arbitrary class method. However, there is no validation that the provided `command` value is one of the expected RPC methods. 
This means that an attacker could supply a `command` value such as `system`, and then pass arbitrary system commands into the `args` parameter and achieve remote code execution. 

### PoC
1. Start the RPC server
2. Send a request to the RPC server as so:
 ```
curl -X POST http://127.0.0.1:18443 -H 'Content-Type: application/json' \
    -d '{"method":"eval","params":["File.write(\"/tmp/pwned\",\"owned\")"]}'
```
3. Check the /tmp folder on the machine where the RPC server is being run. If a folder /pwned now exists, the vulnerability is confirmed.
### Impact
This vulnerability would impact anyone running the RPC server. The impact is higher for those who are running it publicly exposed to the internet.

### Remediation                                                
                                                                                                                                                                                                                               
  **Mitigating Factors:**                                                                                                                                                                                                      
  - The RPC server is part of the experimental SPV node feature, which is not documented and has very few users.                                                                                                               
  - The SPV-related features may be removed in future releases.                                                                                                                                                                
                                                                                                                                                                                                                               
  **Resolution:**                                                                                                                                                                                                              
  - Added whitelist validation to allow only RPC methods defined in `RequestHandler`.                                                                                                                                          
  - Fixed in version 1.12.0.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.11.1
Patched in: 1.11.1

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.0.0.beta1, < 2.0.2
Patched in: 2.0.2

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.1.0, < 2.1.3
Patched in: 2.1.3

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.2.0, < 2.2.2
Patched in: 2.2.2

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.3.0, < 2.3.2
Patched in: 2.3.2

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-w67g-2h6v-vjgq
Package: phlex (RUBYGEMS)
Severity: HIGH (CVSS 7.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.4.0.beta1, < 2.4.1
Patched in: 2.4.1

Summary: Phlex XSS protection bypass via attribute splatting, dynamic tags, and href values

Details:
### Impact

During a security audit conducted with Claude Opus 4.6 and GPT-5.3-Codex, we identified three specific ways to bypass the XSS (cross-site-scripting) protection built into Phlex.

1. The first bypass could happen if user-provided attributes with string keys were splatted into HTML tag, e.g. `div(**user_attributes)`.
2. The second bypass could happen if user-provided tag names were passed to the `tag` method, e.g. `tag(some_tag_name_from_user)`.
3. The third bypass could happen if user’s links were passed to `href` attributes, e.g. `a(href: user_provided_link)`.

All three of these patterns are meant to be safe and all have now been patched.

### Patches

Phlex has patched all three issues and introduced new tests that run against Safari, Firefox and Chrome.

The patched versions are:

- [2.4.1](https://rubygems.org/gems/phlex/versions/2.4.1)
- [2.3.2](https://rubygems.org/gems/phlex/versions/2.3.2)
- [2.2.2](https://rubygems.org/gems/phlex/versions/2.2.2)
- [2.1.3](https://rubygems.org/gems/phlex/versions/2.1.3)
- [2.0.2](https://rubygems.org/gems/phlex/versions/2.0.3)
- [1.11.1](https://rubygems.org/gems/phlex/versions/1.11.1)

Phlex has also patched the [`main`](https://github.com/yippee-fun/phlex) branch in GitHub.

### Workarounds
If a project uses a secure CSP (content security policy) or if the application doesn’t use any of the above patterns, it is not at risk.
GitHub Security Advisory: GHSA-p6pv-q7rc-g4h9
Package: spree_storefront (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.3.0, < 5.3.2
Patched in: 5.3.2

Summary: Unauthenticated Spree Commerce users can view completed guest orders by Order ID

Details:
### Unauthenticated users can view completed guest orders by Order ID (`GHSL-2026-029`)

The `OrdersController#show` action permits viewing completed guest orders by order number alone, without requiring the associated order token.

Order lookup without enforcing token requirement in [`OrdersController#show`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L14):

```ruby
@order = complete_order_finder.new(number: params[:id], token: params[:token], store: current_store).execute.first
```

Authorization bypass for guest orders in [`authorize_access`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L51C1-L55C8):
```ruby
def authorize_access
  return true if @order.user_id.nil?

  @order.user == try_spree_current_user
end
```

If the attacker is in possession of a leaked Order ID, they might look it up directly via this API.
Alternatively, brute forcing all or parts of the possible Order IDs might be feasible for an attacker. (The Order IDs themselves are [securely generated](https://github.com/spree/spree/blob/a878eb4a782ce0445d218ea86fb12075b0e3d7cc/core/lib/spree/core/number_generator.rb#L45), but with relatively low entropy: by default an order ID has a length of 9 and a base of 10, that would require an attacker to perform 1 billion requests to gather all guest orders. (At an assumed constant rate of 100 requests per second it would take 115 days.)


#### Proof of Concept

1. As a guest create a complete order.
2. Fetch the latest Order ID from the database (Table: `spree_orders`).
3. In another clean browser access following URL: `<SPREE-HOST>/orders/<ORDER-ID>`. (Sample: `http://localhost:3000/orders/R496592563`)

=> Full guest order details are disclosed including names, addresses and limited payment info.

#### Impact

This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers).

#### CWEs

- CWE-639: Authorization Bypass Through User-Controlled Key

### Credit

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).

### Disclosure Policy

This report is subject to a 90-day disclosure deadline, as described in more detail in our [coordinated disclosure policy](https://securitylab.github.com/advisories#policy).
GitHub Security Advisory: GHSA-p6pv-q7rc-g4h9
Package: spree_storefront (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.2.0, < 5.2.7
Patched in: 5.2.7

Summary: Unauthenticated Spree Commerce users can view completed guest orders by Order ID

Details:
### Unauthenticated users can view completed guest orders by Order ID (`GHSL-2026-029`)

The `OrdersController#show` action permits viewing completed guest orders by order number alone, without requiring the associated order token.

Order lookup without enforcing token requirement in [`OrdersController#show`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L14):

```ruby
@order = complete_order_finder.new(number: params[:id], token: params[:token], store: current_store).execute.first
```

Authorization bypass for guest orders in [`authorize_access`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L51C1-L55C8):
```ruby
def authorize_access
  return true if @order.user_id.nil?

  @order.user == try_spree_current_user
end
```

If the attacker is in possession of a leaked Order ID, they might look it up directly via this API.
Alternatively, brute forcing all or parts of the possible Order IDs might be feasible for an attacker. (The Order IDs themselves are [securely generated](https://github.com/spree/spree/blob/a878eb4a782ce0445d218ea86fb12075b0e3d7cc/core/lib/spree/core/number_generator.rb#L45), but with relatively low entropy: by default an order ID has a length of 9 and a base of 10, that would require an attacker to perform 1 billion requests to gather all guest orders. (At an assumed constant rate of 100 requests per second it would take 115 days.)


#### Proof of Concept

1. As a guest create a complete order.
2. Fetch the latest Order ID from the database (Table: `spree_orders`).
3. In another clean browser access following URL: `<SPREE-HOST>/orders/<ORDER-ID>`. (Sample: `http://localhost:3000/orders/R496592563`)

=> Full guest order details are disclosed including names, addresses and limited payment info.

#### Impact

This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers).

#### CWEs

- CWE-639: Authorization Bypass Through User-Controlled Key

### Credit

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).

### Disclosure Policy

This report is subject to a 90-day disclosure deadline, as described in more detail in our [coordinated disclosure policy](https://securitylab.github.com/advisories#policy).
GitHub Security Advisory: GHSA-p6pv-q7rc-g4h9
Package: spree_storefront (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.1.0, < 5.1.10
Patched in: 5.1.10

Summary: Unauthenticated Spree Commerce users can view completed guest orders by Order ID

Details:
### Unauthenticated users can view completed guest orders by Order ID (`GHSL-2026-029`)

The `OrdersController#show` action permits viewing completed guest orders by order number alone, without requiring the associated order token.

Order lookup without enforcing token requirement in [`OrdersController#show`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L14):

```ruby
@order = complete_order_finder.new(number: params[:id], token: params[:token], store: current_store).execute.first
```

Authorization bypass for guest orders in [`authorize_access`](https://github.com/spree/spree/blob/1341623f2ae92685cdbe232885bf5808fc8f9ca8/storefront/app/controllers/spree/orders_controller.rb#L51C1-L55C8):
```ruby
def authorize_access
  return true if @order.user_id.nil?

  @order.user == try_spree_current_user
end
```

If the attacker is in possession of a leaked Order ID, they might look it up directly via this API.
Alternatively, brute forcing all or parts of the possible Order IDs might be feasible for an attacker. (The Order IDs themselves are [securely generated](https://github.com/spree/spree/blob/a878eb4a782ce0445d218ea86fb12075b0e3d7cc/core/lib/spree/core/number_generator.rb#L45), but with relatively low entropy: by default an order ID has a length of 9 and a base of 10, that would require an attacker to perform 1 billion requests to gather all guest orders. (At an assumed constant rate of 100 requests per second it would take 115 days.)


#### Proof of Concept

1. As a guest create a complete order.
2. Fetch the latest Order ID from the database (Table: `spree_orders`).
3. In another clean browser access following URL: `<SPREE-HOST>/orders/<ORDER-ID>`. (Sample: `http://localhost:3000/orders/R496592563`)

=> Full guest order details are disclosed including names, addresses and limited payment info.

#### Impact

This issue may lead to disclosure of PII of guest users (including names, addresses and phone numbers).

#### CWEs

- CWE-639: Authorization Bypass Through User-Controlled Key

### Credit

This issue was discovered with the [GitHub Security Lab Taskflow Agent](https://github.com/GitHubSecurityLab/seclab-taskflow-agent) and manually verified by GHSL team members [@p- (Peter Stöckli)](https://github.com/p-) and [@m-y-mo (Man Yue Mo)](https://github.com/m-y-mo).

### Disclosure Policy

This report is subject to a 90-day disclosure deadline, as described in more detail in our [coordinated disclosure policy](https://securitylab.github.com/advisories#policy).