deardaniel/secdata-raw huggingface dataset:
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.0.8
Patched in: 5.0.8

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-2qxw-7fmx-gqfm
Package: foreman_kubevirt (RUBYGEMS)
Severity: HIGH (CVSS 8.1)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 0.4.3
Patched in: 0.4.3

Summary: foreman_kubevirt disables SSL verification if a Certificate Authority (CA) certificate is not explicitly set

Details:
A flaw was found in foreman_kubevirt. When configuring the connection to OpenShift, the system disables SSL verification if a Certificate Authority (CA) certificate is not explicitly set. This insecure default allows a remote attacker, capable of intercepting network traffic between Satellite and OpenShift, to perform a Man-in-the-Middle (MITM) attack. Such an attack could lead to the disclosure or alteration of sensitive information.
GitHub Security Advisory: GHSA-m3hq-3qj8-c5fm
Package: fog-kubevirt (RUBYGEMS)
Severity: HIGH (CVSS 8.1)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: < 1.5.1
Patched in: 1.5.1

Summary: fog-kubevirt allows remote attacker to perform MITM attack due to disabled certificate validation

Details:
A flaw was found in fog-kubevirt. This vulnerability allows a remote attacker to perform a Man-in-the-Middle (MITM) attack due to disabled certificate validation. This enables the attacker to intercept and potentially alter sensitive communications between Satellite and OpenShift, resulting in information disclosure and data integrity compromise.
GitHub Security Advisory: GHSA-f57c-hx33-hvh8
Package: activerecord (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-20: Improper Input Validation, CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 4.2.0
Patched in: 4.2.0

Summary: Active Record component in Ruby on Rails has a data-type injection vulnerability

Details:
The Active Record component in Ruby on Rails 2.3.x, 3.0.x, 3.1.x, and 3.2.x does not ensure that the declared data type of a database column is used during comparisons of input values to stored values in that column, which makes it easier for remote attackers to conduct data-type injection attacks against Ruby on Rails applications via a crafted value, as demonstrated by unintended interaction between the "typed XML" feature and a MySQL database.
GitHub Security Advisory: GHSA-72qj-48g4-5xgx
Package: jruby-openssl (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-295: Improper Certificate Validation, CWE-297: Improper Validation of Certificate with Host Mismatch
Vulnerable versions: >= 0.12.1, < 0.15.4
Patched in: 0.15.4

Summary: JRuby-OpenSSL has hostname verification disabled by default

Details:
### Summary
When verifying SSL certificates, jruby-openssl is not verifying that the hostname presented in the certificate matches the one we are trying to connect to, meaning a MITM could just present _any_ valid cert for a completely different domain they own, and JRuby wouldn't complain. 

### Details
n/a

### PoC
An example domain bad.substitutealert.com was created to present the a certificate for the domain s8a.me. The following script run in IRB in CRuby 3.4.3 will fail with `certificate verify failed (hostname mismatch)`, but will work just fine in JRuby 10.0.0.0 and JRuby 9.4.2.0, both of which use jruby-openssl version 0.15.3

```ruby
require "net/http"
require "openssl"

uri   = URI("https://bad.substitutealert.com/")
https = Net::HTTP.new(uri.host, uri.port)
https.use_ssl      = true
https.verify_mode  = OpenSSL::SSL::VERIFY_PEER

body = https.start { https.get(uri.request_uri).body }
puts body
```

### Impact
Anybody using JRuby to make requests of external APIs, or scraping the web, that depends on https to connect securely
GitHub Security Advisory: GHSA-2762-657x-v979
Package: alchemy_cms (RUBYGEMS)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: >= 8.0.0.a, < 8.0.3
Patched in: 8.0.3

Summary: AlchemyCMS: Authenticated Remote Code Execution (RCE) via eval injection in ResourcesHelper

Details:
### Summary
A vulnerability was discovered during a manual security audit of the AlchemyCMS source code. The application uses the Ruby `eval()` function to dynamically execute a string provided by the `resource_handler.engine_name` attribute in `Alchemy::ResourcesHelper#resource_url_proxy`.

### Details
The vulnerability exists in `app/helpers/alchemy/resources_helper.rb` at line 28. The code explicitly bypasses security linting with `# rubocop:disable Security/Eval`, indicating that the use of a dangerous function was known but not properly mitigated. 

Since `engine_name` is sourced from module definitions that can be influenced by administrative configurations, it allows an authenticated attacker to escape the Ruby sandbox and execute arbitrary system commands on the host OS.

But, for this attack to be possible local file access to the alchemy project or the source on a remote server is necessary in order to manipulate the module config file, though.

### PoC (Proof of Concept)
The following standalone Ruby script demonstrates that the `eval` sink is directly exploitable:

```ruby
require 'ostruct'

def resource_url_proxy(resource_handler)
  if resource_handler.engine_name && !resource_handler.engine_name.empty?
    eval(resource_handler.engine_name)
  end
end

# Payload to create a file in /tmp directory
payload = "system('touch /tmp/alchemy_rce_verified'); 'main_app'"
handler = OpenStruct.new(engine_name: payload)

resource_url_proxy(handler)

if File.exist?('/tmp/alchemy_rce_verified')
  puts "RCE Verified: Command executed successfully."
end
```


<img width="1909" height="885" alt="Screenshot From 2026-01-17 15-49-01" src="https://github.com/user-attachments/assets/07929d46-c839-4d3c-9b74-916bd87819ad" />
GitHub Security Advisory: GHSA-2762-657x-v979
Package: alchemy_cms (RUBYGEMS)
Severity: MODERATE (CVSS 6.4)
CWE: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: < 7.4.12
Patched in: 7.4.12

Summary: AlchemyCMS: Authenticated Remote Code Execution (RCE) via eval injection in ResourcesHelper

Details:
### Summary
A vulnerability was discovered during a manual security audit of the AlchemyCMS source code. The application uses the Ruby `eval()` function to dynamically execute a string provided by the `resource_handler.engine_name` attribute in `Alchemy::ResourcesHelper#resource_url_proxy`.

### Details
The vulnerability exists in `app/helpers/alchemy/resources_helper.rb` at line 28. The code explicitly bypasses security linting with `# rubocop:disable Security/Eval`, indicating that the use of a dangerous function was known but not properly mitigated. 

Since `engine_name` is sourced from module definitions that can be influenced by administrative configurations, it allows an authenticated attacker to escape the Ruby sandbox and execute arbitrary system commands on the host OS.

But, for this attack to be possible local file access to the alchemy project or the source on a remote server is necessary in order to manipulate the module config file, though.

### PoC (Proof of Concept)
The following standalone Ruby script demonstrates that the `eval` sink is directly exploitable:

```ruby
require 'ostruct'

def resource_url_proxy(resource_handler)
  if resource_handler.engine_name && !resource_handler.engine_name.empty?
    eval(resource_handler.engine_name)
  end
end

# Payload to create a file in /tmp directory
payload = "system('touch /tmp/alchemy_rce_verified'); 'main_app'"
handler = OpenStruct.new(engine_name: payload)

resource_url_proxy(handler)

if File.exist?('/tmp/alchemy_rce_verified')
  puts "RCE Verified: Command executed successfully."
end
```


<img width="1909" height="885" alt="Screenshot From 2026-01-17 15-49-01" src="https://github.com/user-attachments/assets/07929d46-c839-4d3c-9b74-916bd87819ad" />
GitHub Security Advisory: GHSA-5xq9-h3j2-jxvc
Package: rollout-ui (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 0.5.3
Patched in: 0.5.3

Summary: Cross Site Scripting (XSS) Vulnerability in Fetlife rollout-ui gem

Details:
Cross Site Scripting (XSS) Vulnerability in Fetlife rollout-ui version 0.5, allows attackers to execute arbitrary code via a crafted url to the delete a feature functionality.
GitHub Security Advisory: GHSA-mpwp-4h2m-765c
Package: activejob (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 4.2.0.beta2
Patched in: 4.2.0.beta2

Summary: Active Job - Object injection security vulnerability

Details:
Active Job vulnerability: An Active Job bug allowed String arguments to be deserialized as if they were Global IDs, an object injection security vulnerability.
GitHub Security Advisory: GHSA-5qw5-wf2q-f538
Package: activerecord-jdbc-adapter (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: < 1.2.8
Patched in: 1.2.8

Summary: ActiveRecord-JDBC-Adapter (AR-JDBC) lib/arjdbc/jdbc/adapter.rb sql.gsub() Function SQL Injection

Details:
ActiveRecord-JDBC-Adapter (AR-JDBC) contains a flaw that may allow carrying out an SQL injection attack. The issue is due to the sql.gsub() function in lib/arjdbc/jdbc/adapter.rb not properly sanitizing user-supplied input before using it in SQL queries. This may allow a remote attacker to inject or manipulate SQL queries in the back-end database, allowing for the manipulation or disclosure of arbitrary data.
GitHub Security Advisory: GHSA-97vm-c39p-jr86
Package: spree (RUBYGEMS)
Severity: CRITICAL (CVSS 9.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection'), CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution')
Vulnerable versions: < 0.60.2
Patched in: 0.60.2

Summary: Spree has Remote Command Execution vulnerability in search functionality

Details:
Spreecommerce versions prior to 0.60.2 contains a remote command execution vulnerability in its search functionality. The application fails to properly sanitize input passed via the search[send][] parameter, which is dynamically invoked using Ruby’s send method. This allows attackers to execute arbitrary shell commands on the server without authentication.
GitHub Security Advisory: GHSA-w757-4qv9-mghp
Package: openc3 (RUBYGEMS)
Severity: CRITICAL (CVSS 10.0)
CWE: CWE-95: Improper Neutralization of Directives in Dynamically Evaluated Code ('Eval Injection')
Vulnerable versions: >= 5.0.6, < 6.10.2
Patched in: 6.10.2

Summary: openc3-api Vulnerable to Unauthenticated Remote Code Execution

Details:
### Summary
OpenC3 COSMOS contains a critical remote code execution vulnerability reachable through the JSON-RPC API. When a JSON-RPC request uses the string form of certain APIs, attacker-controlled parameter text is parsed into values using String#convert_to_value. For array-like inputs, convert_to_value executes eval().

Because the cmd code path parses the command string before calling authorize(), an unauthenticated attacker can trigger Ruby code execution even though the request ultimately fails authorization (401).
GitHub Security Advisory: GHSA-3ghg-3787-w2xr
Package: spree_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.2.0, < 5.2.5
Patched in: 5.2.5

Summary: Spree API has Unauthenticated IDOR - Guest Address

Details:
### Summary
An Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an unauthenticated attacker to access guest address information without supplying valid credentials or session cookies.

### Details
During testing, it was observed that all guest users can make an unauthenticated request to retrieve address data belonging to other guest users by manipulating object identifiers. The attacker would need to know the storefront URL structure to perform this attack (which can be learnt after creating a registered user account).

Affected Component(s)
* Address Edit endpoint: `/addresses/{addressId}/edit`

Root Cause
- Faulty authorization check in CanCanCan Ability class:

```diff
- can :manage, ::Spree::Address, user_id: user.id
+ can :manage, ::Spree::Address, user_id: user.id if user.persisted?
```

the `user` object in `Spree::Ability` class for guest users is a `Spree.user_class.new` object. 

Addresses endpoint to access it is part of the `spree_storefront` gem. **Headless builds using APIs are not affected,** as the Addresses endpoint there is only for registered users, and records are scoped to the currently signed-in user.

### PoC
Preconditions
- No authentication required
- No cookies or session tokens set

To reproduce this vulnerability simply perform the request shown below, replacing the number with an arbitrary value. 

**For the initial request the Guest Address id = 6 is used to obtain the information**

**Request**
GET `/addresses/6/edit`

<img width="291" height="454" alt="IDOR Guest" src="https://github.com/user-attachments/assets/d21d01a2-8fa5-4ab1-b9e2-6ee65bd6b5a2" />

Repeat the request and check the response, in this example using Guest Address id = 2.

**Request**
GET `/addresses/2/edit`

[<img width="360" height="519" alt="IDOR Guest Address ID 2" src="https://github.com/user-attachments/assets/1ce35990-3d11-4f47-9bba-266b5361313c" />
](url)

### Impact
An unauthenticated attacker can:

- Enumerate and retrieve guest address information (Addresses associated with User accounts are NOT affected)
- Access personally identifiable information (PII) such as:
- Full names
- Physical addresses
- Phone numbers (if present)

This vulnerability could lead to:

- Privacy violations
- Regulatory compliance issues (e.g., GDPR)
- Loss of user trust
GitHub Security Advisory: GHSA-3ghg-3787-w2xr
Package: spree_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.1.0, < 5.1.9
Patched in: 5.1.9

Summary: Spree API has Unauthenticated IDOR - Guest Address

Details:
### Summary
An Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an unauthenticated attacker to access guest address information without supplying valid credentials or session cookies.

### Details
During testing, it was observed that all guest users can make an unauthenticated request to retrieve address data belonging to other guest users by manipulating object identifiers. The attacker would need to know the storefront URL structure to perform this attack (which can be learnt after creating a registered user account).

Affected Component(s)
* Address Edit endpoint: `/addresses/{addressId}/edit`

Root Cause
- Faulty authorization check in CanCanCan Ability class:

```diff
- can :manage, ::Spree::Address, user_id: user.id
+ can :manage, ::Spree::Address, user_id: user.id if user.persisted?
```

the `user` object in `Spree::Ability` class for guest users is a `Spree.user_class.new` object. 

Addresses endpoint to access it is part of the `spree_storefront` gem. **Headless builds using APIs are not affected,** as the Addresses endpoint there is only for registered users, and records are scoped to the currently signed-in user.

### PoC
Preconditions
- No authentication required
- No cookies or session tokens set

To reproduce this vulnerability simply perform the request shown below, replacing the number with an arbitrary value. 

**For the initial request the Guest Address id = 6 is used to obtain the information**

**Request**
GET `/addresses/6/edit`

<img width="291" height="454" alt="IDOR Guest" src="https://github.com/user-attachments/assets/d21d01a2-8fa5-4ab1-b9e2-6ee65bd6b5a2" />

Repeat the request and check the response, in this example using Guest Address id = 2.

**Request**
GET `/addresses/2/edit`

[<img width="360" height="519" alt="IDOR Guest Address ID 2" src="https://github.com/user-attachments/assets/1ce35990-3d11-4f47-9bba-266b5361313c" />
](url)

### Impact
An unauthenticated attacker can:

- Enumerate and retrieve guest address information (Addresses associated with User accounts are NOT affected)
- Access personally identifiable information (PII) such as:
- Full names
- Physical addresses
- Phone numbers (if present)

This vulnerability could lead to:

- Privacy violations
- Regulatory compliance issues (e.g., GDPR)
- Loss of user trust
GitHub Security Advisory: GHSA-3ghg-3787-w2xr
Package: spree_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-639: Authorization Bypass Through User-Controlled Key
Vulnerable versions: >= 5.0.0, < 5.0.7
Patched in: 5.0.7

Summary: Spree API has Unauthenticated IDOR - Guest Address

Details:
### Summary
An Unauthenticated Insecure Direct Object Reference (IDOR) vulnerability was identified that allows an unauthenticated attacker to access guest address information without supplying valid credentials or session cookies.

### Details
During testing, it was observed that all guest users can make an unauthenticated request to retrieve address data belonging to other guest users by manipulating object identifiers. The attacker would need to know the storefront URL structure to perform this attack (which can be learnt after creating a registered user account).

Affected Component(s)
* Address Edit endpoint: `/addresses/{addressId}/edit`

Root Cause
- Faulty authorization check in CanCanCan Ability class:

```diff
- can :manage, ::Spree::Address, user_id: user.id
+ can :manage, ::Spree::Address, user_id: user.id if user.persisted?
```

the `user` object in `Spree::Ability` class for guest users is a `Spree.user_class.new` object. 

Addresses endpoint to access it is part of the `spree_storefront` gem. **Headless builds using APIs are not affected,** as the Addresses endpoint there is only for registered users, and records are scoped to the currently signed-in user.

### PoC
Preconditions
- No authentication required
- No cookies or session tokens set

To reproduce this vulnerability simply perform the request shown below, replacing the number with an arbitrary value. 

**For the initial request the Guest Address id = 6 is used to obtain the information**

**Request**
GET `/addresses/6/edit`

<img width="291" height="454" alt="IDOR Guest" src="https://github.com/user-attachments/assets/d21d01a2-8fa5-4ab1-b9e2-6ee65bd6b5a2" />

Repeat the request and check the response, in this example using Guest Address id = 2.

**Request**
GET `/addresses/2/edit`

[<img width="360" height="519" alt="IDOR Guest Address ID 2" src="https://github.com/user-attachments/assets/1ce35990-3d11-4f47-9bba-266b5361313c" />
](url)

### Impact
An unauthenticated attacker can:

- Enumerate and retrieve guest address information (Addresses associated with User accounts are NOT affected)
- Access personally identifiable information (PII) such as:
- Full names
- Physical addresses
- Phone numbers (if present)

This vulnerability could lead to:

- Privacy violations
- Regulatory compliance issues (e.g., GDPR)
- Loss of user trust