## 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:** 1. `POST /api/_action/user/user-recovery` — triggers recovery, creates hash in DB (**no auth required**) 2. `POST /api/search/user-recovery` — reads the hash (**requires only `user_recovery:read` ACL**) 3. `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:read` is a seemingly harmless permission that grants devastating access ## Remediation Remove the `hash` field from API responses: ```php // src/Core/System/User/Recovery/UserRecoveryDefinition.php (new StringField('hash', 'hash')) ->addFlags(new Required(), new ApiAware(false)), ```
## 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:** 1. `POST /api/_action/user/user-recovery` — triggers recovery, creates hash in DB (**no auth required**) 2. `POST /api/search/user-recovery` — reads the hash (**requires only `user_recovery:read` ACL**) 3. `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:read` is a seemingly harmless permission that grants devastating access ## Remediation Remove the `hash` field from API responses: ```php // src/Core/System/User/Recovery/UserRecoveryDefinition.php (new StringField('hash', 'hash')) ->addFlags(new Required(), new ApiAware(false)), ```
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: Admin Account Takeover via User Recovery Hash Exposure affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. ## 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:** 1. `POST /api/_action/user/user-recovery` — triggers recovery, creates hash in DB (**no auth required**) 2. `POST /api/search/user-recovery` — reads the hash (**requires only `user_recovery:read` ACL**) 3. `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:read` is a seemingly harmless permission that grants devastating access ## Remediation Remove the `hash` field from API responses: ```php // src/Core/System/User/Recovery/UserRecoveryDefinition.php (new StringField('hash', 'hash')) ->addFlags(new Required(), new ApiAware(false)), ```
AI coding agents often install or upgrade packages automatically in composer. A medium 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: Admin Account Takeover via User Recovery Hash Exposure affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. ## 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:** 1. `POST /api/_action/user/user-recovery` — triggers recovery, creates hash in DB (**no auth required**) 2. `POST /api/search/user-recovery` — reads the hash (**requires only `user_recovery:read` ACL**) 3. `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:read` is a seemingly harmless permission that grants devastating access ## Remediation Remove the `hash` field from API responses: ```php // src/Core/System/User/Recovery/UserRecoveryDefinition.php (new StringField('hash', 'hash')) ->addFlags(new Required(), new ApiAware(false)), ```
AI coding agents often install or upgrade packages automatically in composer. A medium 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