`UserController::upsertUser()` writes user data in `SYSTEM_SCOPE` and does not filter the `admin` field. A non-admin API user with `user:create` or `user:update` ACL permission can set `admin: true` on new or existing users, escalating to full admin access. ## The Problem In `src/Core/Framework/Api/Controller/UserController.php`, line 210-234: ```php public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response { $data = $request->request->all(); // raw request data, no field filtering // ... $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) => $this->userRepository->upsert([$data], $context) ); } ``` `SYSTEM_SCOPE` bypasses `AclWriteValidator` entirely (line 52 of `AclWriteValidator::preValidate()` returns early for `SYSTEM_SCOPE`). The `admin` boolean field is accepted without restriction. Compare with `IntegrationController::upsertIntegration()` in the same codebase, which correctly checks: ```php if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin'])) ) { throw new PermissionDeniedException(); } ``` `UserController` is missing this exact check. ## Impact Any API user with the low-privilege `user:create` permission can create accounts with full admin access, or with `user:update` can promote any existing user to admin. This is a direct privilege escalation. ## Suggested Fix Add the same `isAdmin()` check from `IntegrationController`: ```php $source = $context->getSource(); if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) { throw new PermissionDeniedException(); } ``` Best regards, Keyvan Hardani
`UserController::upsertUser()` writes user data in `SYSTEM_SCOPE` and does not filter the `admin` field. A non-admin API user with `user:create` or `user:update` ACL permission can set `admin: true` on new or existing users, escalating to full admin access. ## The Problem In `src/Core/Framework/Api/Controller/UserController.php`, line 210-234: ```php public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response { $data = $request->request->all(); // raw request data, no field filtering // ... $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) => $this->userRepository->upsert([$data], $context) ); } ``` `SYSTEM_SCOPE` bypasses `AclWriteValidator` entirely (line 52 of `AclWriteValidator::preValidate()` returns early for `SYSTEM_SCOPE`). The `admin` boolean field is accepted without restriction. Compare with `IntegrationController::upsertIntegration()` in the same codebase, which correctly checks: ```php if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin'])) ) { throw new PermissionDeniedException(); } ``` `UserController` is missing this exact check. ## Impact Any API user with the low-privilege `user:create` permission can create accounts with full admin access, or with `user:update` can promote any existing user to admin. This is a direct privilege escalation. ## Suggested Fix Add the same `isAdmin()` check from `IntegrationController`: ```php $source = $context->getSource(); if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) { throw new PermissionDeniedException(); } ``` Best regards, Keyvan Hardani
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: non-admin user with user:create ACL can create admin accounts affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. `UserController::upsertUser()` writes user data in `SYSTEM_SCOPE` and does not filter the `admin` field. A non-admin API user with `user:create` or `user:update` ACL permission can set `admin: true` on new or existing users, escalating to full admin access. ## The Problem In `src/Core/Framework/Api/Controller/UserController.php`, line 210-234: ```php public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response { $data = $request->request->all(); // raw request data, no field filtering // ... $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) => $this->userRepository->upsert([$data], $context) ); } ``` `SYSTEM_SCOPE` bypasses `AclWriteValidator` entirely (line 52 of `AclWriteValidator::preValidate()` returns early for `SYSTEM_SCOPE`). The `admin` boolean field is accepted without restriction. Compare with `IntegrationController::upsertIntegration()` in the same codebase, which correctly checks: ```php if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin'])) ) { throw new PermissionDeniedException(); } ``` `UserController` is missing this exact check. ## Impact Any API user with the low-privilege `user:create` permission can create accounts with full admin access, or with `user:update` can promote any existing user to admin. This is a direct privilege escalation. ## Suggested Fix Add the same `isAdmin()` check from `IntegrationController`: ```php $source = $context->getSource(); if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) { throw new PermissionDeniedException(); } ``` Best regards, Keyvan Hardani
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: non-admin user with user:create ACL can create admin accounts affects shopware/core (composer), shopware/core (composer), shopware/platform (composer), shopware/platform (composer). Severity is medium. `UserController::upsertUser()` writes user data in `SYSTEM_SCOPE` and does not filter the `admin` field. A non-admin API user with `user:create` or `user:update` ACL permission can set `admin: true` on new or existing users, escalating to full admin access. ## The Problem In `src/Core/Framework/Api/Controller/UserController.php`, line 210-234: ```php public function upsertUser(?string $userId, Request $request, Context $context, ResponseFactoryInterface $factory): Response { $data = $request->request->all(); // raw request data, no field filtering // ... $events = $context->scope(Context::SYSTEM_SCOPE, fn (Context $context) => $this->userRepository->upsert([$data], $context) ); } ``` `SYSTEM_SCOPE` bypasses `AclWriteValidator` entirely (line 52 of `AclWriteValidator::preValidate()` returns early for `SYSTEM_SCOPE`). The `admin` boolean field is accepted without restriction. Compare with `IntegrationController::upsertIntegration()` in the same codebase, which correctly checks: ```php if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin'])) ) { throw new PermissionDeniedException(); } ``` `UserController` is missing this exact check. ## Impact Any API user with the low-privilege `user:create` permission can create accounts with full admin access, or with `user:update` can promote any existing user to admin. This is a direct privilege escalation. ## Suggested Fix Add the same `isAdmin()` check from `IntegrationController`: ```php $source = $context->getSource(); if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) { throw new PermissionDeniedException(); } ``` Best regards, Keyvan Hardani
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