deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-26xx-m4q2-xhq8
Package: spree_auth_devise (RUBYGEMS)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 4.3.0, < 4.4.1
Patched in: 4.4.1

Summary: Spree Auth Devise vulnerability allows for authentication bypass through CSRF weakness

Details:
### Impact

CSRF vulnerability that allows user account takeover.

All applications using any version of the frontend component of `spree_auth_devise` are affected if `protect_from_forgery` method is both:

* Executed whether as:
  * A before_action callback (the default)
  * A prepend_before_action (option prepend: true given) before the :load_object hook in Spree::UserController (most likely order to find).
* Configured to use :null_session or :reset_session strategies (:null_session is the default in case the no strategy is given, but rails --new generated skeleton use :exception).

That means that applications that haven't been configured differently from what it's generated with Rails aren't affected.

Thanks @waiting-for-dev for reporting and providing a patch 👏 

### Patches

Spree 4.3 users should update to spree_auth_devise 4.4.1
Spree 4.2 users should update to spree_auth_devise 4.2.1
Spree 4.1 users should update to spree_auth_devise 4.1.1
Older Spree version users should update to spree_auth_devise 4.0.1
 
### Workarounds

If possible, change your strategy to :exception:

```ruby
class ApplicationController < ActionController::Base
  protect_from_forgery with: :exception
end
```

Add the following to`config/application.rb `to at least run the `:exception` strategy on the affected controller:

```ruby
config.after_initialize do
  Spree::UsersController.protect_from_forgery with: :exception
end
```

### References
https://github.com/solidusio/solidus_auth_devise/security/advisories/GHSA-xm34-v85h-9pg2
GitHub Security Advisory: GHSA-xm34-v85h-9pg2
Package: solidus_auth_devise (RUBYGEMS)
Severity: CRITICAL (CVSS 9.3)
CWE: CWE-352: Cross-Site Request Forgery (CSRF)
Vulnerable versions: >= 1.0.0, < 2.5.4
Patched in: 2.5.4

Summary: Authentication Bypass by CSRF Weakness

Details:
### Impact
CSRF vulnerability that allows user account takeover.

All applications using any version of the frontend component of  `solidus_auth_devise` are affected if `protect_from_forgery` method is both: 
- Executed whether as:
  - A `before_action` callback (the default)
  - A `prepend_before_action` (option `prepend: true` given) before the `:load_object` hook in `Spree::UserController` (most likely order to find).
- Configured to use `:null_session` or `:reset_session` strategies (`:null_session` is the default in case the no strategy is given, but `rails --new` generated skeleton use `:exception`).

That means that applications that haven't been configured differently from what it's generated with Rails aren't affected.

### Patches
Users should promptly update to `solidus_auth_devise` version `2.5.4`.

### Workarounds
A couple of options:

- If possible, change your strategy to `:exception`:
  ```ruby
  class ApplicationController < ActionController::Base
    protect_from_forgery with: :exception
  end
  ```

- Add the following to `config/application.rb` to at least run the `:exception` strategy on the affected controller:
  ```ruby
  config.after_initialize do
    Spree::UsersController.protect_from_forgery with: :exception
  end
  ```

- We've also released new Solidus versions monkey patching `solidus_auth_devise` with the quick fix. Those versions are `v3.1.3`, `v.3.0.3` & `v2.11.12`. See [GHSA-5629-8855-gf4g](https://github.com/solidusio/solidus/security/advisories/GHSA-5629-8855-gf4g) for details.

