GHSA-mrj3-f2h4-7w45
MEDIUMSaleor: Customers' addresses leak when using Warehouse as a `Pickup: Local stock only` delivery method
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
Blast Radius
saleor🐍saleor🐍saleor🐍saleor🐍saleor🐍saleorReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Summary
Using Pickup: Local stock only as a click-and-collect points could cause a leak of customer addresses
Details
When using Pickup: Local stock only click-and-collect as a delivery method in specific conditions the customer could overwrite the warehouse address with its own, which exposes its address as click-and-collect address.
Impact
The vulnerability can cause the leak of customer's address when using click-and-collect delivery option marked as Local stock only. It has impact on all orders with click-and-collect delivery method marked as Pickup:Local stock only
The affected versions: >=3.14.56 <3.14.61, >=3.15.31 <3.15.37, >=3.16.27 <3.16.34, >=3.17.25 <3.17.32, >=3.18.19 <3.18.28, >=3.19.5 <3.19.15
This issue has been patched in versions: 3.14.61, 3.15.37, 3.16.34, 3.17.32, 3.18.28, 3.19.15
Workaround
We strongly recommend upgrading to the latest versions, in case of inability to upgrade straight away, possible workarounds are:
- turn off click-and-collect delivery method on warehouse view when
Pickupoption is set toLocal stock only. - cherry-pick the changes from PRs: https://github.com/saleor/saleor/pull/15694 & https://github.com/saleor/saleor/pull/15697
References
- Commits introducing the issue (https://github.com/saleor/saleor/commit/22a1aa3ef0bc54156405f69146788016a7f3f761 main, https://github.com/saleor/saleor/commit/997f7ea4f576543ec88679a86bfe1b14f7f2ff26 3.14, https://github.com/saleor/saleor/commit/ef003c76a304c89ddb2dc65b7f1d5b3b2ba1c640 3.15, https://github.com/saleor/saleor/commit/39abb0f4e4fe6503f81bfbb871227e4f70bcdd5c 3.16, https://github.com/saleor/saleor/commit/b7cecda8b603f7472790150bb4508c7b655946d4 3.17, https://github.com/saleor/saleor/commit/dccc2c842b4e2e09470929c80f07dc137e439182 3.18, https://github.com/saleor/saleor/commit/d8ba545c16ad3153febc5b5be8fd2ef75da9fc95 3.19)
- https://github.com/saleor/saleor/commit/47cedfd7d6524d79bdb04708edcdbb235874de6b (main branch) https://github.com/saleor/saleor/releases/tag/3.14.60 https://github.com/saleor/saleor/releases/tag/3.14.61 https://github.com/saleor/saleor/releases/tag/3.15.36 https://github.com/saleor/saleor/releases/tag/3.15.37 https://github.com/saleor/saleor/releases/tag/3.16.33 https://github.com/saleor/saleor/releases/tag/3.16.34 https://github.com/saleor/saleor/releases/tag/3.17.31 https://github.com/saleor/saleor/releases/tag/3.17.32 https://github.com/saleor/saleor/releases/tag/3.18.27 https://github.com/saleor/saleor/releases/tag/3.18.28 https://github.com/saleor/saleor/releases/tag/3.19.14 https://github.com/saleor/saleor/releases/tag/3.19.15
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | saleor | ≥ 3.14.56&&< 3.14.61 | 3.14.61 |
| 🐍PyPI | saleor | ≥ 3.15.31&&< 3.15.37 | 3.15.37 |
| 🐍PyPI | saleor | ≥ 3.16.27&&< 3.16.34 | 3.16.34 |
| 🐍PyPI | saleor | ≥ 3.17.25&&< 3.17.32 | 3.17.32 |
| 🐍PyPI | saleor | ≥ 3.18.19&&< 3.18.28 | 3.18.28 |
| 🐍PyPI | saleor | ≥ 3.19.5&&< 3.19.15 | 3.19.15 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for saleor. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update saleor to 3.14.61 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-mrj3-f2h4-7w45 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-mrj3-f2h4-7w45 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-mrj3-f2h4-7w45. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-mrj3-f2h4-7w45 in your dependencies?
O3 detects GHSA-mrj3-f2h4-7w45 across PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.