CVE-2026-48009: Shopware Authentication Bypass Vulnerability

CVE-2026-48009 Overview

CVE-2026-48009 is an information exposure vulnerability [CWE-200] in Shopware, an open commerce platform. A low-privilege administrator holding the user_recovery:read ACL can escalate to full admin account takeover. The flaw resides in src/Core/System/User/Recovery/UserRecoveryDefinition.php, which exposes the password recovery hash field through the Admin API. The definition lacks ApiAware(false) or ReadProtection flags, allowing the hash to be read via the standard search endpoint. The issue is fixed in Shopware versions 6.6.10.18 and 6.7.10.1.

Critical Impact
An authenticated low-privilege admin can take over any admin account, including higher-privileged ones, by chaining recovery-request, hash-read, and password-reset API calls.

Affected Products

Shopware versions prior to 6.6.10.18 (6.6.x branch)
Shopware versions prior to 6.7.10.1 (6.7.x branch)
Shopware open commerce platform deployments exposing the Admin API

Discovery Timeline

2026-07-17 - CVE-2026-48009 published to NVD
2026-07-17 - Last updated in NVD database

Technical Details for CVE-2026-48009

Vulnerability Analysis

The vulnerability is a broken access control and information disclosure issue in Shopware's Data Abstraction Layer (DAL). The UserRecoveryDefinition entity defines the fields available to the Admin API, including the hash field used for password recovery workflows. Because the field lacks the ApiAware(false) flag and any ReadProtection, any authenticated admin user with the narrow user_recovery:read ACL can query the hash via the DAL search endpoint.

An attacker exploits this by issuing three sequential Admin API calls. First, POST /api/_action/user/user-recovery initiates recovery for the target admin. Second, POST /api/search/user-recovery reads the newly generated hash. Third, PATCH /api/_action/user/user-recovery/password submits the hash together with a new password, completing the account takeover.

Root Cause

The root cause is a missing field-level access control flag in the entity definition. Fields destined for internal use only must be marked with ApiAware(false) or protected by ReadProtection. The hash field in UserRecoveryEntity was returned by the DAL serializer without such restrictions, and the corresponding entity getter did not enforce a property access check.

Attack Vector

The attack requires network access to the Admin API and an authenticated session with the user_recovery:read ACL. No user interaction is required. The attack complexity is elevated because the attacker must chain recovery initiation with hash retrieval before the recovery token expires.

php

// Patch: src/Core/System/User/Aggregate/UserRecovery/UserRecoveryDefinition.php
 use Shopware\Core\Framework\DataAbstractionLayer\EntityDefinition;
 use Shopware\Core\Framework\DataAbstractionLayer\Field\CreatedAtField;
 use Shopware\Core\Framework\DataAbstractionLayer\Field\FkField;
+use Shopware\Core\Framework\DataAbstractionLayer\Field\Flag\ApiAware;
 use Shopware\Core\Framework\DataAbstractionLayer\Field\Flag\PrimaryKey;
 use Shopware\Core\Framework\DataAbstractionLayer\Field\Flag\Required;
 use Shopware\Core\Framework\DataAbstractionLayer\Field\IdField;

// Patch: src/Core/System/User/Aggregate/UserRecovery/UserRecoveryEntity.php
 public function getHash(): string
 {
+    $this->checkIfPropertyAccessIsAllowed('hash');
+
     return $this->hash;
 }

Source: GitHub Commit 9ef4873 and GitHub Commit 06f8b9a. The patches add explicit property access checks and refactor the ApiAware handling to prevent the hash field from being serialized to Admin API consumers.

Detection Methods for CVE-2026-48009

Indicators of Compromise

Admin API access logs showing POST /api/_action/user/user-recovery followed within seconds by POST /api/search/user-recovery from the same session or integration token.
Subsequent PATCH /api/_action/user/user-recovery/password calls that successfully reset an admin password not owned by the caller.
Admin login events from unexpected IP addresses immediately after a recovery-password reset sequence.

Detection Strategies

Alert on any Admin API caller that queries the user_recovery entity and includes the hash field in the response payload.
Correlate the three-step API sequence (recovery request → search → password patch) originating from a single identity within a short time window.
Baseline legitimate use of user_recovery endpoints and flag deviations, since recovery is normally initiated by end users, not admin API tokens.

Monitoring Recommendations

Enable audit logging for all Admin API calls under /api/_action/user/user-recovery and /api/search/user-recovery.
Track the assignment and use of the user_recovery:read ACL and restrict it to service accounts that require it.
Monitor Shopware application logs for password reset completions on high-privilege admin accounts.

How to Mitigate CVE-2026-48009

Immediate Actions Required

Upgrade to Shopware 6.6.10.18 or 6.7.10.1 as documented in GitHub Security Advisory GHSA-8v9p-g828-v98f.
Audit all admin users and integrations that hold the user_recovery:read ACL and revoke unnecessary grants.
Rotate credentials for any admin account that may have been targeted during the exposure window.

Patch Information

Shopware released fixes in versions 6.6.10.18 and 6.7.10.1. The patches remove the ApiAware exposure of the hash field and add checkIfPropertyAccessIsAllowed('hash') inside UserRecoveryEntity::getHash(). See the release notes at GitHub Release 6.6.10.18 and GitHub Release 6.7.10.1.

Workarounds

Remove the user_recovery:read ACL from all custom admin roles until patching is complete.
Restrict Admin API access at the network layer to trusted internal networks or VPN clients.
Disable or limit password recovery workflows for administrative accounts where feasible.

bash

# Update Shopware via Composer to a patched release
composer require shopware/core:~6.7.10.1 --update-with-all-dependencies
# Or for the 6.6.x branch
composer require shopware/core:~6.6.10.18 --update-with-all-dependencies

# Clear caches and run migrations after upgrade
bin/console cache:clear
bin/console database:migrate --all