Shopware: Admin Account Takeover via User Recovery Hash Exposure
Description
Summary
A low-privilege admin user with user_recovery:read ACL can take over any admin account. The attacker triggers password recovery for the victim (unauthenticated endpoint), reads the recovery hash from the Admin API search endpoint, then uses the hash to reset the victim's password (another unauthenticated endpoint). The recovery hash — intended to be secret and delivered only via email — is fully readable through the standard entity search API.
OWASP: A01:2021 — Broken Access Control
Root
Cause
The user_recovery entity exposes its hash field through the Admin API search endpoint (POST /api/search/user-recovery). The hash field lacks ApiAware(false) or ReadProtection, so any user with user_recovery:read ACL can read it.
The password recovery flow assumes the hash is delivered exclusively via email. The Admin API provides an alternative channel to obtain it, breaking this assumption.
Three endpoints combine to form the attack:
POST /api/_action/user/user-recovery— triggers recovery, creates hash in DB (no auth required)POST /api/search/user-recovery— reads the hash (**requires onlyuser_recovery:readACL**)PATCH /api/_action/user/user-recovery/password— resets password using hash (no auth required)
Vulnerable code: - src/Core/System/User/Recovery/UserRecoveryDefinition.php — hash field is ApiAware with no ReadProtection
Impact
- Full admin account takeover — attacker gains the highest privilege level in the system
- All admin capabilities — user/role management, system configuration, plugin management, customer data access
- Cascading compromise — taken-over admin account can be used to pivot to other attacks
- Low barrier —
user_recovery:readis a seemingly harmless permission that grants devastating access
Remediation
Remove the hash field from API responses:
// src/Core/System/User/Recovery/UserRecoveryDefinition.php
(new StringField('hash', 'hash'))
->addFlags(new Required(), new ApiAware(false)),
Affected products
1Patches
194569f7e71e6Merge pull request #210 from shopware/fix/oauth-fixed-verification-time-backport-66
2 files changed · +20 −2
src/Core/Framework/Api/OAuth/ClientRepository.php+12 −1 modified@@ -15,6 +15,11 @@ #[Package('framework')] class ClientRepository implements ClientRepositoryInterface { + /** + * Bcrypt hash for a static dummy secret used to equalize timing when no client is found. + */ + private const DUMMY_CLIENT_SECRET_HASH = '$2y$12$PVcA5R6ri9kS.7FnFUBRIOLwqU//bCicx5RFxwecAAccbmZ7V7PKu'; + /** * @internal */ @@ -34,8 +39,11 @@ public function validateClient($clientIdentifier, $clientSecret, $grantType): bo } $values = $this->getByAccessKey($clientIdentifier); + if (!$values) { - return false; + // Prevent client enumeration via timing attacks by always running password_verify(). + $values = ['secret_access_key' => self::DUMMY_CLIENT_SECRET_HASH]; + $clientSecret = 'invalid-secret-will-always-fail'; } if (!password_verify($clientSecret, (string) $values['secret_access_key'])) { @@ -67,6 +75,9 @@ public function getClientEntity($clientIdentifier): ?ClientEntityInterface $values = $this->getByAccessKey($clientIdentifier); if (!$values) { + // Prevent client enumeration via timing attacks by always running password_verify(). + password_verify('invalid-secret-will-always-fail', self::DUMMY_CLIENT_SECRET_HASH); + return null; }
src/Core/Framework/Api/OAuth/UserRepository.php+8 −1 modified@@ -13,6 +13,11 @@ #[Package('framework')] class UserRepository implements UserRepositoryInterface { + /** + * Bcrypt hash for a static dummy password used to equalize timing when no user is found. + */ + private const DUMMY_PASSWORD_HASH = '$2y$12$PVcA5R6ri9kS.7FnFUBRIOLwqU//bCicx5RFxwecAAccbmZ7V7PKu'; + /** * @internal */ @@ -42,7 +47,9 @@ public function getUserEntityByUserCredentials( ->fetchAssociative(); if (!$user) { - return null; + // Prevent user enumeration via timing attacks by always running password_verify(). + $user = ['password' => self::DUMMY_PASSWORD_HASH]; + $password = 'invalid-password-will-always-fail'; } if (!password_verify($password, (string) $user['password'])) {
Vulnerability mechanics
Root cause
"The `hash` field of the `user_recovery` entity is exposed via the Admin API search endpoint without adequate protection."
Attack vector
An attacker with a low-privilege admin account possessing the `user_recovery:read` ACL can exploit this vulnerability. First, the attacker triggers the password recovery process for a target admin account via an unauthenticated endpoint. Subsequently, the attacker reads the generated recovery hash from the Admin API search endpoint. Finally, the attacker uses this hash to reset the victim's password through another unauthenticated endpoint, thereby taking over the admin account [ref_id=1]. This attack chain leverages three distinct endpoints to bypass intended security controls [ref_id=2].
Affected code
The vulnerability resides in `src/Core/System/User/Recovery/UserRecoveryDefinition.php`. Specifically, the `hash` field is defined with `ApiAware` flags but lacks `ReadProtection`. This allows any user with the `user_recovery:read` ACL to access the sensitive hash value through the Admin API search endpoint, as described in the advisory [ref_id=1].
What the fix does
The remediation involves modifying the `UserRecoveryDefinition.php` file to prevent the `hash` field from being exposed in API responses. By adding the `ApiAware(false)` flag to the `hash` field, it is no longer included when the entity is serialized for API requests. This ensures that the sensitive recovery hash is not accessible through the Admin API, thus closing the alternative channel for obtaining it and preserving the integrity of the password recovery flow [ref_id=2].
Preconditions
- authAttacker must have a low-privilege admin account with the `user_recovery:read` ACL.
Generated on Jun 4, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
4News mentions
1- Shopware: Nine Vulnerabilities Disclosed, Including Privilege Escalation and XSSVypr Intelligence · Jun 4, 2026