Shopware 6 allows attackers to check for registered accounts through the store-apiGHSA-hh7j-6x3q-f52h
MEDIUMGHSA-hh7j-6x3q-f52h is a medium-severity (CVSS 5.3) CWE-204 vulnerability in shopware/core. A fix is available for shopware/core — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-hh7j-6x3q-f52h.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
shopware/core🐘shopware/platform🐘shopware/core🐘shopware/platform🐘shopware/core🐘shopware/platformReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Through the store-api it is possible as a attacker to check if a specific e-mail address has an account in the shop.
Using the store-api endpoint /store-api/account/recovery-password you get the response
{"errors":[{"status":"404","code":"CHECKOUT__CUSTOMER_NOT_FOUND","title":"Not Found","detail":"No matching customer for the email \[email protected]\u0022 was found.","meta":{"parameters":{"email":"[email protected]"}}}]}
which indicates clearly that there is no account for this customer. In contrast you get a success response if the account was found.
Patches
Update to Shopware 6.6.10.3
Workarounds
For older versions of 6.5 or 6.4, corresponding security measures are also available via a plugin. For the full range of functions, we recommend updating to the latest Shopware version.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | shopware/core | ≥ 6.6.0.0&&< 6.6.10.3 | 6.6.10.3composer require shopware/core:^6.6.10.3 |
| 🐘Packagist | shopware/platform | ≥ 6.6.0.0&&< 6.6.10.3 | 6.6.10.3composer require shopware/platform:^6.6.10.3 |
| 🐘Packagist | shopware/core | ≥ 6.7.0.0-rc1&&< 6.7.0.0-rc2 | 6.7.0.0-rc2composer require shopware/core:^6.7.0.0-rc2 |
| 🐘Packagist | shopware/platform | ≥ 6.7.0.0-rc1&&< 6.7.0.0-rc2 | 6.7.0.0-rc2composer require shopware/platform:^6.7.0.0-rc2 |
| 🐘Packagist | shopware/core | all versions | 6.5.8.18composer require shopware/core:^6.5.8.18 |
| 🐘Packagist | shopware/platform | all versions | 6.5.8.18composer require shopware/platform:^6.5.8.18 |
Affected Products
shopwareshopwareDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopware/core, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update shopware/core to 6.6.10.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-hh7j-6x3q-f52h 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.
Frequently Asked Questions
Is GHSA-hh7j-6x3q-f52h in your dependencies?
Find it across Packagist, including transitive dependencies.