deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-cf3w-g86h-35x4
Package: carrierwave (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: < 1.3.2
Patched in: 1.3.2

Summary: Code Injection vulnerability in CarrierWave::RMagick

Details:
### Impact
[CarrierWave::RMagick](https://github.com/carrierwaveuploader/carrierwave/blob/master/lib/carrierwave/processing/rmagick.rb) has a Code Injection vulnerability. Its `#manipulate!` method inappropriately evals the content of mutation option(`:read`/`:write`), allowing attackers to craft a string that can be executed as a Ruby code.
If an application developer supplies untrusted inputs to the option, it will lead to remote code execution(RCE).

(But supplying untrusted input to the option itself is dangerous even in absence of this vulnerability, since is prone to DoS vulnerability - attackers can try to consume massive amounts of memory by resizing to a very large dimension)

### Proof of Concept
```ruby
class MyUploader < CarrierWave::Uploader::Base
  include CarrierWave::RMagick
end

MyUploader.new.manipulate!({ read: { density: "1 }; p 'Hacked'; {" }}) # => shows "Hacked"
```

### Patches
Upgrade to [2.1.1](https://rubygems.org/gems/carrierwave/versions/2.1.1) or [1.3.2](https://rubygems.org/gems/carrierwave/versions/1.3.2).

### Workarounds
Stop supplying untrusted input to `#manipulate!`'s mutation option.

### References
[Code Injection Software Attack](https://owasp.org/www-community/attacks/Code_Injection)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [CarrierWave repo](https://github.com/carrierwaveuploader/carrierwave)
* Email me at [mit.shibuya@gmail.com](mailto:mit.shibuya@gmail.com)
GitHub Security Advisory: GHSA-fwcm-636p-68r5
Package: carrierwave (RUBYGEMS)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: >= 2.0.0, < 2.1.1
Patched in: 2.1.1

Summary: Server-side request forgery in CarrierWave

Details:
### Impact
[CarrierWave download feature](https://github.com/carrierwaveuploader/carrierwave#uploading-files-from-a-remote-location) has an SSRF vulnerability, allowing attacks to provide DNS entries or IP addresses that are intended for internal use and gather information about the Intranet infrastructure of the platform.

### Patches
Upgrade to [2.1.1](https://rubygems.org/gems/carrierwave/versions/2.1.1) or [1.3.2](https://rubygems.org/gems/carrierwave/versions/1.3.2).

### Workarounds
Using proper network segmentation and applying the principle of least privilege to outbound connections from application servers can reduce the severity of SSRF vulnerabilities. Ideally the vulnerable gem should run on an isolated server without access to any internal network resources or cloud metadata access.

### References
[Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [CarrierWave repo](https://github.com/carrierwaveuploader/carrierwave)
* Email me at [mit.shibuya@gmail.com](mailto:mit.shibuya@gmail.com)
GitHub Security Advisory: GHSA-fwcm-636p-68r5
Package: carrierwave (RUBYGEMS)
Severity: MODERATE (CVSS 4.3)
CWE: CWE-918: Server-Side Request Forgery (SSRF)
Vulnerable versions: < 1.3.2
Patched in: 1.3.2

Summary: Server-side request forgery in CarrierWave

Details:
### Impact
[CarrierWave download feature](https://github.com/carrierwaveuploader/carrierwave#uploading-files-from-a-remote-location) has an SSRF vulnerability, allowing attacks to provide DNS entries or IP addresses that are intended for internal use and gather information about the Intranet infrastructure of the platform.

### Patches
Upgrade to [2.1.1](https://rubygems.org/gems/carrierwave/versions/2.1.1) or [1.3.2](https://rubygems.org/gems/carrierwave/versions/1.3.2).

### Workarounds
Using proper network segmentation and applying the principle of least privilege to outbound connections from application servers can reduce the severity of SSRF vulnerabilities. Ideally the vulnerable gem should run on an isolated server without access to any internal network resources or cloud metadata access.

### References
[Server-Side Request Forgery Prevention Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html)

### For more information
If you have any questions or comments about this advisory:
* Open an issue in [CarrierWave repo](https://github.com/carrierwaveuploader/carrierwave)
* Email me at [mit.shibuya@gmail.com](mailto:mit.shibuya@gmail.com)
GitHub Security Advisory: GHSA-qrqm-fpv6-6r8g
Package: mechanize (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-78: Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
Vulnerable versions: >= 2.0.0, < 2.7.7
Patched in: 2.7.7

Summary: Command Injection Vulnerability in Mechanize

Details:
This security advisory has been created for public disclosure of a Command Injection vulnerability that was responsibly reported by @kyoshidajp (Katsuhiko YOSHIDA).

### Impact

Mechanize `>= v2.0`, `< v2.7.7` allows for OS commands to be injected using several classes' methods which implicitly use Ruby's `Kernel.open` method. Exploitation is possible only if untrusted input is used as a local filename and passed to any of these calls:

- `Mechanize::CookieJar#load`: since v2.0 (see 208e3ed)
- `Mechanize::CookieJar#save_as`: since v2.0 (see 5b776a4)
- `Mechanize#download`: since v2.2 (see dc91667)
- `Mechanize::Download#save` and `#save!` since v2.1 (see 98b2f51, bd62ff0)
- `Mechanize::File#save` and `#save_as`: since v2.1 (see 2bf7519)
- `Mechanize::FileResponse#read_body`: since v2.0 (see 01039f5)


### Patches

These vulnerabilities are patched in Mechanize v2.7.7.


### Workarounds

No workarounds are available. We recommend upgrading to v2.7.7 or later.


### References

See https://docs.rubocop.org/rubocop/cops_security.html#securityopen for background on why `Kernel.open` should not be used with untrusted input.


### For more information

If you have any questions or comments about this advisory, please open an issue in [sparklemotion/mechanize](https://github.com/sparklemotion/mechanize/issues/new).
GitHub Security Advisory: GHSA-wjx2-7hqq-8h7m
Package: rails_admin (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 1.4.3
Patched in: 1.4.3

Summary: rails_admin ruby gem XSS vulnerability

Details:
RailsAdmin (aka rails_admin) before 1.4.3 and 2.x before 2.0.2 allows XSS via nested forms.
GitHub Security Advisory: GHSA-wjx2-7hqq-8h7m
Package: rails_admin (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 2.0.0, < 2.0.2
Patched in: 2.0.2

Summary: rails_admin ruby gem XSS vulnerability

Details:
RailsAdmin (aka rails_admin) before 1.4.3 and 2.x before 2.0.2 allows XSS via nested forms.
GitHub Security Advisory: GHSA-q3wr-qw3g-3p4h
Package: redcarpet (RUBYGEMS)
Severity: MODERATE (CVSS 6.8)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection'), CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: < 3.5.1
Patched in: 3.5.1

Summary: Injection/XSS in Redcarpet

Details:
Redcarpet is a Ruby library for Markdown processing. In Redcarpet before version 3.5.1, there is an injection vulnerability which can enable a cross-site scripting attack. In affected versions no HTML escaping was being performed when processing quotes. This applies even when the `:escape_html` option was being used.  This is fixed in version 3.5.1 by the referenced commit.
GitHub Security Advisory: GHSA-2j55-pcw5-x4h2
Package: active-support (RUBYGEMS)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: > 0
Patched in: unpatched

Summary: active-support impersonates 'activesupport' gem

Details:
The `active-support` ruby gem gem is malware and duplicates the official `activesupport` (no hyphen) gem, but adds a compiled extension. The extension attempts to resolve a base64 encoded domain (29faea63.planfhntage.de), downloads a payload, and executes.
 
This trojan horse gem could allow a remote attacker to execute arbitrary code on the system, caused by containing a malicious backdoor. An attacker could exploit this vulnerability to execute arbitrary code on the system.  No version of this gem should be considered safe.
GitHub Security Advisory: GHSA-49r3-2549-3633
Package: omniauth-apple (RUBYGEMS)
Severity: HIGH (CVSS 7.7)
CWE: CWE-290: Authentication Bypass by Spoofing
Vulnerable versions: < 1.0.1
Patched in: 1.0.1

Summary: omniauth-apple allows attacker to fake their email address during authentication

Details:
### Impact

This vulnerability impacts applications using the [omniauth-apple](https://github.com/nhosoya/omniauth-apple) strategy of OmniAuth and using the `info.email` field of OmniAuth's [Auth Hash Schema](https://github.com/omniauth/omniauth/wiki/Auth-Hash-Schema) for any kind of identification.  The value of this field may be set to any value of the attacker's choice including email addresses of other users.

For example, an application using omniauth-apple with the following code will be impacted:
```ruby
def omniauth_callback
    auth_hash = request.env['omniauth.auth']
    @authenticated_user = User.find_by(email: auth_hash.info.email)
end
```

Applications not using `info.email` for identification but are instead using the `uid` field are not impacted in the same manner.  Note, these applications may still be negatively affected if the value of `info.email` is being used for other purposes.

### Patches

Applications using affected versions of omniauth-apple are advised to upgrade to omniauth-apple version 1.0.1 or later.

### Workarounds

If unable to upgrade to a patched version, monkey patching `OmniAuth::Strategies::Apple#email` as follows is advised as a workaround:

```ruby
module OmniAuth
  module Strategies
    class Apple
      def email
        id_info['email']
      end
    end
  end
end
```
GitHub Security Advisory: GHSA-m2jr-hmc3-qmpr
Package: spree_api (RUBYGEMS)
Severity: HIGH (CVSS 7.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 4.1.0, < 4.1.12
Patched in: 4.1.12

Summary: Authorization bypass in Spree

Details:
### Impact
The perpetrator could query the [API v2 Order Status](https://guides.spreecommerce.org/api/v2/storefront#tag/Order-Status) endpoint with an empty string passed as an Order token

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. Users of Spree < 3.7 are not affected.

### References
Pull request with a fix and in-depth explanation - https://github.com/spree/spree/pull/10573

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-m2jr-hmc3-qmpr
Package: spree_api (RUBYGEMS)
Severity: HIGH (CVSS 7.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 4.0.0, < 4.0.5
Patched in: 4.0.5

Summary: Authorization bypass in Spree

Details:
### Impact
The perpetrator could query the [API v2 Order Status](https://guides.spreecommerce.org/api/v2/storefront#tag/Order-Status) endpoint with an empty string passed as an Order token

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. Users of Spree < 3.7 are not affected.

### References
Pull request with a fix and in-depth explanation - https://github.com/spree/spree/pull/10573

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-m2jr-hmc3-qmpr
Package: spree_api (RUBYGEMS)
Severity: HIGH (CVSS 7.7)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: >= 3.7.0, < 3.7.13
Patched in: 3.7.13

Summary: Authorization bypass in Spree

Details:
### Impact
The perpetrator could query the [API v2 Order Status](https://guides.spreecommerce.org/api/v2/storefront#tag/Order-Status) endpoint with an empty string passed as an Order token

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. Users of Spree < 3.7 are not affected.

### References
Pull request with a fix and in-depth explanation - https://github.com/spree/spree/pull/10573

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-23f7-99jx-m54r
Package: dependabot-common (RUBYGEMS)
Severity: HIGH (CVSS 8.7)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: >= 0.119.0.beta1, < 0.125.1
Patched in: 0.125.1

Summary: Remote code execution in dependabot-core branch names when cloning

Details:
### Impact
Remote code execution vulnerability in `dependabot-common` and  `dependabot-go_modules` when a source branch name contains malicious injectable bash code.

For example, if Dependabot is configured to use the following source branch name: `"/$({curl,127.0.0.1})"`, Dependabot will make a HTTP request to the following URL: 127.0.0.1 when cloning the source repository.

When Dependabot is configured to clone the source repository during an update, Dependabot runs a shell command to git clone the repository:

```bash
git clone --no-tags --no-recurse-submodules --depth=1 --branch=<BRANCH> --single-branch <GITHUB_REPO_URL> repo/contents/path
```

Dependabot will always clone the source repository for `go_modules` during the file fetching step and can be configured to clone the repository for other package managers using the `FileFetcher` class from `dependabot-common`.

```ruby
source = Dependabot::Source.new(
  provider: "github",
  repo: "repo/name",
  directory: "/",
  branch: "/$({curl,127.0.0.1})",
)

repo_contents_path = "./file/path"
fetcher = Dependabot::FileFetchers.for_package_manager("bundler").
                  new(source: source, credentials: [],
                  repo_contents_path: repo_contents_path)
fetcher.clone_repo_contents
```

### Patches

The fix was applied to version `0.125.1`: https://github.com/dependabot/dependabot-core/pull/2727

### Workarounds
Escape the branch name prior to passing it to the `Dependabot::Source` class.

For example using `shellwords`:

```ruby
require "shellwords"
branch = Shellwords.escape("/$({curl,127.0.0.1})")
source = Dependabot::Source.new(
  provider: "github",
  repo: "repo/name",
  directory: "/",
  branch: branch,
)
```
GitHub Security Advisory: GHSA-23f7-99jx-m54r
Package: dependabot-omnibus (RUBYGEMS)
Severity: HIGH (CVSS 8.7)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: >= 0.119.0.beta1, < 0.125.1
Patched in: 0.125.1

Summary: Remote code execution in dependabot-core branch names when cloning

Details:
### Impact
Remote code execution vulnerability in `dependabot-common` and  `dependabot-go_modules` when a source branch name contains malicious injectable bash code.

For example, if Dependabot is configured to use the following source branch name: `"/$({curl,127.0.0.1})"`, Dependabot will make a HTTP request to the following URL: 127.0.0.1 when cloning the source repository.

When Dependabot is configured to clone the source repository during an update, Dependabot runs a shell command to git clone the repository:

```bash
git clone --no-tags --no-recurse-submodules --depth=1 --branch=<BRANCH> --single-branch <GITHUB_REPO_URL> repo/contents/path
```

Dependabot will always clone the source repository for `go_modules` during the file fetching step and can be configured to clone the repository for other package managers using the `FileFetcher` class from `dependabot-common`.

```ruby
source = Dependabot::Source.new(
  provider: "github",
  repo: "repo/name",
  directory: "/",
  branch: "/$({curl,127.0.0.1})",
)

repo_contents_path = "./file/path"
fetcher = Dependabot::FileFetchers.for_package_manager("bundler").
                  new(source: source, credentials: [],
                  repo_contents_path: repo_contents_path)
fetcher.clone_repo_contents
```

### Patches

The fix was applied to version `0.125.1`: https://github.com/dependabot/dependabot-core/pull/2727

### Workarounds
Escape the branch name prior to passing it to the `Dependabot::Source` class.

For example using `shellwords`:

```ruby
require "shellwords"
branch = Shellwords.escape("/$({curl,127.0.0.1})")
source = Dependabot::Source.new(
  provider: "github",
  repo: "repo/name",
  directory: "/",
  branch: branch,
)
```
GitHub Security Advisory: GHSA-58r4-h6v8-jcvm
Package: omniauth-auth0 (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-287: Improper Authentication, CWE-347: Improper Verification of Cryptographic Signature
Vulnerable versions: >= 2.3.0, < 2.4.1
Patched in: 2.4.1

Summary: Regression in JWT Signature Validation

Details:
### Overview
Versions after and including `2.3.0` are improperly validating the JWT token signature when using the `JWTValidator.verify` method.  Improper validation of the JWT token signature when not using the default Authorization Code Flow can allow an attacker to bypass authentication and authorization.

### Am I affected?
You are affected by this vulnerability if all of the following conditions apply:

- You are using `omniauth-auth0`.
- You are using `JWTValidator.verify` method directly OR you are not authenticating using the SDK’s default Authorization Code Flow.

### How to fix that?
Upgrade to version `2.4.1`.

### Will this update impact my users?
The fix provided in this version will not affect your users.
GitHub Security Advisory: GHSA-f8cm-364f-q9qh
Package: spree (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-287: Improper Authentication, CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 4.1.0, < 4.1.11
Patched in: 4.1.11

Summary: Ensure that doorkeeper_token is valid when authenticating requests in API v2 calls

Details:
### Impact
The perpetrator who previously obtained an old expired user token could use it to access Storefront API v2 endpoints. 

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. 

### Workarounds
In your project directory create a decorator file `app/controllers/spree/api/v2/base_controller_decotatror.rb` with contents:

```ruby
module Spree
  module Api
    module V2
      module BaseControllerDecorator
        private

        def spree_current_user
          return nil unless doorkeeper_token
          return @spree_current_user if @spree_current_user

          doorkeeper_authorize!

          @spree_current_user ||= ::Spree.user_class.find_by(id: doorkeeper_token.resource_owner_id)
        end
     end
  end
end

Spree::Api::V2::BaseController.prepend(Spree::Api::V2::BaseControllerDecorator)
```

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-f8cm-364f-q9qh
Package: spree (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-287: Improper Authentication, CWE-613: Insufficient Session Expiration
Vulnerable versions: >= 4.0.0, < 4.0.4
Patched in: 4.0.4

Summary: Ensure that doorkeeper_token is valid when authenticating requests in API v2 calls

Details:
### Impact
The perpetrator who previously obtained an old expired user token could use it to access Storefront API v2 endpoints. 

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. 

### Workarounds
In your project directory create a decorator file `app/controllers/spree/api/v2/base_controller_decotatror.rb` with contents:

```ruby
module Spree
  module Api
    module V2
      module BaseControllerDecorator
        private

        def spree_current_user
          return nil unless doorkeeper_token
          return @spree_current_user if @spree_current_user

          doorkeeper_authorize!

          @spree_current_user ||= ::Spree.user_class.find_by(id: doorkeeper_token.resource_owner_id)
        end
     end
  end
end

Spree::Api::V2::BaseController.prepend(Spree::Api::V2::BaseControllerDecorator)
```

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-f8cm-364f-q9qh
Package: spree (RUBYGEMS)
Severity: HIGH (CVSS 7.4)
CWE: CWE-287: Improper Authentication, CWE-613: Insufficient Session Expiration
Vulnerable versions: < 3.7.11
Patched in: 3.7.11

Summary: Ensure that doorkeeper_token is valid when authenticating requests in API v2 calls

Details:
### Impact
The perpetrator who previously obtained an old expired user token could use it to access Storefront API v2 endpoints. 

### Patches
Please upgrade to 3.7.11, 4.0.4, or 4.1.11 depending on your used Spree version. 

### Workarounds
In your project directory create a decorator file `app/controllers/spree/api/v2/base_controller_decotatror.rb` with contents:

```ruby
module Spree
  module Api
    module V2
      module BaseControllerDecorator
        private

        def spree_current_user
          return nil unless doorkeeper_token
          return @spree_current_user if @spree_current_user

          doorkeeper_authorize!

          @spree_current_user ||= ::Spree.user_class.find_by(id: doorkeeper_token.resource_owner_id)
        end
     end
  end
end

Spree::Api::V2::BaseController.prepend(Spree::Api::V2::BaseControllerDecorator)
```

### For more information
If you have any questions or comments about this advisory:
* Email us at [security@spreecommerce.org](mailto:security@spreecommerce.org)
GitHub Security Advisory: GHSA-h385-52j6-9984
Package: agoo (RUBYGEMS)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: <= 2.13.0
Patched in: unpatched

Summary: Withdrawn: HTTP Request Smuggling in Agoo

Details:
# Withdrawn reason
Withdrawn on 1/13/2021 due to [this comment from the maintainer](https://github.com/ohler55/agoo/issues/88#issuecomment-723580783).  This is no longer considered a vulnerability.

# Original description
agoo through 2.12.3 allows request smuggling attacks where agoo is used as a backend and a frontend proxy also being vulnerable. It is possible to conduct HTTP request smuggling attacks by sending the Content-Length header twice. Furthermore, invalid Transfer Encoding headers were found to be parsed as valid which could be leveraged for TE:CL smuggling attacks.