GHSA-v39m-97p8-gqg7 CVE-2026-48010
Shopware: Privilege escalation: non-admin user with user:create ACL can create admin accounts
- Severity
- 6.5 / 10
- Medium · CVSS 3.1
- Exploit chance (EPSS)
- 0.47%
- Chance of exploitation in the next 30 days. Higher than 40.83% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-269 Improper Privilege Management
- Fix
- Available
- 2 packages have a fixed version
Description
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:
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:
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:
$source = $context->getSource();
if ((!$source instanceof AdminApiSource) || (!$source->isAdmin() && isset($data['admin']))) {
throw new PermissionDeniedException();
}
Best regards, Keyvan Hardani
Affected versions
Packagist
| Package | Vulnerable | Fixed in |
|---|---|---|
| shopware/core | >= 6.7.0.0, < 6.7.10.1 |
6.7.10.1 |
| shopware/core | < 6.6.10.18 |
6.6.10.18 |
| shopware/platform | >= 6.7.0.0, < 6.7.10.1 |
6.7.10.1 |
| shopware/platform | < 6.6.10.18 |
6.6.10.18 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
shopware/core Packagist → 6.7.10.1
- composer
composer require shopware/core:^6.7.10.1
shopware/platform Packagist → 6.7.10.1
- composer
composer require shopware/platform:^6.7.10.1
Severity breakdown
CVSS 3.1 6.5
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:N
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- High
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- High
- Integrity
- High
- Availability
- None
Weakness
CWE-269: Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
References
Packages
Other links
- github.com/shopware/shopware/security/advisories/GHSA-v39m-97p8-gqg7
- github.com/shopware/shopware/releases/tag/v6.6.10.18
- github.com/shopware/shopware/releases/tag/v6.7.10.1
- github.com/shopware/shopware/commit/7f1cef324ca4edfa6369264cc1c41287d032624d
- github.com/shopware/shopware/commit/d8d9a34a9255abf69c2798015a17cd6a80b08c25
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-gq96-5pfx-f4vc Shopware: SSRF in Media External-Link Endpoint Bypasses IP Validation | Medium | Also affects shopware/core |
| GHSA-xvhc-gm7j-mhmc Shopware: Stored XSS via SVG file upload — no SVG sanitization | Medium | Also affects shopware/core |
| GHSA-9v5m-39wh-5chq Shopware: Unauthorized Payment Trigger for Foreign Orders via /store-api/handle-payment | Medium | Also affects shopware/core |
| GHSA-f8q6-3g5w-jjr6 Shopware: Admin API ACL Bypass in Order State Transition Endpoints | Medium | Also affects shopware/core |
| GHSA-4x3x-869w-xx3m Shopware SSO referer trust leading to an arbitrary redirect target | Medium | Also affects shopware/core |
| GHSA-7w52-7jvm-m9vw Shopware: Timing-attack on admin panel allowing enumeration of administrator usernames | Low | Also affects shopware/core |
| GHSA-8v9p-g828-v98f Shopware: Admin Account Takeover via User Recovery Hash Exposure | Medium | Also affects shopware/core |
| GHSA-gv8p-48fr-4fxg Shopware: Privilege Escalation via Sync API Integration Admin Flag Bypass | Medium | Also affects shopware/core |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor