GHSA-8V9P-G828-V98F

Vulnerability from github – Published: 2026-06-04 19:27 – Updated: 2026-06-04 19:27
VLAI
Summary
Shopware: Admin Account Takeover via User Recovery Hash Exposure
Details

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.phphash 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 barrieruser_recovery:read is 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)),
Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/platform"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "6.7.0.0"
            },
            {
              "fixed": "6.7.10.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "shopware/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "6.6.10.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48009"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-200"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T19:27:15Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA 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\u0027s password (another unauthenticated endpoint). The recovery hash \u2014 intended to be secret and delivered only via email \u2014 is fully readable through the standard entity search API.\n\n**OWASP:** A01:2021 \u2014 Broken Access Control\n\n## Root Cause\n\nThe `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.\n\nThe password recovery flow assumes the hash is delivered exclusively via email. The Admin API provides an alternative channel to obtain it, breaking this assumption.\n\n**Three endpoints combine to form the attack:**\n\n1. `POST /api/_action/user/user-recovery` \u2014 triggers recovery, creates hash in DB (**no auth required**)\n2. `POST /api/search/user-recovery` \u2014 reads the hash (**requires only `user_recovery:read` ACL**)\n3. `PATCH /api/_action/user/user-recovery/password` \u2014 resets password using hash (**no auth required**)\n\n**Vulnerable code:**\n- `src/Core/System/User/Recovery/UserRecoveryDefinition.php` \u2014 `hash` field is `ApiAware` with no `ReadProtection`\n\n## Impact\n\n- **Full admin account takeover** \u2014 attacker gains the highest privilege level in the system\n- **All admin capabilities** \u2014 user/role management, system configuration, plugin management, customer data access\n- **Cascading compromise** \u2014 taken-over admin account can be used to pivot to other attacks\n- **Low barrier** \u2014 `user_recovery:read` is a seemingly harmless permission that grants devastating access\n\n## Remediation\n\nRemove the `hash` field from API responses:\n\n```php\n// src/Core/System/User/Recovery/UserRecoveryDefinition.php\n(new StringField(\u0027hash\u0027, \u0027hash\u0027))\n    -\u003eaddFlags(new Required(), new ApiAware(false)),\n```",
  "id": "GHSA-8v9p-g828-v98f",
  "modified": "2026-06-04T19:27:15Z",
  "published": "2026-06-04T19:27:15Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-8v9p-g828-v98f"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/shopware/shopware"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.6.10.18"
    },
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/releases/tag/v6.7.10.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware: Admin Account Takeover via User Recovery Hash Exposure"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…