## 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` — `admin` field has no `WriteProtection(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: ```php // src/Core/Framework/Integration/IntegrationDefinition.php (new BoolField('admin', 'admin')) ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)), ```
## 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` — `admin` field has no `WriteProtection(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: ```php // src/Core/Framework/Integration/IntegrationDefinition.php (new BoolField('admin', 'admin')) ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)), ```
Update shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Privilege Escalation via Sync API Integration Admin Flag Bypass affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. ## 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` — `admin` field has no `WriteProtection(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: ```php // src/Core/Framework/Integration/IntegrationDefinition.php (new BoolField('admin', 'admin')) ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)), ```
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL GuardUpdate shopware/core to 6.7.10.1; shopware/core to 6.6.10.18; shopware/platform to 6.7.10.1; shopware/platform to 6.6.10.18 if you use the affected versions. Test the change in a non-production environment first.
Local check
hol-guard supply-chain scanShopware: Privilege Escalation via Sync API Integration Admin Flag Bypass affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. ## 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` — `admin` field has no `WriteProtection(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: ```php // src/Core/Framework/Integration/IntegrationDefinition.php (new BoolField('admin', 'admin')) ->addFlags(new WriteProtection(Context::SYSTEM_SCOPE)), ```
AI coding agents often install or upgrade packages automatically in composer. A medium vulnerability in a dependency can be pulled into a project through a normal install or update without a human reviewing the change, expanding the blast radius from a single package to every agent workspace that depends on it.
| Package | Affected range | Fixed version |
|---|---|---|
| shopware/corecomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/corecomposer | <6.6.10.18 | 6.6.10.18 |
| shopware/platformcomposer | >=6.7.0.0,<6.7.10.1 | 6.7.10.1 |
| shopware/platformcomposer | <6.6.10.18 | 6.6.10.18 |
Fixed versions are reported by the source feed; confirm compatibility before updating.
Reported by GitHub Security Advisories (ghsa).
HOL Guard can help your team review package activity against supported protection paths.
Explore HOL Guard