Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass
Published 4 Jun 2026 · Updated 10 Sept 2026
Affected packages
- Affected
- >=6.7.0.0 <6.7.10.1
- Fixed in
- 6.7.10.1
composer require shopware/platform:^6.7.10.1- Affected
- <6.6.10.18
- Fixed in
- 6.6.10.18
composer require shopware/platform:^6.6.10.18- Affected
- >=6.7.0.0 <6.7.10.1
- Fixed in
- 6.7.10.1
composer require shopware/core:^6.7.10.1- Affected
- <6.6.10.18
- Fixed in
- 6.6.10.18
composer require shopware/core:^6.6.10.18Details
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.php→SyncService→EntityWriter::upsert()- Missing protection:
src/Core/Framework/Integration/IntegrationDefinition.php—adminfield has noWriteProtection(Context::SYSTEM_SCOPE)
Working protection (bypassed):
src/Core/Framework/Integration/IntegrationController.php:46-56—isAdmin()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)),Is GHSA-gv8p-48fr-4fxg in any of your client repos?
Checking one package by hand is fine. Checking it across forty client projects is not. NPMscan reads the lockfiles in every GitHub repo you pick, finds each project with an affected shopware/platform, and gives you the command that fixes it.
References
Advisory data from OSV.dev (opens OSV.dev in a new tab), refreshed daily.