CVE-2020-15109
Ability to change order address without triggering address validations in solidus
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. 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. 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. See the linked reference for more information. As a workaround, if it is not possible to upgrade to a supported patched version, please use this gist in the references section.
Attack profile
How easy it is to exploit
- Attack vector
- Network
- Complexity
- Low
- Privileges needed
- None
- User interaction
- None
What an attacker can affect
- Confidentiality
- None
- Integrity
- Low
- Availability
- None
Exploit likelihood
What each source reports
CVE List Score used
5.3
Ability to change order address without triggering address validations in solidus
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. 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. 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. See the linked reference for more information. As a workaround, if it is not possible to upgrade to a supported patched version, please use this gist in the references section.
- Record
CVE-2020-15109- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20
- Updated
- 2026-11-02
EUVDEUVD-2020-0585
5.3
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. 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. 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. See the linked reference for more information. As a workaround, if it is not possible to upgrade to a supported patched version, please use this gist in the references section.
- Record
EUVD-2020-0585- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Updated
- 2026-11-03
GitHub AdvisoriesGHSA-3mvg-rrrw-m7ph
5.3
Ability to change order address without triggering address validations in solidus
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.
- 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.
- The attacker user enters any NY shipping address in the address step
- The attacker user chooses the $1 delivery option
- 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',
...
}
}
}
- 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.
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
- Record
GHSA-3mvg-rrrw-m7ph- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20, CWE-862
- Updated
- 2026-11-02
NVD
5.3
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. 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. 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. See the linked reference for more information. As a workaround, if it is not possible to upgrade to a supported patched version, please use this gist in the references section.
- Record
CVE-2020-15109- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - CVSS 2.0
- 5.0 Medium
AV:N/AC:L/Au:N/C:N/I:P/A:N - Weakness
- CWE-20, CWE-862
- Updated
- 2026-11-02
OSV
5.3
In solidus before versions 2.8.6, 2.9.6, and 2.10.2, there is an bility to change order address without triggering address validations. 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. 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. See the linked reference for more information. As a workaround, if it is not possible to upgrade to a supported patched version, please use this gist in the references section.
- Record
CVE-2020-15109- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Updated
- 2026-11-02
OSVGHSA-3mvg-rrrw-m7ph
5.3
Ability to change order address without triggering address validations in solidus
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.
- 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.
- The attacker user enters any NY shipping address in the address step
- The attacker user chooses the $1 delivery option
- 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',
...
}
}
}
- 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.
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
- Record
GHSA-3mvg-rrrw-m7ph- CVSS 3.1
- 5.3 Medium
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N - Weakness
- CWE-20, CWE-862
- Updated
- 2026-11-02
Affected products
Affected packages
| Package | Affected | Fixed |
|---|---|---|
solidus_frontendRubyGems |
before 2.8.6 | 2.8.6 |
solidus_frontendRubyGems |
2.9.0 up to 2.9.6 | 2.9.6 |
solidus_frontendRubyGems |
2.10.0 up to 2.10.2 | 2.10.2 |
solidus_apiRubyGems |
before 2.8.6 | 2.8.6 |
solidus_apiRubyGems |
2.9.0 up to 2.9.6 | 2.9.6 |
solidus_apiRubyGems |
2.10.0 up to 2.10.2 | 2.10.2 |
solidus_frontendRubyGems |
before 2.8.6, plus listed versions 1.0.01.0.0.pre1.0.0.pre21.0.0.pre31.0.0.rc1 Show 45 moreShow less1.0.0.rc21.0.11.0.21.0.31.0.41.0.51.0.61.0.71.1.01.1.0.beta11.1.0.pre11.1.0.pre21.1.11.1.21.1.31.1.41.2.01.2.0.beta11.2.0.rc11.2.0.rc21.2.11.2.21.2.31.3.01.3.0.beta11.3.0.rc11.3.0.rc21.3.11.3.21.4.01.4.0.beta11.4.0.rc11.4.11.4.22.0.02.0.0.beta12.0.0.rc12.0.12.0.22.0.32.1.02.1.0.beta12.1.0.rc12.1.12.2.0 |
2.8.6 |
solidus_frontendRubyGems |
2.9.0 up to 2.9.6, plus listed versions 2.9.12.9.22.9.32.9.42.9.5 |
2.9.6 |
solidus_frontendRubyGems |
2.10.0 up to 2.10.2, plus listed versions 2.10.1 |
2.10.2 |
solidus_apiRubyGems |
before 2.8.6, plus listed versions 1.0.01.0.0.pre1.0.0.pre21.0.0.pre31.0.0.rc1 Show 45 moreShow less1.0.0.rc21.0.11.0.21.0.31.0.41.0.51.0.61.0.71.1.01.1.0.beta11.1.0.pre11.1.0.pre21.1.11.1.21.1.31.1.41.2.01.2.0.beta11.2.0.rc11.2.0.rc21.2.11.2.21.2.31.3.01.3.0.beta11.3.0.rc11.3.0.rc21.3.11.3.21.4.01.4.0.beta11.4.0.rc11.4.11.4.22.0.02.0.0.beta12.0.0.rc12.0.12.0.22.0.32.1.02.1.0.beta12.1.0.rc12.1.12.2.0 |
2.8.6 |
solidus_apiRubyGems |
2.9.0 up to 2.9.6, plus listed versions 2.9.12.9.22.9.32.9.42.9.5 |
2.9.6 |
solidus_apiRubyGems |
2.10.0 up to 2.10.2, plus listed versions 2.10.1 |
2.10.2 |
History
| Recorded | Changed | Sources |
|---|---|---|
| aliases | EUVD | |
| first indexed | CVE List, GitHub Advisories, NVD, OSV |
Dates are when Every CVE recorded each change. Upstream dates may differ.
In short
CVE-2020-15109 is a medium vulnerability (CVSS 5.3) in Nebulab Solidus, published August 4, 2020. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 1.00%, the 62nd percentile. Fixed in solidus_frontend 2.8.6.
References
github.com/solidusio/solidus/security/advisories/GHSA-3mvg-rrrw-m7ph
gist.github.com/kennyadsl/4618cd9797984cb64f7700a81bda889d
solidus.io/blog/2020/07/16/new-releases.html
nvd.nist.gov/vuln/detail/CVE-2020-15109
github.com/rubysec/ruby-advisory-db/blob/master/gems/solidus_api/CVE-2020-15109.yml
github.com/rubysec/ruby-advisory-db/blob/master/gems/solidus_frontend/CVE-2020-15109.yml
github.com/advisories/GHSA-3mvg-rrrw-m7ph
github.com/solidusio/solidus
Left out here: 80 versions. The JSON record has them.