Shopware: Timing-attack on admin panel allowing enumeration of administrator usernamesGHSA-7w52-7jvm-m9vw
LOWGHSA-7w52-7jvm-m9vw is a low-severity (CVSS 3.7) CWE-208 vulnerability in shopware/platform. A fix is available for shopware/platform — see the affected versions and patch details below.
Exploitation Status
Proof-of-concept exploit code exists
- CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
Exploitation and automatability from CISA’s SSVC triage for GHSA-7w52-7jvm-m9vw.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-7w52-7jvm-m9vw by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 390,400 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
shopware/platform🐘shopware/platform🐘shopware/core🐘shopware/coreReal-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
Summary
There is a Proof of Concept which is able to enumerate the usernames of administrator users. This was possible by performing a timing attack.
Details
The faulty code exists in src/Core/Framework/Api/OAuth/UserRepository.php:
public function getUserEntityByUserCredentials(
string $username,
#[\SensitiveParameter]
string $password,
string $grantType,
ClientEntityInterface $clientEntity
): ?UserEntityInterface {
if ($this->loginConfigService->getConfig()?->useDefault === false) {
// never allow login via password if the default login is disabled (e.g. using SSO only)
return null;
}
$builder = $this->connection->createQueryBuilder();
$user = $builder->select('user.id', 'user.password')
->from('user')
->where('username = :username')
->setParameter('username', $username)
->fetchAssociative();
// PATH 1: EARLY RETURN WHEN USERNAME IS NOT FOUND
if (!$user) {
return null;
}
// PATH 2: VERIFY PASSWORD IF USER IS FOUND
if (!password_verify($password, (string) $user['password'])) {
return null;
}
return new User(Uuid::fromBytesToHex($user['id']));
}
Subroutine getUserEntityByUserCredentials() is called when an auth request is send to api/oauth/token. If the given username is not found an early return is done (PATH 1). Only if the user is found we verify the password using password_verify.
PHP method password_verify by default uses hashing algorithm Argon2id which by design is intentionally 'slow' by introducing a timing cost to an attempt to bruteforce hashes more costly.
Since password_verify has a notable executable time, PATH 2 where an user is found and verified will be slower on average then PATH 1 where we do an early return for non-existing users.
Proposed fix
Before doing the early return, password_verify a dummy hash.
Impact
- More targeted dictionary/bruteforce attacks.
- Spear phishing / eases social engineering.
- Credential stuffing from other data leaks.
Authors
Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | shopware/platform | ≥ 6.7.0.0&&< 6.7.10.1 | 6.7.10.1composer require shopware/platform:^6.7.10.1 |
| 🐘Packagist | shopware/platform | all versions | 6.6.10.18composer require shopware/platform:^6.6.10.18 |
| 🐘Packagist | shopware/core | ≥ 6.7.0.0&&< 6.7.10.1 | 6.7.10.1composer require shopware/core:^6.7.10.1 |
| 🐘Packagist | shopware/core | all versions | 6.6.10.18composer require shopware/core:^6.6.10.18 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for shopware/platform, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update shopware/platform to 6.7.10.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-7w52-7jvm-m9vw 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-7w52-7jvm-m9vw in your dependencies?
Find it across Packagist, including transitive dependencies.