deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-5jjv-x4fq-qjwp
Package: shrine (RUBYGEMS)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-203: Observable Discrepancy, CWE-208: Observable Timing Discrepancy
Vulnerable versions: < 3.3.0
Patched in: 3.3.0

Summary: Possible timing attack in derivation_endpoint

Details:
### Impact

When using the `derivation_endpoint` plugin, it's possible for the attacker to use a timing attack to guess the signature of the derivation URL.

### Patches

The problem has been fixed by comparing sent and calculated signature in constant time, using `Rack::Utils.secure_compare`. Users using the `derivation_endpoint` plugin are urged to upgrade to Shrine 3.3.0 or greater.

### Workarounds

Users of older Shrine versions can apply the following monkey-patch after loading the `derivation_endpoint` plugin:

```rb
class Shrine
  class UrlSigner
    def verify_signature(string, signature)
      if signature.nil?
        fail InvalidSignature, "missing \"signature\" param"
      elsif !Rack::Utils.secure_compare(signature, generate_signature(string))
        fail InvalidSignature, "provided signature does not match the calculated signature"
      end
    end
  end
end
```

### References

You can read more about timing attacks [here](https://en.wikipedia.org/wiki/Timing_attack).
GitHub Security Advisory: GHSA-vp9c-fpxx-744v
Package: personnummer (RUBYGEMS)
Severity: LOW (CVSS 0.0)
Vulnerable versions: < 3.0.1
Patched in: 3.0.1

Summary: personnummer/ruby vulnerable to Improper Input Validation

Details:
This vulnerability was reported to the personnummer team in June 2020. The slow response was due to locked ownership of some of the affected packages, which caused delays to update packages prior to disclosure.

The vulnerability is determined to be low severity.

### Impact

This vulnerability impacts users who rely on the for last digits of personnummer to be a _real_ personnummer.  

### Patches

The issue have been patched in all repositories. The following versions should be updated to as soon as possible:

[C#](https://github.com/advisories/GHSA-qv8q-v995-72gr) 3.0.2  
D 3.0.1  
[Dart](https://github.com/advisories/GHSA-4xh4-v2pq-jvhm) 3.0.3  
Elixir 3.0.0  
[Go](https://github.com/advisories/GHSA-hv53-vf5m-8q94) 3.0.1  
[Java](https://github.com/advisories/GHSA-q3vw-4jx3-rrr2) 3.3.0  
[JavaScript](https://github.com/advisories/GHSA-vpgc-7h78-gx8f) 3.1.0  
Kotlin 1.1.0  
Lua 3.0.1  
[PHP](https://github.com/advisories/GHSA-2p6g-gjp8-ggg9) 3.0.2  
Perl 3.0.0  
[Python](https://github.com/advisories/GHSA-rxq3-5249-8hgg) 3.0.2  
[Ruby](https://github.com/advisories/GHSA-vp9c-fpxx-744v) 3.0.1  
[Rust](https://github.com/advisories/GHSA-28r9-pq4c-wp3c) 3.0.0  
Scala 3.0.1  
Swift 1.0.1  

If you are using any of the earlier packages, please update to latest.

### Workarounds

The issue arrieses from the regular expression allowing the first three digits in the last four digits of the personnummer to be
000, which is invalid. To mitigate this without upgrading, a check on the last four digits can be made to make sure it's not
000x.

### For more information

If you have any questions or comments about this advisory:
* Open an issue in [Personnummer Meta](https://github.com/personnummer/meta/issues)
* Email us at [Personnummer Email](mailto:security@personnummer.dev)
GitHub Security Advisory: GHSA-cfjv-5498-mph5
Package: actionview (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: <= 5.2.4.3
Patched in: 5.2.4.4

Summary: XSS in Action View

Details:
There is a potential Cross-Site Scripting (XSS) vulnerability in Action View's translation helpers. Views that allow the user to control the default (not found) value of the `t` and `translate` helpers could be susceptible to XSS attacks.

### Impact

When an HTML-unsafe string is passed as the default for a missing translation key [named `html` or ending in `_html`](https://guides.rubyonrails.org/i18n.html#using-safe-html-translations), the default string is incorrectly marked as HTML-safe and not escaped. Vulnerable code may look like the following examples:

```erb
<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>
```

### Patches

Patched Rails versions, 6.0.3.3 and 5.2.4.4, are available from the normal locations.

The patches have also been applied to the `master`, `6-0-stable`, and `5-2-stable` branches on GitHub. If you track any of these branches, you should update to the latest.

To aid users who aren’t able to upgrade immediately, we’ve provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

* [5-2-translate-helper-xss.patch](https://gist.github.com/georgeclaghorn/a466e103922ee81f24c32c[PII_REDACTED]#file-5-2-translate-helper-xss-patch) — patch for the 5.2 release series
* [6-0-translate-helper-xss.patch](https://gist.github.com/georgeclaghorn/a466e103922ee81f24c32c[PII_REDACTED]#file-6-0-translate-helper-xss-patch) — patch for the 6.0 release series

Please note that only the 5.2 and 6.0 release series are currently supported. Users of earlier, unsupported releases are advised to update as soon as possible, as we cannot provide security fixes for unsupported releases.

### Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid this issue by manually escaping default translations with the `html_escape` helper (aliased as `h`):

```erb
<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>
```
GitHub Security Advisory: GHSA-cfjv-5498-mph5
Package: actionview (RUBYGEMS)
Severity: MODERATE (CVSS 5.4)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
Vulnerable versions: >= 6.0.0.0, <= 6.0.3.2
Patched in: 6.0.3.3

Summary: XSS in Action View

Details:
There is a potential Cross-Site Scripting (XSS) vulnerability in Action View's translation helpers. Views that allow the user to control the default (not found) value of the `t` and `translate` helpers could be susceptible to XSS attacks.

### Impact

When an HTML-unsafe string is passed as the default for a missing translation key [named `html` or ending in `_html`](https://guides.rubyonrails.org/i18n.html#using-safe-html-translations), the default string is incorrectly marked as HTML-safe and not escaped. Vulnerable code may look like the following examples:

```erb
<%# The welcome_html translation is not defined for the current locale: %>
<%= t("welcome_html", default: untrusted_user_controlled_string) %>

<%# Neither the title.html translation nor the missing.html translation is defined for the current locale: %>
<%= t("title.html", default: [:"missing.html", untrusted_user_controlled_string]) %>
```

### Patches

Patched Rails versions, 6.0.3.3 and 5.2.4.4, are available from the normal locations.

The patches have also been applied to the `master`, `6-0-stable`, and `5-2-stable` branches on GitHub. If you track any of these branches, you should update to the latest.

To aid users who aren’t able to upgrade immediately, we’ve provided patches for the two supported release series. They are in git-am format and consist of a single changeset.

* [5-2-translate-helper-xss.patch](https://gist.github.com/georgeclaghorn/a466e103922ee81f24c32c[PII_REDACTED]#file-5-2-translate-helper-xss-patch) — patch for the 5.2 release series
* [6-0-translate-helper-xss.patch](https://gist.github.com/georgeclaghorn/a466e103922ee81f24c32c[PII_REDACTED]#file-6-0-translate-helper-xss-patch) — patch for the 6.0 release series

Please note that only the 5.2 and 6.0 release series are currently supported. Users of earlier, unsupported releases are advised to update as soon as possible, as we cannot provide security fixes for unsupported releases.

### Workarounds

Impacted users who can’t upgrade to a patched Rails version can avoid this issue by manually escaping default translations with the `html_escape` helper (aliased as `h`):

```erb
<%= t("welcome_html", default: h(untrusted_user_controlled_string)) %>
```
GitHub Security Advisory: GHSA-3j95-fjv2-3m4p
Package: chartkick (RUBYGEMS)
Severity: MODERATE (CVSS 6.1)
CWE: CWE-74: Improper Neutralization of Special Elements in Output Used by a Downstream Component ('Injection')
Vulnerable versions: < 3.4.0
Patched in: 3.4.0

Summary: CSS Injection in Chartkick gem

Details:
The Chartkick gem through 3.3.2 for Ruby allows Cascading Style Sheets (CSS) Injection (without attribute).
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_api (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: >= 2.10.0, < 2.10.2
Patched in: 2.10.2

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_api (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: >= 2.9.0, < 2.9.6
Patched in: 2.9.6

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_api (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: < 2.8.6
Patched in: 2.8.6

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_frontend (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: >= 2.10.0, < 2.10.2
Patched in: 2.10.2

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_frontend (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: >= 2.9.0, < 2.9.6
Patched in: 2.9.6

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-3mvg-rrrw-m7ph
Package: solidus_frontend (RUBYGEMS)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-20: Improper Input Validation, CWE-862: Missing Authorization
Vulnerable versions: < 2.8.6
Patched in: 2.8.6

Summary: Ability to change order address without triggering address validations in solidus

Details:
### Impact

This vulnerability allows a malicious customer to craft request data with parameters that allow changing the address of the current order without changing the shipment costs associated with the new shipment.

All stores with at least two shipping zones and different costs of shipment per zone are impacted. 

E.g.
1. Store admin configured the store so that there are two zones in US:
-  East Cost Zone - Shipping Method cost: $1
- West Cost Zone - Shipping Method cost: $10

The attacker user can know that shipping to NY is less expensive than to LA just by testing different addresses in checkout.

2. The attacker user enters any NY shipping address in the address step
3. The attacker user chooses the $1 delivery option
4. The attacker user crafts a request with their real LA address, similar to:

```
// POST #checkout/update:

{
  state: 'payment',
  order: {
    ship_address_attributes: {
      city: 'Los Angeles',
      ...
    }
  }
}
```
5. The attacker user proceeds with checking out with a new address and the $1 shipment costs.

Another scenario where this could be dangerous is:

> You cannot ship products in some zones and you are relying on Solidus Shipping Method building only to filter out unwanted zones. Malicious users can enter an allowed zone's address and change back to an unwanted one in the payment step by crafting a request with some proper ship_address_attributes.

This problem comes from how checkout permitted attributes are structured. We have a single list of attributes that are permitted across the whole checkout, no matter the step that is being submitted.

### Patches

A PR has been attached to fix the security concern for each of all the Solidus supported versions following the rules of the [Solidus Security Policy](https://solidus.io/security).

### Workarounds

When it's not possible to upgrade to a supported patched version, please use this gist to patch the store:

https://gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
GitHub Security Advisory: GHSA-cr3x-7m39-c6jq
Package: actionview (RUBYGEMS)
Severity: HIGH (CVSS 8.8)
CWE: CWE-94: Improper Control of Generation of Code ('Code Injection')
Vulnerable versions: <= 4.2.11.1
Patched in: 4.2.11.3

Summary: Remote code execution via user-provided local names in ActionView

Details:
The is a code injection vulnerability in versions of Rails prior to 5.0.1 that would allow an attacker who controlled the `locals` argument of a `render` call to perform a RCE.