### References
- [CSRF on the Rails guides](https://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf)
- [Solidus security](https://solidus.io/security/)

### Thanks
We'd like to thank [vampire000](https://hackerone.com/vampire000) for reporting this issue.

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

Summary: Regular expression denial of service vulnerability (ReDoS) in date

Details:
Date’s parsing methods including Date.parse are using Regexps internally, some of which are vulnerable against regular expression denial of service. Applications and libraries that apply such methods to untrusted input may be affected.

The fix limits the input length up to 128 bytes by default instead of changing the regexps. This is because Date gem uses many Regexps and it is possible that there are still undiscovered vulnerable Regexps. For compatibility, it is allowed to remove the limitation by explicitly passing limit keywords as nil like Date.parse(str, limit: nil), but note that it may take a long time to parse.

Please update the date gem to version 3.2.1, 3.1.2, 3.0.2, and 2.0.1, or later. You can use gem update date to update it. If you are using bundler, please add gem "date", ">= 3.2.1" to your Gemfile. If you import `date` from the standard library rather than as a gem you should update your Ruby install to `3.0.3`, `2.7.5`, `2.6.9` or later.

Users unable to upgrade may consider using `Date.strptime` instead with a predefined date format
```ruby
Date.strptime('2001-02-20', '%Y-%m-%d')
```
GitHub Security Advisory: GHSA-qg54-694p-wgpp
Package: date (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.0.0, < 3.0.2
Patched in: 3.0.2

Summary: Regular expression denial of service vulnerability (ReDoS) in date

Details:
Date’s parsing methods including Date.parse are using Regexps internally, some of which are vulnerable against regular expression denial of service. Applications and libraries that apply such methods to untrusted input may be affected.

The fix limits the input length up to 128 bytes by default instead of changing the regexps. This is because Date gem uses many Regexps and it is possible that there are still undiscovered vulnerable Regexps. For compatibility, it is allowed to remove the limitation by explicitly passing limit keywords as nil like Date.parse(str, limit: nil), but note that it may take a long time to parse.

Please update the date gem to version 3.2.1, 3.1.2, 3.0.2, and 2.0.1, or later. You can use gem update date to update it. If you are using bundler, please add gem "date", ">= 3.2.1" to your Gemfile. If you import `date` from the standard library rather than as a gem you should update your Ruby install to `3.0.3`, `2.7.5`, `2.6.9` or later.

Users unable to upgrade may consider using `Date.strptime` instead with a predefined date format
```ruby
Date.strptime('2001-02-20', '%Y-%m-%d')
```
GitHub Security Advisory: GHSA-qg54-694p-wgpp
Package: date (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.1.0, < 3.1.2
Patched in: 3.1.2

Summary: Regular expression denial of service vulnerability (ReDoS) in date

Details:
Date’s parsing methods including Date.parse are using Regexps internally, some of which are vulnerable against regular expression denial of service. Applications and libraries that apply such methods to untrusted input may be affected.

The fix limits the input length up to 128 bytes by default instead of changing the regexps. This is because Date gem uses many Regexps and it is possible that there are still undiscovered vulnerable Regexps. For compatibility, it is allowed to remove the limitation by explicitly passing limit keywords as nil like Date.parse(str, limit: nil), but note that it may take a long time to parse.

Please update the date gem to version 3.2.1, 3.1.2, 3.0.2, and 2.0.1, or later. You can use gem update date to update it. If you are using bundler, please add gem "date", ">= 3.2.1" to your Gemfile. If you import `date` from the standard library rather than as a gem you should update your Ruby install to `3.0.3`, `2.7.5`, `2.6.9` or later.

Users unable to upgrade may consider using `Date.strptime` instead with a predefined date format
```ruby
Date.strptime('2001-02-20', '%Y-%m-%d')
```
GitHub Security Advisory: GHSA-qg54-694p-wgpp
Package: date (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-1333: Inefficient Regular Expression Complexity
Vulnerable versions: >= 3.2.0, < 3.2.1
Patched in: 3.2.1

Summary: Regular expression denial of service vulnerability (ReDoS) in date

Details:
Date’s parsing methods including Date.parse are using Regexps internally, some of which are vulnerable against regular expression denial of service. Applications and libraries that apply such methods to untrusted input may be affected.

The fix limits the input length up to 128 bytes by default instead of changing the regexps. This is because Date gem uses many Regexps and it is possible that there are still undiscovered vulnerable Regexps. For compatibility, it is allowed to remove the limitation by explicitly passing limit keywords as nil like Date.parse(str, limit: nil), but note that it may take a long time to parse.

Please update the date gem to version 3.2.1, 3.1.2, 3.0.2, and 2.0.1, or later. You can use gem update date to update it. If you are using bundler, please add gem "date", ">= 3.2.1" to your Gemfile. If you import `date` from the standard library rather than as a gem you should update your Ruby install to `3.0.3`, `2.7.5`, `2.6.9` or later.

Users unable to upgrade may consider using `Date.strptime` instead with a predefined date format
```ruby
Date.strptime('2001-02-20', '%Y-%m-%d')
```
GitHub Security Advisory: GHSA-844m-cpr9-jcmh
Package: rails_multisite (RUBYGEMS)
Severity: MODERATE (CVSS 6.2)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor, CWE-327: Use of a Broken or Risky Cryptographic Algorithm, CWE-565: Reliance on Cookies without Validation and Integrity Checking
Vulnerable versions: < 4.0.0
Patched in: 4.0.0

Summary: Rails Multisite secure/signed cookies share secrets between sites in a multi-site application

Details:
### Impact
This vulnerability impacts any Rails applications using `rails_multisite` alongside Rails' signed/encrypted cookies. Depending on how the application makes use of these cookies, it may be possible for an attacker to re-use cookies on different 'sites' within a multi-site Rails application.

### Patches
The issue has been patched in v4 of the `rails_multisite` gem. Note that this upgrade will invalidate all previous signed/encrypted cookies. The impact of this invalidation will vary based on the application architecture.
GitHub Security Advisory: GHSA-2rr5-8q37-2w7h
Package: nokogiri (RUBYGEMS)
Severity: HIGH (CVSS 7.5)
CWE: CWE-611: Improper Restriction of XML External Entity Reference
Vulnerable versions: <= 1.12.4
Patched in: 1.12.5

Summary: Improper Restriction of XML External Entity Reference (XXE) in Nokogiri on JRuby

Details:
### Severity

The Nokogiri maintainers have evaluated this as [**High Severity** 7.5 (CVSS3.0)](https://www.first.org/cvss/calculator/3.0#CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N/E:H/RL:O/RC:C/MAV:N/MAC:L) for JRuby users. (This security advisory does not apply to CRuby users.)


### Impact

In Nokogiri v1.12.4 and earlier, **on JRuby only**, the SAX parser resolves external entities by default.

Users of Nokogiri on JRuby who parse untrusted documents using any of these classes are affected:

- Nokogiri::XML::SAX::Parser
- Nokogiri::HTML4::SAX::Parser or its alias Nokogiri::HTML::SAX::Parser
- Nokogiri::XML::SAX::PushParser
- Nokogiri::HTML4::SAX::PushParser or its alias Nokogiri::HTML::SAX::PushParser


### Mitigation

JRuby users should upgrade to Nokogiri v1.12.5 or later. There are no workarounds available for v1.12.4 or earlier.

CRuby users are not affected.
GitHub Security Advisory: GHSA-hwhf-64mh-r662
Package: fluentd (RUBYGEMS)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.14.14, < 1.14.2
Patched in: 1.14.2

Summary: ReDoS vulnerability in parser_apache2

Details:
### Impact
parser_apache2 plugin in Fluentd v0.14.14 to v1.14.1 suffers from a regular expression denial of service (ReDoS) vulnerability. A broken apache log with a certain pattern of string can spend too much time in a regular expression, resulting in the potential for a DoS attack.

### Patches
v1.14.2

### Workarounds
Either of the following:

* Don't use parser_apache2 for parsing logs which cannot guarantee generated by Apache.
* Put patched version of parser_apache2.rb into /etc/fluent/plugin  directory (or any other directories specified by the environment variable `FLUENT_PLUGIN` or `--plugin` option of fluentd).

### References
* [CVE-2021-41186](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-41186)
* [GHSA-hwhf-64mh-r662](https://github.com/fluent/fluentd/security/advisories/GHSA-hwhf-64mh-r662)
* [GHSL-2021-102](https://securitylab.github.com/advisories/GHSL-2021-102-fluent-fluentd/)
* https://github.com/fluent/fluentd/blob/master/CHANGELOG.md#v1142
GitHub Security Advisory: GHSA-48w2-rm65-62xx
Package: puma (RUBYGEMS)
Severity: LOW (CVSS 3.7)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 4.3.9
Patched in: 4.3.9

Summary: Puma with proxy which forwards LF characters as line endings could allow HTTP request smuggling

Details:
### Impact

Prior to `puma` version 5.5.0, using `puma` with a proxy which forwards LF characters as line endings could allow HTTP request smuggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to another unknown client.

This behavior (forwarding LF characters as line endings) is very uncommon amongst proxy servers, so we have graded the impact here as "low". Puma is only aware of a single proxy server which has this behavior.

If the proxy uses persistent connections and the client adds another request in via HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two requests, and when processing the second request, send back a response that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another request for a different client, the second response from the first client will be sent to the second client.

### Patches

This vulnerability was patched in Puma 5.5.1 and 4.3.9.

### Workarounds

This vulnerability only affects Puma installations without any proxy in front.

Use a proxy which does not forward LF characters as line endings.

Proxies which do not forward LF characters as line endings:

* Nginx
* Apache (>2.4.25)
* Haproxy
* Caddy
* Traefik

### Possible Breakage

If you are [dealing with legacy clients that want to send `LF` as a line ending](https://stackoverflow.com/questions/43574428/have-apache-accept-lf-vs-crlf-in-request-headers) in an HTTP header, this will cause those clients to receive a `400` error.

### References

* [HTTP Request Smuggling](https://portswigger.net/web-security/request-smuggling)

### 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-48w2-rm65-62xx
Package: puma (RUBYGEMS)
Severity: LOW (CVSS 3.7)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: >= 5.0.0, < 5.5.1
Patched in: 5.5.1

Summary: Puma with proxy which forwards LF characters as line endings could allow HTTP request smuggling

Details:
### Impact

Prior to `puma` version 5.5.0, using `puma` with a proxy which forwards LF characters as line endings could allow HTTP request smuggling. A client could smuggle a request through a proxy, causing the proxy to send a response back to another unknown client.

This behavior (forwarding LF characters as line endings) is very uncommon amongst proxy servers, so we have graded the impact here as "low". Puma is only aware of a single proxy server which has this behavior.

If the proxy uses persistent connections and the client adds another request in via HTTP pipelining, the proxy may mistake it as the first request's body. Puma, however, would see it as two requests, and when processing the second request, send back a response that the proxy does not expect. If the proxy has reused the persistent connection to Puma to send another request for a different client, the second response from the first client will be sent to the second client.

### Patches

This vulnerability was patched in Puma 5.5.1 and 4.3.9.

### Workarounds

This vulnerability only affects Puma installations without any proxy in front.

Use a proxy which does not forward LF characters as line endings.

Proxies which do not forward LF characters as line endings:

* Nginx
* Apache (>2.4.25)
* Haproxy
* Caddy
* Traefik

### Possible Breakage

If you are [dealing with legacy clients that want to send `LF` as a line ending](https://stackoverflow.com/questions/43574428/have-apache-accept-lf-vs-crlf-in-request-headers) in an HTTP header, this will cause those clients to receive a `400` error.

### References

* [HTTP Request Smuggling](https://portswigger.net/web-security/request-smuggling)

### 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-grh7-935j-hg6w
Package: sidekiq (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 6.0.0, < 6.2.1
Patched in: 6.2.1

Summary: Cross-site Scripting in Sidekiq

Details:
Sidekiq through 5.1.3 and 6.x through 6.2.0 allows XSS via the queue name of the live-poll feature when Internet Explorer is used.
GitHub Security Advisory: GHSA-grh7-935j-hg6w
Package: sidekiq (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 5.2.0
Patched in: 5.2.0

Summary: Cross-site Scripting in Sidekiq

Details:
Sidekiq through 5.1.3 and 6.x through 6.2.0 allows XSS via the queue name of the live-poll feature when Internet Explorer is used.
GitHub Security Advisory: GHSA-vmfh-c547-v45h
Package: ruby-jss (RUBYGEMS)
Severity: CRITICAL (CVSS 9.8)
Vulnerable versions: < 1.6.0
Patched in: 1.6.0

Summary: Remote code execution in ruby-jss

Details:
The Pixar ruby-jss gem before 1.6.0 allows remote attackers to execute arbitrary code because of the Plist gem's documented behavior of using Marshal.load during XML document processing.
GitHub Security Advisory: GHSA-vqcm-7f7f-r539
Package: brbackup (RUBYGEMS)
Severity: HIGH (CVSS 7.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: = 0.1.1
Patched in: unpatched

Summary: brbackup exposes database password to unauthorized users

Details:
lib/brbackup.rb in the brbackup gem 0.1.1 for Ruby places the database password on the mysql command line, which allows local users to obtain sensitive information by listing the process.
GitHub Security Advisory: GHSA-pc3m-v286-2jwj
Package: actionview (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 5.0.0
Patched in: 5.0.0.1

Summary: actionview Cross-site Scripting vulnerability

Details:
Cross-site scripting (XSS) vulnerability in Action View in Ruby on Rails 3.x before 3.2.22.3, 4.x before 4.2.7.1, and 5.x before 5.0.0.1 might allow remote attackers to inject arbitrary web script or HTML via text declared as "HTML safe" and used as attribute values in tag handlers.
GitHub Security Advisory: GHSA-pc3m-v286-2jwj
Package: actionview (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 4.0.0, <= 4.2.7
Patched in: 4.2.7.1

Summary: actionview Cross-site Scripting vulnerability

Details:
Cross-site scripting (XSS) vulnerability in Action View in Ruby on Rails 3.x before 3.2.22.3, 4.x before 4.2.7.1, and 5.x before 5.0.0.1 might allow remote attackers to inject arbitrary web script or HTML via text declared as "HTML safe" and used as attribute values in tag handlers.
GitHub Security Advisory: GHSA-pc3m-v286-2jwj
Package: actionview (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 3.0.0, <= 3.2.22.2
Patched in: 3.2.22.3

Summary: actionview Cross-site Scripting vulnerability

Details:
Cross-site scripting (XSS) vulnerability in Action View in Ruby on Rails 3.x before 3.2.22.3, 4.x before 4.2.7.1, and 5.x before 5.0.0.1 might allow remote attackers to inject arbitrary web script or HTML via text declared as "HTML safe" and used as attribute values in tag handlers.
GitHub Security Advisory: GHSA-pcm6-g2qp-9gw8
Package: cap-strap (RUBYGEMS)
Severity: HIGH (CVSS 7.8)
CWE: CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
Vulnerable versions: = 0.1.5
Patched in: unpatched

Summary: Cap-Strap gem for Ruby places credentials on the useradd command line

Details:
lib/cap-strap/helpers.rb in the cap-strap gem 0.1.5 for Ruby places credentials on the useradd command line, which allows local users to obtain sensitive information by listing the process.
GitHub Security Advisory: GHSA-mvw8-v767-qhjm
Package: radiant (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 1.1.4
Patched in: unpatched

Summary: Radiant CMS vulnerable to Cross-site Scripting

Details:
Radiant CMS 1.1.4 has XSS via crafted Markdown input in the `part_body_content` parameter to an `admin/pages/*/edit `resource.
GitHub Security Advisory: GHSA-gp82-xr77-88f4
Package: radiant (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: = 1.1.4
Patched in: unpatched

Summary: radiant vulnerable to Cross-site Scripting

Details:
There are multiple Persistent XSS vulnerabilities in Radiant CMS 1.1.4. They affect Personal Preferences (Name and Username) and Configuration (Site Title, Dev Site Domain, Page Parts, and Page Fields).
GitHub Security Advisory: GHSA-g982-9r8g-6qxw
Package: ciborg (RUBYGEMS)
Severity: MODERATE (CVSS 5.5)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: = 3.0.0
Patched in: unpatched

Summary: Ciborg gem for Ruby allows local users to write files and gain privileges via Symlink

Details:
There is a /tmp file race condition in `chef/travis-cookbooks/ci_environment/perlbrew/recipes/default.rb` in the ciborg gem 3.0.0 when creating `/tmp/perlbrew-installer`. If a malicious local user creates the file first they can overwrite the contents with their own code executing it as the ciborg process owner.
GitHub Security Advisory: GHSA-9hx9-w2j6-rw76
Package: show_in_browser (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-59: Improper Link Resolution Before File Access ('Link Following')
Vulnerable versions: = 0.0.3
Patched in: unpatched

Summary: Script Injection in Show In Browser gem

Details:
The Show In Browser (show_in_browser) gem 0.0.3 for Ruby allows local users to inject arbitrary web script or HTML via a symlink attack on `/tmp/browser.html`.