### 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`](https://github.com/shopware/shopware/blob/trunk/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 1. More targeted dictionary/bruteforce attacks. 2. Spear phishing / eases social engineering. 3. Credential stuffing from other data leaks. ### Authors Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
### 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`](https://github.com/shopware/shopware/blob/trunk/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 1. More targeted dictionary/bruteforce attacks. 2. Spear phishing / eases social engineering. 3. Credential stuffing from other data leaks. ### Authors Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
Update shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Timing-attack on admin panel allowing enumeration of administrator usernames affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is low. ### 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`](https://github.com/shopware/shopware/blob/trunk/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 1. More targeted dictionary/bruteforce attacks. 2. Spear phishing / eases social engineering. 3. Credential stuffing from other data leaks. ### Authors Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Timing-attack on admin panel allowing enumeration of administrator usernames affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is low. ### 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`](https://github.com/shopware/shopware/blob/trunk/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 1. More targeted dictionary/bruteforce attacks. 2. Spear phishing / eases social engineering. 3. Credential stuffing from other data leaks. ### Authors Niel Duysters (@NielDuysters) and Thomas Brankaer (@tbrankaer)
AI coding agents often install or upgrade packages automatically in composer. A low vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard