deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-rmj8-8hhh-gv5h
Package: puma (RUBYGEMS)
Severity: HIGH (CVSS 8.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: < 4.3.11
Patched in: 4.3.11

Summary: Puma used with Rails may lead to Information Exposure

Details:
### Impact
Prior to `puma` version `5.6.2`, `puma` may not always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body being closed in order for its `CurrentAttributes` implementation to work correctly.

From Rails:

> Under certain circumstances response bodies will not be closed, for example a bug in a webserver[1] or a bug in a Rack middleware. In the event a response is not notified of a close, ActionDispatch::Executor will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests, especially when interacting with ActiveSupport::CurrentAttributes.

The combination of these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information leakage.

### Patches
This problem is fixed in Puma versions 5.6.2 and 4.3.11.

This problem is fixed in Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

See: 
https://github.com/advisories/GHSA-wh98-p28r-vrc9 
for details about the rails vulnerability

Upgrading to a patched Rails _or_ Puma version fixes the vulnerability.

### Workarounds

Upgrade to Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

The [Rails CVE](https://groups.google.com/g/ruby-security-ann/c/FkTM-_7zSNA/m/K2RiMJBlBAAJ?utm_medium=email&utm_source=footer&pli=1) includes a middleware that can be used instead.

### References

* Rails CVE: [CVE-2022-23633](https://groups.google.com/g/ruby-security-ann/c/FkTM-_7zSNA/m/K2RiMJBlBAAJ?utm_medium=email&utm_source=footer&pli=1)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [puma](https://github.com/puma/puma)
* See our [security policy](https://github.com/puma/puma/security/policy)
GitHub Security Advisory: GHSA-rmj8-8hhh-gv5h
Package: puma (RUBYGEMS)
Severity: HIGH (CVSS 8.0)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-404: Improper Resource Shutdown or Release
Vulnerable versions: >= 5.0.0, < 5.6.2
Patched in: 5.6.2

Summary: Puma used with Rails may lead to Information Exposure

Details:
### Impact
Prior to `puma` version `5.6.2`, `puma` may not always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body being closed in order for its `CurrentAttributes` implementation to work correctly.

From Rails:

> Under certain circumstances response bodies will not be closed, for example a bug in a webserver[1] or a bug in a Rack middleware. In the event a response is not notified of a close, ActionDispatch::Executor will not know to reset thread local state for the next request. This can lead to data being leaked to subsequent requests, especially when interacting with ActiveSupport::CurrentAttributes.

The combination of these two behaviors (Puma not closing the body + Rails' Executor implementation) causes information leakage.

### Patches
This problem is fixed in Puma versions 5.6.2 and 4.3.11.

This problem is fixed in Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

See: 
https://github.com/advisories/GHSA-wh98-p28r-vrc9 
for details about the rails vulnerability

Upgrading to a patched Rails _or_ Puma version fixes the vulnerability.

### Workarounds

Upgrade to Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

The [Rails CVE](https://groups.google.com/g/ruby-security-ann/c/FkTM-_7zSNA/m/K2RiMJBlBAAJ?utm_medium=email&utm_source=footer&pli=1) includes a middleware that can be used instead.

### References

* Rails CVE: [CVE-2022-23633](https://groups.google.com/g/ruby-security-ann/c/FkTM-_7zSNA/m/K2RiMJBlBAAJ?utm_medium=email&utm_source=footer&pli=1)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [puma](https://github.com/puma/puma)
* See our [security policy](https://github.com/puma/puma/security/policy)
GitHub Security Advisory: GHSA-wh98-p28r-vrc9
Package: actionpack (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 7.0.0.0, <= 7.0.2.1
Patched in: 7.0.2.2

Summary: Exposure of information in Action Pack

Details:
### Impact

Under certain circumstances response bodies will not be closed, for example a [bug in a webserver](https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware.  In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request.  This can lead to data being leaked to subsequent requests, especially when interacting with `ActiveSupport::CurrentAttributes`.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

### Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

### Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

```ruby
class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
```
GitHub Security Advisory: GHSA-wh98-p28r-vrc9
Package: actionpack (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 6.1.0.0, <= 6.1.4.5
Patched in: 6.1.4.6

Summary: Exposure of information in Action Pack

Details:
### Impact

Under certain circumstances response bodies will not be closed, for example a [bug in a webserver](https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware.  In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request.  This can lead to data being leaked to subsequent requests, especially when interacting with `ActiveSupport::CurrentAttributes`.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

### Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

### Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

```ruby
class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
```
GitHub Security Advisory: GHSA-wh98-p28r-vrc9
Package: actionpack (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 6.0.0.0, <= 6.0.4.5
Patched in: 6.0.4.6

Summary: Exposure of information in Action Pack

Details:
### Impact

Under certain circumstances response bodies will not be closed, for example a [bug in a webserver](https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware.  In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request.  This can lead to data being leaked to subsequent requests, especially when interacting with `ActiveSupport::CurrentAttributes`.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

### Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

### Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

```ruby
class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
```
GitHub Security Advisory: GHSA-wh98-p28r-vrc9
Package: actionpack (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-212: Improper Removal of Sensitive Information Before Storage or Transfer
Vulnerable versions: >= 5.0.0.0, <= 5.2.6.1
Patched in: 5.2.6.2

Summary: Exposure of information in Action Pack

Details:
### Impact

Under certain circumstances response bodies will not be closed, for example a [bug in a webserver](https://github.com/puma/puma/pull/2812) or a bug in a Rack middleware.  In the event a response is *not* notified of a `close`, `ActionDispatch::Executor` will not know to reset thread local state for the next request.  This can lead to data being leaked to subsequent requests, especially when interacting with `ActiveSupport::CurrentAttributes`.

Upgrading to the FIXED versions of Rails will ensure mitigation of this issue even in the context of a buggy webserver or middleware implementation.

### Patches

This has been fixed in Rails 7.0.2.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2.

### Workarounds

Upgrading is highly recommended, but to work around this problem the following middleware can be used:

```ruby
class GuardedExecutor < ActionDispatch::Executor
  def call(env)
    ensure_completed!
    super
  end

  private

    def ensure_completed!
      @executor.new.complete! if @executor.active?
    end
end

# Ensure the guard is inserted before ActionDispatch::Executor
Rails.application.configure do
  config.middleware.swap ActionDispatch::Executor, GuardedExecutor, executor
end
```
GitHub Security Advisory: GHSA-wrvw-hg22-4m67
Package: google-protobuf (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-696: Incorrect Behavior Order
Vulnerable versions: < 3.19.2
Patched in: 3.19.2

Summary: A potential Denial of Service issue in protobuf-java

Details:
## Summary

A potential Denial of Service issue in protobuf-java was discovered in the parsing procedure for binary data.

Reporter: [OSS-Fuzz](https://github.com/google/oss-fuzz)

Affected versions: All versions of Java Protobufs (including Kotlin and JRuby) prior to the versions listed below. Protobuf "javalite" users (typically Android) are not affected.

## Severity

[CVE-2021-22569](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-22569) **High** - CVSS Score: 7.5,  An implementation weakness in how unknown fields are parsed in Java. A small (~800 KB) malicious payload can occupy the parser for several minutes by creating large numbers of short-lived objects that cause frequent, repeated GC pauses.

## Proof of Concept

For reproduction details, please refer to the oss-fuzz issue that identifies the specific inputs that exercise this parsing weakness.

## Remediation and Mitigation

Please update to the latest available versions of the following packages:

- protobuf-java (3.16.1, 3.18.2, 3.19.2) 
- protobuf-kotlin (3.18.2, 3.19.2)
- google-protobuf [JRuby  gem only] (3.19.2)
GitHub Security Advisory: GHSA-xmgj-5fh3-xjmm
Package: message_bus (RUBYGEMS)
Severity: MODERATE (CVSS 4.2)
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')
Vulnerable versions: < 3.3.7
Patched in: 3.3.7

Summary: Path traversal when MessageBus::Diagnostics is enabled

Details:
### Impact

Users who deployed message bus with diagnostics features enabled (default off) were vulnerable to a path traversal bug, which could lead to disclosure of secret information on a machine if an unintended user were to gain access to the diagnostic route. The impact is also greater if there is no proxy for your web application as the number of steps up the directories is not bounded. For deployments which uses a proxy, the impact varies. For example, If a request goes through a proxy like Nginx with `merge_slashes` enabled, the number of steps up the directories that can be read is limited to 3 levels. 

### Patches

Patched in 3.3.7.

### Workarounds

Disable MessageBus::Diagnostics in production like environments.
GitHub Security Advisory: GHSA-qxmr-qxh6-2cc9
Package: solidus_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.1.0, < 3.1.4
Patched in: 3.1.4

Summary: ReDos vulnerability on guest checkout email validation

Details:
### Impact
Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like `a.a.`.

Before the patch, it can be reproduced in the console like this:

```ruby
irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil
```

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the `type` attribute for that field from `email` to `text`. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.


### Patches
Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

```bash
bin/rails solidus:check_orders_with_invalid_email
```

The above will print information for every affected order if any.

### Workarounds

If a prompt upgrade is not an option, please, add the following to `config/application.rb`:

```ruby
config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end
```

### References

- https://en.wikipedia.org/wiki/ReDoS
- https://snyk.io/blog/redos-and-catastrophic-backtracking/

### For more information
If you have any questions or comments about this advisory:
* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.
* Email us at [security@solidus.io](mailto:security@soliidus.io)
* Contact the core team on [Slack](http://slack.solidus.io/)
GitHub Security Advisory: GHSA-qxmr-qxh6-2cc9
Package: solidus_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.0.0, < 3.0.4
Patched in: 3.0.4

Summary: ReDos vulnerability on guest checkout email validation

Details:
### Impact
Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like `a.a.`.

Before the patch, it can be reproduced in the console like this:

```ruby
irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil
```

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the `type` attribute for that field from `email` to `text`. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.


### Patches
Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

```bash
bin/rails solidus:check_orders_with_invalid_email
```

The above will print information for every affected order if any.

### Workarounds

If a prompt upgrade is not an option, please, add the following to `config/application.rb`:

```ruby
config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end
```

### References

- https://en.wikipedia.org/wiki/ReDoS
- https://snyk.io/blog/redos-and-catastrophic-backtracking/

### For more information
If you have any questions or comments about this advisory:
* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.
* Email us at [security@solidus.io](mailto:security@soliidus.io)
* Contact the core team on [Slack](http://slack.solidus.io/)
GitHub Security Advisory: GHSA-qxmr-qxh6-2cc9
Package: solidus_core (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: < 2.11.13
Patched in: 2.11.13

Summary: ReDos vulnerability on guest checkout email validation

Details:
### Impact
Denial of service vulnerability that could be exploited during a guest checkout. The regular expression used to validate a guest order's email was subject to exponential backtracking through a fragment like `a.a.`.

Before the patch, it can be reproduced in the console like this:

```ruby
irb(main)> Spree::EmailValidator::EMAIL_REGEXP.match "a@a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.a.@"
processing time: 54.293660s
=> nil
```

To reproduce in the browser, fill in the "Customer Email" field with that fake email address during a guest checkout. Before that, you should open the browser dev tools and change the `type` attribute for that field from `email` to `text`. After entering a fake address and pressing the "Save & Continue" button, the browser will take a long term to perform the request before showing an error message for the invalid address. Eventually, making the email string even longer could lead to the exhaustion of server resources.


### Patches
Versions 3.1.4, 3.0.4, and 2.11.13 have been patched to use a different regular expression.

There's an improbable chance that some orders in your system end up having associated an email address that is no longer valid. We've added a task to check precisely that:

```bash
bin/rails solidus:check_orders_with_invalid_email
```

The above will print information for every affected order if any.

### Workarounds

If a prompt upgrade is not an option, please, add the following to `config/application.rb`:

```ruby
config.after_initialize do
  Spree::EmailValidator.send(:remove_const, :EMAIL_REGEXP)
  Spree::EmailValidator::EMAIL_REGEXP = URI::MailTo::EMAIL_REGEXP
end
```

### References

- https://en.wikipedia.org/wiki/ReDoS
- https://snyk.io/blog/redos-and-catastrophic-backtracking/

### For more information
If you have any questions or comments about this advisory:
* Open an [issue](https://github.com/solidusio/solidus/issues) or a [discussion](https://github.com/solidusio/solidus/discussions) in Solidus.
* Email us at [security@solidus.io](mailto:security@soliidus.io)
* Contact the core team on [Slack](http://slack.solidus.io/)
GitHub Security Advisory: GHSA-7phj-gmgx-2r66
Package: activerecord (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 3.0.0, <= 3.2.22.0
Patched in: 3.2.22.1

Summary: Moderate severity vulnerability that affects activerecord

Details:
Withdrawn, accidental duplicate publish.

activerecord/lib/active_record/nested_attributes.rb in Active Record in Ruby on Rails 3.1.x and 3.2.x before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not properly implement a certain destroy option, which allows remote attackers to bypass intended change restrictions by leveraging use of the nested attributes feature.
GitHub Security Advisory: GHSA-7phj-gmgx-2r66
Package: activerecord (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 4.2.0, <= 4.2.5.0
Patched in: 4.2.5.1

Summary: Moderate severity vulnerability that affects activerecord

Details:
Withdrawn, accidental duplicate publish.

activerecord/lib/active_record/nested_attributes.rb in Active Record in Ruby on Rails 3.1.x and 3.2.x before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not properly implement a certain destroy option, which allows remote attackers to bypass intended change restrictions by leveraging use of the nested attributes feature.
GitHub Security Advisory: GHSA-7phj-gmgx-2r66
Package: activerecord (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 4.0.0, <= 4.1.14.0
Patched in: 4.1.14.1

Summary: Moderate severity vulnerability that affects activerecord

Details:
Withdrawn, accidental duplicate publish.

activerecord/lib/active_record/nested_attributes.rb in Active Record in Ruby on Rails 3.1.x and 3.2.x before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not properly implement a certain destroy option, which allows remote attackers to bypass intended change restrictions by leveraging use of the nested attributes feature.
GitHub Security Advisory: GHSA-vwfg-qj3r-6v3r
Package: actionpack (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: >= 4.0.0, <= 4.1.14.0
Patched in: 4.1.14.1

Summary: Moderate severity vulnerability that affects actionpack

Details:
Withdrawn, accidental duplicate publish.

The http_basic_authenticate_with method in actionpack/lib/action_controller/metal/http_authentication.rb in the Basic Authentication implementation in Action Controller in Ruby on Rails before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not use a constant-time algorithm for verifying credentials, which makes it easier for remote attackers to bypass authentication by measuring timing differences.
GitHub Security Advisory: GHSA-vwfg-qj3r-6v3r
Package: actionpack (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: <= 3.2.22.0
Patched in: 3.2.22.1

Summary: Moderate severity vulnerability that affects actionpack

Details:
Withdrawn, accidental duplicate publish.

The http_basic_authenticate_with method in actionpack/lib/action_controller/metal/http_authentication.rb in the Basic Authentication implementation in Action Controller in Ruby on Rails before 3.2.22.1, 4.0.x and 4.1.x before 4.1.14.1, 4.2.x before 4.2.5.1, and 5.x before 5.0.0.beta1.1 does not use a constant-time algorithm for verifying credentials, which makes it easier for remote attackers to bypass authentication by measuring timing differences.