GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

GHSA-GV8P-48FR-4FXG

Vulnerability from github – Published: 2026-06-04 19:23 – Updated: 2026-06-04 19:23
VLAI
Summary
Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass
Details

Summary

A non-admin API user with integration:create ACL privilege can escalate to full administrator by creating an integration with admin: true through the Sync API (POST /api/_action/sync). The regular integration endpoint (POST /api/integration) correctly blocks this, but the Sync API bypasses the controller-level check by writing directly through the DAL EntityWriter. The integration entity definition lacks WriteProtection, and the admin field has no field-level restriction flag.

OWASP: A01:2021 — Broken Access Control

Root Cause

IntegrationController::upsertIntegration() checks $source->isAdmin() before allowing the admin field to be set. However, SyncController::sync() routes writes through SyncService → EntityWriter, which only applies:

  1. AclWriteValidator — checks entity-level ACL (integration:create is sufficient)
  2. EntityProtectionValidator — checks WriteProtection on entity definitions, but IntegrationDefinition has none

The admin field in IntegrationDefinition is a plain BoolField with no WriteProtection or special flag. The Sync API writes it without restriction.

Vulnerable code path: - src/Core/Framework/Api/Controller/SyncController.phpSyncServiceEntityWriter::upsert() - Missing protection: src/Core/Framework/Integration/IntegrationDefinition.phpadmin field has no WriteProtection(Context::SYSTEM_SCOPE)

Working protection (bypassed): - src/Core/Framework/Integration/IntegrationController.php:46-56isAdmin() check only applies to the dedicated controller endpoint

Impact

  • Complete admin API access — the escalated integration has full read/write on every entity: users, customers, orders, system configuration, integrations, plugins
  • PII exfiltration — read all customer records (names, emails, addresses, order history)
  • Persistent backdoor — the admin integration survives password changes and user deactivation

Remediation

Add WriteProtection(Context::SYSTEM_SCOPE) to IntegrationDefinition, matching how UserDefinition and AclRoleDefinition are already protected:

// src/Core/Framework/Integration/IntegrationDefinition.php
(new BoolField('admin', 'admin'))
    ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)),
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-48008"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-862"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-04T19:23:33Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nA non-admin API user with `integration:create` ACL privilege can escalate to full administrator by creating an integration with `admin: true` through the Sync API (`POST /api/_action/sync`). The regular integration endpoint (`POST /api/integration`) correctly blocks this, but the Sync API bypasses the controller-level check by writing directly through the DAL EntityWriter. The `integration` entity definition lacks `WriteProtection`, and the `admin` field has no field-level restriction flag.\n\n**OWASP:** A01:2021 \u2014 Broken Access Control\n\n## Root Cause\n\n`IntegrationController::upsertIntegration()` checks `$source-\u003eisAdmin()` before allowing the `admin` field to be set. However, `SyncController::sync()` routes writes through `SyncService \u2192 EntityWriter`, which only applies:\n\n1. `AclWriteValidator` \u2014 checks entity-level ACL (`integration:create` is sufficient)\n2. `EntityProtectionValidator` \u2014 checks `WriteProtection` on entity definitions, but `IntegrationDefinition` has none\n\nThe `admin` field in `IntegrationDefinition` is a plain `BoolField` with no `WriteProtection` or special flag. The Sync API writes it without restriction.\n\n**Vulnerable code path:**\n- `src/Core/Framework/Api/Controller/SyncController.php` \u2192 `SyncService` \u2192 `EntityWriter::upsert()`\n- **Missing protection:** `src/Core/Framework/Integration/IntegrationDefinition.php` \u2014 `admin` field has no `WriteProtection(Context::SYSTEM_SCOPE)`\n\n**Working protection (bypassed):**\n- `src/Core/Framework/Integration/IntegrationController.php:46-56` \u2014 `isAdmin()` check only applies to the dedicated controller endpoint\n\n## Impact\n\n- **Complete admin API access** \u2014 the escalated integration has full read/write on every entity: users, customers, orders, system configuration, integrations, plugins\n- **PII exfiltration** \u2014 read all customer records (names, emails, addresses, order history)\n- **Persistent backdoor** \u2014 the admin integration survives password changes and user deactivation\n\n## Remediation\n\nAdd `WriteProtection(Context::SYSTEM_SCOPE)` to `IntegrationDefinition`, matching how `UserDefinition` and `AclRoleDefinition` are already protected:\n\n```php\n// src/Core/Framework/Integration/IntegrationDefinition.php\n(new BoolField(\u0027admin\u0027, \u0027admin\u0027))\n    -\u003eaddFlags(new WriteProtection(Context::SYSTEM_SCOPE)),\n```",
  "id": "GHSA-gv8p-48fr-4fxg",
  "modified": "2026-06-04T19:23:33Z",
  "published": "2026-06-04T19:23:33Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/shopware/shopware/security/advisories/GHSA-gv8p-48fr-4fxg"
    },
    {
      "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:L/PR:H/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass"
}



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…

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.


Loading…