VYPR
Medium severity6.5GHSA Advisory· Published Jun 4, 2026· Updated Jun 4, 2026

Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass

CVE-2026-48008

Description

A non-admin user can escalate to full administrator by creating an integration with admin privileges via the Sync API, bypassing access controls.

AI Insight

LLM-synthesized narrative grounded in this CVE's description and references.

A non-admin user can escalate to full administrator by creating an integration with admin privileges via the Sync API, bypassing access controls.

Vulnerability

A non-administrator API user with the integration:create ACL privilege can escalate to full administrator privileges by creating an integration with the admin: true flag through the Sync API (POST /api/_action/sync). The regular integration endpoint (POST /api/integration) correctly enforces this restriction, but the Sync API bypasses the controller-level check by writing directly through the DAL EntityWriter. This is possible because the integration entity definition lacks WriteProtection, and the admin field has no field-level restriction flag. This vulnerability affects Shopware versions >= 6.7.0.0, < 6.7.10.1 and < 6.6.10.18 [2].

Exploitation

An attacker with network access and the integration:create ACL privilege can exploit this vulnerability. The attacker needs to send a POST request to the /api/_action/sync endpoint, creating an integration with the admin: true parameter. This bypasses the intended access control checks that would normally prevent non-administrators from setting the admin flag on an integration [2, 4].

Impact

Successful exploitation grants the attacker complete administrator API access. This allows for full read and write access to all entities, including users, customers, orders, system configuration, integrations, and plugins. The attacker can exfiltrate Personally Identifiable Information (PII) such as customer names, emails, addresses, and order history. The escalated integration also acts as a persistent backdoor, surviving password changes and user deactivations [2, 4].

Mitigation

This vulnerability was fixed in Shopware versions 6.7.10.1 and 6.6.10.18, released on June 4, 2026 [3]. The remediation involves adding WriteProtection(Context::SYSTEM_SCOPE) to the admin field in the IntegrationDefinition [4]. Users should update to the patched versions to mitigate this risk.

AI Insight generated on Jun 4, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.

Affected products

1

Patches

1
94569f7e71e6

Merge pull request #210 from shopware/fix/oauth-fixed-verification-time-backport-66

https://github.com/shopware/shopwareMarcel KrämlMay 19, 2026Fixed in 6.6.10.18via release-tag
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 Sync API bypasses controller-level access checks by writing directly through the DAL EntityWriter, which lacks sufficient validation for the admin field."

Attack vector

A non-administrator API user with the `integration:create` ACL privilege can exploit this vulnerability. By sending a POST request to the Sync API endpoint (`POST /api/_action/sync`), they can create a new integration with the `admin: true` flag set. This bypasses the checks present in the regular integration endpoint (`POST /api/integration`), which would normally prevent such an escalation. The vulnerability stems from the `IntegrationDefinition` lacking a `WriteProtection` on its `admin` field [ref_id=1].

Affected code

The vulnerability lies in the `SyncController::sync()` method, which routes writes through `SyncService` and `EntityWriter::upsert()`. Specifically, the `IntegrationDefinition` in `src/Core/Framework/Integration/IntegrationDefinition.php` lacks a `WriteProtection` on its `admin` field. This bypasses the intended check in `IntegrationController::upsertIntegration()` [ref_id=1].

What the fix does

The remediation involves adding `WriteProtection(Context::SYSTEM_SCOPE)` to the `admin` field within the `IntegrationDefinition` class [ref_id=2]. This ensures that only system-level operations can modify this sensitive field, preventing unauthorized users from escalating their privileges. This change aligns the protection of the integration admin flag with that of other sensitive definitions like `UserDefinition` and `AclRoleDefinition`.

Preconditions

  • authThe attacker must be a non-admin API user with the `integration:create` ACL privilege.

Generated on Jun 4, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.

References

4

News mentions

1