← Back to results
Vulnerability record · public intelligence
CVE-2020-15109
MEDIUM

Ability to change order address without triggering address validations in solidus

Published Aug 4, 2020 · Updated Nov 3, 2026

Severity · CVSSMEDIUM · Not scored
Known exploitationNot listed
EPSS / likelihood1.00%
QFinch risk scoreNot available

Original summary

Normalized public record · Updated Nov 3, 2026

Ability to change order address without triggering address validations in solidus

Publisher and source text is retained separately from QFinch interpretation.

QFinch assessment

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.

Potential 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: 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 shipaddressattributes. 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.

Evidence: public source records

Affected products

Affected scope reported by the available public evidence
Affected package, product or rangeFix status
Consult the referenced vendor advisory for affected versions.Consult source advisory

Matching a version is only one part of assessing exposure. QFinch has not assessed your environment on this public page.

Remediation

Apply the vendor-supported fixed release or mitigation, then verify the affected component is no longer reachable.

  1. Confirm the affected product and reachable code path exist in your environment.
  2. Apply the vendor-supported patch or mitigation from the primary advisory.
  3. Rescan the exact deployed revision and retain verification evidence.
Review primary references

Evidence coverage

FIRST-EPSSCVE-LIST-V5
SSVC priority
LOW
Confidence
Not available
Aliases
None reported

Scores appear only when corresponding evidence exists. Missing data is never interpreted as zero risk.

Sources and record history

  1. Security advisory ↗
  2. gist.github.com ↗

Record history

Published Aug 4, 2020 · Last refreshed Nov 3, 2026